On Mon, Jun 8, 2015 at 10:44 PM, Jamie Lennox <jamielen...@redhat.com> wrote:
> > > ----- Original Message ----- > > From: "David Chadwick" <d.w.chadw...@kent.ac.uk> > > To: openstack-dev@lists.openstack.org > > Sent: Saturday, 6 June, 2015 6:01:10 PM > > Subject: Re: [openstack-dev] [keystone][reseller] New way to get a > project scoped token by name > > > > > > > > On 06/06/2015 00:24, Adam Young wrote: > > > On 06/05/2015 01:15 PM, Henry Nash wrote: > > >> I am sure I have missed something along the way, but can someone > > >> explain to me why we need this at all. Project names are unique > > >> within a domain, with the exception of the project that is acting as > > >> its domain (i.e. they can only every be two names clashing in a > > >> hierarchy at the domain level and below). So why isn’t specifying > > >> “is_domain=True/False” sufficient in an auth scope along with the > > >> project name? > > > > > > The limitation of " Project names are unique within a domain" is > > > artificial and somethi8ng we should not be enforcing. Names should > only > > > be unique within parent project. > > > > +++1 > > I said the exact same thing as Henry in the other thread that seems to be > on the same topic. You're correct the limitation of "Project names are > unique within a domain" is completely artificial, but it's a constraint > that allows us to maintain the auth systems we currently have and will not > harm the reseller model (because they would be creating new domains). > > It's also a constraint that we can relax later when multitenancy is a bit > more established and someone has a real issue with the limitation - it's > not something we can ever claw back again if we allow some looking up > projects by name with delimiters. > > I think for the time being it's an artificial constraint we should > maintain. > +1 > > > > > > > > > This whole thing started by trying to distinguish a domain from a > > > project within that domain that both have the same name. We can special > > > case that, but it is not a great solution. > > > > > > > > > > > >> > > >> Henry > > >> > > >>> On 5 Jun 2015, at 18:02, Adam Young <ayo...@redhat.com > > >>> <mailto:ayo...@redhat.com>> wrote: > > >>> > > >>> On 06/03/2015 05:05 PM, Morgan Fainberg wrote: > > >>>> Hi David, > > >>>> > > >>>> There needs to be some form of global hierarchy delimiter - well > > >>>> more to the point there should be a common one across OpenStack > > >>>> installations to ensure we are providing a good and consistent (and > > >>>> more to the point inter-operable) experience to our users. I'm > > >>>> worried a custom defined delimiter (even at the domain level) is > > >>>> going to make it difficult to consume this data outside of the > > >>>> context of OpenStack (there are applications that are written to use > > >>>> the APIs directly). > > >>> We have one already. We are working JSON, and so instead of project > > >>> name being a string, it can be an array. > > >>> > > >>> Nothing else is backwards compatible. Nothing else will ensure we > > >>> don;t break exisiting deployments. > > >>> > > >>> Moving forward, we should support DNS notation, but it has to be an > > >>> opt in > > >>> > > >>>> > > >>>> The alternative is to explicitly list the delimiter in the project ( > > >>>> e.g. {"hierarchy": {"delim": ".", "domain.project.project2"}} ). The > > >>>> additional need to look up the delimiter / set the delimiter when > > >>>> creating a domain is likely to make for a worse user experience than > > >>>> selecting one that is not different across installations. > > >>>> > > >>>> --Morgan > > >>>> > > >>>> On Wed, Jun 3, 2015 at 12:19 PM, David Chadwick > > >>>> <d.w.chadw...@kent.ac.uk <mailto:d.w.chadw...@kent.ac.uk>> wrote: > > >>>> > > >>>> > > >>>> > > >>>> On 03/06/2015 14:54, Henrique Truta wrote: > > >>>> > Hi David, > > >>>> > > > >>>> > You mean creating some kind of "delimiter" attribute in the > domain > > >>>> > entity? That seems like a good idea, although it does not > > >>>> solve the > > >>>> > problem Morgan's mentioned that is the global hierarchy > delimiter. > > >>>> > > >>>> There would be no global hierarchy delimiter. Each domain would > > >>>> define > > >>>> its own and this would be carried in the JSON as a separate > > >>>> parameter so > > >>>> that the recipient can tell how to parse hierarchical names > > >>>> > > >>>> David > > >>>> > > >>>> > > > >>>> > Henrique > > >>>> > > > >>>> > Em qua, 3 de jun de 2015 às 04:21, David Chadwick > > >>>> > <d.w.chadw...@kent.ac.uk <mailto:d.w.chadw...@kent.ac.uk> > > >>>> <mailto:d.w.chadw...@kent.ac.uk > > >>>> <mailto:d.w.chadw...@kent.ac.uk>>> escreveu: > > >>>> > > > >>>> > > > >>>> > > > >>>> > On 02/06/2015 23:34, Morgan Fainberg wrote: > > >>>> > > Hi Henrique, > > >>>> > > > > >>>> > > I don't think we need to specifically call out that we > > >>>> want a > > >>>> > domain, we > > >>>> > > should always reference the namespace as we do today. > > >>>> Basically, if we > > >>>> > > ask for a project name we need to also provide it's > > >>>> namespace (your > > >>>> > > option #1). This clearly lines up with how we handle > > >>>> projects in > > >>>> > domains > > >>>> > > today. > > >>>> > > > > >>>> > > I would, however, focus on how to represent the > > >>>> namespace in a single > > >>>> > > (usable) string. We've been delaying the work on this > > >>>> for a while > > >>>> > since > > >>>> > > we have historically not provided a clear way to > delimit the > > >>>> > hierarchy. > > >>>> > > If we solve the issue with "what is the delimiter" > > >>>> between domain, > > >>>> > > project, and subdomain/subproject, we end up solving the > > >>>> usability > > >>>> > > > >>>> > why not allow the top level domain/project to define the > > >>>> delimiter for > > >>>> > its tree, and to carry the delimiter in the JSON as a new > > >>>> parameter. > > >>>> > That provides full flexibility for all languages and > locales > > >>>> > > > >>>> > David > > >>>> > > > >>>> > > issues with proposal #1, and not breaking the current > > >>>> behavior you'd > > >>>> > > expect with implementing option #2 (which at face value > > >>>> feels to > > >>>> > be API > > >>>> > > incompatible/break of current behavior). > > >>>> > > > > >>>> > > Cheers, > > >>>> > > --Morgan > > >>>> > > > > >>>> > > On Tue, Jun 2, 2015 at 7:43 AM, Henrique Truta > > >>>> > > <henriquecostatr...@gmail.com > > >>>> <mailto:henriquecostatr...@gmail.com> > > >>>> > <mailto:henriquecostatr...@gmail.com > > >>>> <mailto:henriquecostatr...@gmail.com>> > > >>>> > <mailto:henriquecostatr...@gmail.com > > >>>> <mailto:henriquecostatr...@gmail.com> > > >>>> > <mailto:henriquecostatr...@gmail.com > > >>>> <mailto:henriquecostatr...@gmail.com>>>> wrote: > > >>>> > > > > >>>> > > Hi folks, > > >>>> > > > > >>>> > > > > >>>> > > In Reseller[1], we’ll have the domains concept > > >>>> merged into > > >>>> > projects, > > >>>> > > that means that we will have projects that will > > >>>> behave as domains. > > >>>> > > Therefore, it will be possible to have two projects > > >>>> with the same > > >>>> > > name in a hierarchy, one being a domain and another > > >>>> being a > > >>>> > regular > > >>>> > > project. For instance, the following hierarchy will > > >>>> be valid: > > >>>> > > > > >>>> > > A - is_domain project, with domain A > > >>>> > > > > >>>> > > | > > >>>> > > > > >>>> > > B - project > > >>>> > > > > >>>> > > | > > >>>> > > > > >>>> > > A - project with domain A > > >>>> > > > > >>>> > > > > >>>> > > That hierarchy faces a problem when a user requests > > >>>> a project > > >>>> > scoped > > >>>> > > token by name, once she’ll pass “domain = ‘A’” and > > >>>> > project.name <http://project.name/> <http://project.name > > >>>> <http://project.name/>> > > >>>> > > <http://project.name <http://project.name/>> = “A”. > > >>>> Currently, we have no way to > > >>>> > > distinguish which project we are referring to. We > > >>>> have two > > >>>> > proposals > > >>>> > > for this. > > >>>> > > > > >>>> > > > > >>>> > > 1. > > >>>> > > > > >>>> > > Specify the whole hierarchy in the token request > > >>>> body, which > > >>>> > > means that when requesting a token for the child > > >>>> project for > > >>>> > > that hierarchy, we’ll have in the scope field > > >>>> something like: > > >>>> > > > > >>>> > > "project": { > > >>>> > > "domain": { > > >>>> > > "name": "A" > > >>>> > > }, > > >>>> > > "name": [“A”', “B”, “A”] > > >>>> > > } > > >>>> > > > > >>>> > > > > >>>> > > If the project name is unique inside the domain > > >>>> (project “B”, for > > >>>> > > example), the hierarchy is optional. > > >>>> > > > > >>>> > > > > >>>> > > 2. > > >>>> > > > > >>>> > > When a conflict happen, always provide a token > > >>>> to the child > > >>>> > > project. That means that, in case we have a name > > >>>> clashing as > > >>>> > > described, it will only be possible to get a > > >>>> project scoped > > >>>> > > token to the is_domain project through its id. > > >>>> > > > > >>>> > > > > >>>> > > > > >>>> > > The former will give us more clarity and won’t > > >>>> create any more > > >>>> > > restrictions than we already have. As a con, we > > >>>> currently are not > > >>>> > > able to get the names of projects in the hierarchy > > >>>> above a given > > >>>> > > project. Although the latter seems to hurt fewer > > >>>> people, it > > >>>> > has the > > >>>> > > disadvantage of creating another set of constraints > > >>>> that might > > >>>> > > difficult the UX in the future. > > >>>> > > > > >>>> > > > > >>>> > > What do you think about that? We want to hear your > > >>>> oppinion, so we > > >>>> > > can discuss it at today’s Keystone Meeting. > > >>>> > > > > >>>> > > > > >>>> > > [1] > > >>>> > > > > >>>> > > > >>>> > https://github.com/openstack/keystone-specs/blob/master/specs/liberty/reseller.rst > > >>>> > > > > >>>> > > > > >>>> > > > > >>>> > > > >>>> > __________________________________________________________________________ > > >>>> > > OpenStack Development Mailing List (not for usage > > >>>> questions) > > >>>> > > Unsubscribe: > > >>>> > > > > >>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > > >>>> < > http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe> > > >>>> > > > >>>> < > http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > > >>>> < > http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe>> > > >>>> > > > > >>>> > > > >>>> < > http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > > >>>> < > http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe>> > > >>>> > > > > >>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > >>>> > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>> > > > >>>> > __________________________________________________________________________ > > >>>> > > OpenStack Development Mailing List (not for usage > questions) > > >>>> > > Unsubscribe: > > >>>> > > > >>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > > >>>> < > http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe> > > >>>> > > > >>>> < > http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > > >>>> < > http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe>> > > >>>> > > > > >>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > >>>> > > > > >>>> > > > >>>> > > > >>>> > __________________________________________________________________________ > > >>>> > OpenStack Development Mailing List (not for usage > questions) > > >>>> > Unsubscribe: > > >>>> > > > >>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > > >>>> < > http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe> > > >>>> > > > >>>> < > http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > > >>>> < > http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe>> > > >>>> > > > >>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > >>>> > > > >>>> > > > >>>> > > > >>>> > > > >>>> > __________________________________________________________________________ > > >>>> > OpenStack Development Mailing List (not for usage questions) > > >>>> > Unsubscribe: > > >>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > > >>>> < > http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe> > > >>>> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > >>>> > > > >>>> > > >>>> > __________________________________________________________________________ > > >>>> OpenStack Development Mailing List (not for usage questions) > > >>>> Unsubscribe: > > >>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > > >>>> < > http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe> > > >>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > __________________________________________________________________________ > > >>>> OpenStack Development Mailing List (not for usage questions) > > >>>> Unsubscribe: > > >>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > > >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > >>> > > >>> > __________________________________________________________________________ > > >>> OpenStack Development Mailing List (not for usage questions) > > >>> Unsubscribe: openstack-dev-requ...@lists.openstack.org > > >>> <mailto:openstack-dev-requ...@lists.openstack.org > >?subject:unsubscribe > > >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > >> > > >> > > >> > > >> > __________________________________________________________________________ > > >> OpenStack Development Mailing List (not for usage questions) > > >> Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > > > > > > > > __________________________________________________________________________ > > > OpenStack Development Mailing List (not for usage questions) > > > Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > > > __________________________________________________________________________ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev