Comment 9 for bug 1473396

Sergey, you're missing the point, your statement "I hope that it is obvious that keystone admin tests will fail against keystone 'publicUrl'." is 100% deployment specific and not a absolute truth. The way you've deployed your cloud, which is likely just the keystone default paste file, might make this statement true for when you're running tests. But, that doesn't make it true for every deployment, it's still completely configurable by deployers. I can easily setup a cloud using the knobs provided as deployer configuration and change this behavior.

The issue with all of those proposed solutions you mention is that the are treating adminURL and publicURL endpoint types as a defined categories that will mean the same thing on every single cloud you're deploying on. The problem is that's just not true is it, those are just labels, I will agree that keystone v2 does have a separate public and admin api route (v3 does not) which is different, but that doesn't have anything to do with which endpoint types you use to access the different routes. I agree it's easy to confuse things here they so I'll try to use examples. Let's look at the default paste.ini file in the keystone repo:

http://git.openstack.org/cgit/openstack/keystone/tree/etc/keystone-paste.ini

This is considered a configuration file for deployers, sure you can use the default one, but nothing stops anyone from editing a config file. Looking at it you can see exactly where the split your asserting is setup towards the bottom of the page. You can do a simple synthetic experiment: swap L96 and L102, then restart keystone, and then run your tests again you'll notice the exact opposite behavior of what you're asserting here. (that would probably be a strange way to deploy your keystone but a completely valid way) How would your proposed skips work in the case? They'd skip all the admin tests and fail with the non-admin tests right? That would be the exact opposite of your intent with adding the skip logic. This is exactly what I'm talking about though, the endpoint_type names don't actually match up to the api your touching it's just a configurable label. Yes, it's confusing because they're both called admin and the intent is you use them together, but there isn't anything dictating that.

Just as with your skip your proposed solutions based solely on the endpoint_type as a branch selector for some other behavior won't work because they rely on the endpoint_type as the switch. We can't programatically change how we operate based on the configured endpoint_type it just doesn't work. It'd be different if we just had to worry about a single deployment, we could easily code to the behavior of a single deployment.