No way to convert V2 tokens to V3 if domain id changes

NOte that this has a security implication in that policy might be improperly enforced based on the domain for admin actions.

This is proposing an API impacting solution to a deprecated API, and completely glossing over the problem being addressed.

> If they default domain changes, the tokens will not be properly converted.

What does this mean?

If a configuration changes the default domains name or ID from "default" to ,s ay a UUID based domain, the default domain tokens will not properly reflect the new default domain, but will, rather reflect the assumed default domain_id of "default." The only way to expose this information to the outside world, and not make an assumption, is to expose the configuration value that Keystone knows about.

This is not invalid. Call it a low priorty bug, but it is a real bug seen in deployments as we try to change the endpoint to using the V3 API. Since service users get reigstered in the domain that is created initially, but we want to have the corporate LDAP serve the human users. The default domain will still point at "default" not the LDAP backed domain.

V2 is not yet deprecated; we still mark it as supported. We need a transition strategy, and adding a value to help in that migration is the lowest impact solution I've come across. The alternative is making the Keystone Config value remotely queryable, which seems even higher impact.

> the default domain tokens will not properly reflect the new default domain

You're losing me here, and I'm not understanding what use case is breaking. What are "default domain tokens"?

I'm with dolph. This bug isn't making any sense to me.

[Expired for OpenStack Identity (keystone) because there has been no activity for 60 days.]