Comment 4 for bug 1473396

So I think the confusion here is around the idea that all clouds have the same restrictions set on endpoint configurations and the catalog entries. The point Andrea is making here is that keystone (or any service for that matter) can be configured to restrict or to not restrict operations to any endpoint type. Just like the policy file is completely configurable so you can severely limit the rules for performing an operation or even disable it. Yes this makes things terrible, absolutely terrible, from an interoperability standpoint, but as it stands this how things work. We can't be making assumptions like what you have described in this bug about only being able to perform admin actions against the adminURL endpoint type. I can easily configure an OpenStack cloud to do the exact opposite and restrict admin actions to the publicURL endpoint type and reject all other user creds and non-admin actions, (I'm not sure why I'd do this though) the endpoint type is just a label and doesn't carry any extra weight.

This is exactly why tempest has a config option to specify which endpoint type to use for tests. The only solution that will fit any possible deployment is to limit ourselves to a single endpoint type because there are no standard rules for how they should be used. If using a single endpoint is too restrictive for your particular deployment to run all the tests then you'll have to leverage the test runner or config feature flags to select the set of tests which are supposed to work against that single endpoint. Then you can have a separate config/set of tests if you need and concatenate the results. (this is a nice feature of the subunit protocol if you use that for tracking results because this just works)

So I agree with Andrea, the part of the bug here which is valid is the hardcoded adminURL. In no way is that correct and we should fix it. As for taking an opinion on which tests should run with which endpoint type we can not do that, because there is not way to make that assumption compatible for every deployment out there. I also would like to change the default type to publicURL because that's really what we should be running against by default, but there is a backwards compat concern for changing the default. (a good compromise might be a detailed help comment and changing devstack over) We can discuss that in the review that honors the config flag.

FWIW, If you shared some more details about how your cloud is configured and why keystone is returning a 403 for your particular request I'd be willing to walk through logs with you to get to the bottom of a configuration which works.