Comment 3 for bug 1477373

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.