Hi Folks, As we have discussed in the last Keystone meeting, we created an etherpad with the alternatives to solve this problem: https://etherpad.openstack.org/p/reseller-project-token We have also decided to take a vote to choose the best option in the next Keystone Meeting (#openstack-meeting - June 16th - 18:00 UTC).
It would be great if you could take a look before the meeting, so we could discuss and improve this document before the vote. Best regards, On Tue, Jun 9, 2015 at 12:12 PM Dolph Mathews <dolph.math...@gmail.com> wrote: > 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 >
__________________________________________________________________________ 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