Sent via mobile
> On Jun 9, 2015, at 05:44, 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
