Open Stack

Thanks Dolph, that’s helpful.

For backwards compatibility reasons we need to preserve legacy access control list behavior for projects/users in the default domain only. To achieve that, we need to persist the project’s domain id in Swift. If a project subsequently moved to/from the default domain then Swift wouldn’t ‘break’ but would potentially (dis)allow legacy ACLs based on stale domain information.

If the backwards compatibility feature in Swift were configurable (on/off) then, as you suggest, some text alongside the Keystone config option (and corresponding in Swift) can act as a warning not to enable both options.
Alistair


From: Dolph Mathews [mailto:dolph.mathews at gmail.com]
Sent: 01 July 2014 20:15
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Keystone] [Swift] Question re. keystone domains


On Tue, Jul 1, 2014 at 11:20 AM, Coles, Alistair <alistair.coles at hp.com<mailto:alistair.coles at hp.com>> wrote:
We have a change [1] under review in Swift to make access control lists compatible with migration to keystone v3 domains. The change makes two assumptions that I’d like to double-check with keystone folks:


1.      That a project can never move from one domain to another.
We're moving in this direction, at least. In Grizzly and Havana, we made no such restriction. In Icehouse, we introduced such a restriction by default, but it can be disabled. So far, we haven't gotten any complaints about adding the restriction, so maybe we should just add additional help text to the option in our config about why you would never want to disable the restriction, citing how it would break swift?

2.      That the underscore character cannot appear in a valid domain id – more specifically, that the string ‘_unknown’ cannot be confused with a domain id.
That's fairly sound. All of our domain ID's are system-assigned as UUIDs, except for the "default" domain which has an explicit id='default'. We don't do anything to validate the assumption, though.

Are those safe assumptions?

Thanks,
Alistair

[1] https://review.openstack.org/86430

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140702/f0fb4b01/attachment.html>