Ok, after all the pushback related to the domain users change I'm not sure how to proceed with this :(
Flipping the deferred_auth_method method to trusts is easy enough (apart from the unit test fallout), but then it is expected that the role referred to in trusts_delegated_roles will exist, and that every user creating a stack will have it (or whatever deployers put in that list), since to delegate via trusts you must have a role to delegate.
I believe the fallback for existing DB contents will be OK, but the fallback in the event deferred_auth_method=trusts and the role's aren't right will probably be unacceptable to those trunk-chasing heat.
Clint, perhaps you can provide feedback on your preferred strategy for making this tranition?
For now I think we'll have to make do with a patch which makes it the default in devstack (with a variable folks can easily use to switch back), at least then we'll be getting some wider usage and taking a step towards making it the default.
Ok, after all the pushback related to the domain users change I'm not sure how to proceed with this :(
Flipping the deferred_ auth_method method to trusts is easy enough (apart from the unit test fallout), but then it is expected that the role referred to in trusts_ delegated_ roles will exist, and that every user creating a stack will have it (or whatever deployers put in that list), since to delegate via trusts you must have a role to delegate.
I believe the fallback for existing DB contents will be OK, but the fallback in the event deferred_ auth_method= trusts and the role's aren't right will probably be unacceptable to those trunk-chasing heat.
Clint, perhaps you can provide feedback on your preferred strategy for making this tranition?
For now I think we'll have to make do with a patch which makes it the default in devstack (with a variable folks can easily use to switch back), at least then we'll be getting some wider usage and taking a step towards making it the default.
I'll remove the Icehouse milestone for this.