Open Stack

+1

While I hope that we can consider all of v2 deprecated as of Grizzly, we do
need to maintain as much support as possible for v2 authentication &
validation, probably until Grizzly + 3.

-Dolph


On Wed, Jan 23, 2013 at 10:47 AM, Henry Nash <henryn at linux.vnet.ibm.com>wrote:

> So, as previously described, what has been proposed is:
>
> - v2 tenants/users are migrated across to the default domain - the v2 api
> will continue to access these entities
> - If a cloud provider does (using the v3 api) create domains, then any
> users/groups/projects created within those domains are simply not visible
> via the v2 api.  A v3 client can, of course, create entities in the default
> domain....and those would be visible via the v2 api
> - The fact that a default domain exists at all is hidden from the v2 api
> (i.e. domain_id attributes from all entities in the default domain are
> filtered out)
> - A v2 client has no need to see domain roles, since it can't ask for them
> (i.e. it can't ask for a domain scoped token), and would not know how to
> interpret them anyway (i.e. the related policy file would not know about
> domain roles either)
> - More complex versions of the above indeed possible, but so far we have
> considered them more confusing to make them worthwhile
>
> Henry
> On 23 Jan 2013, at 15:32, David Chadwick wrote:
>
> > Isnt it more complex than this? What if an V3 admin has set up an
> OpenStack system with multiple domains, but some services are still using
> the V2 API. In this case they cant (or shouldn't) all occupy the default
> domain. Rather, as I argued in an earlier posting, there should be an
> intercept module in the Keystone code that converts the domain and role
> into <domain><separator><role> (where separator is a configurable string
> according to culture, language, char set etc.) and returns this to the V2
> api as the role (since it does not know about domains). Then the reverse
> conversion is done when the V2 API passes in the role. The only thing the
> V2 service needs to do is change its policy so that wherever role is
> specified in a rule it is now replaced by <domain><separator><role> as the
> role string. A string is just a string to a policy engine so it wont care
> that the string is now longer and has some hidden internal meaning.
> >
> > regards
> >
> > David
> >
> >
> > On 22/01/2013 15:07, Henry Nash wrote:
> >> OK, here is how I suggest we proceed:
> >>
> >> First, there are two separate (but related) items:
> >>
> >> 1) How do we migrate v2 users across?  I don't think anyone is arguing
> that they should not  go into a default domain  - we need a way of letting
> the v2 api work on users migrated across to Grizzly.  Dolph has a change
> pending to create the default domain, which I will then pick up and do the
> actual migration code as part of the domain_scoping change (since I need
> domains to be fully supported for that).  I suggest, we let Dolph's change
> go in since there is no debate about it.
> >> 2) What happens in v3 if a call is made to create an entity (user,
> group, project etc.) where the optional domain_id is not specified?  That
> is what all the options relate to.  There are really only 3 options (since
> Dolph's additions of D & E are actually duplicates of mine since I was not
> trying to suggest that we would override a domain_id if it IS specified).
>  Dolph and I will bring forward the proposed design/blueprint that
> specifies the proposal for these v3 calls in more detail.
> >>
> >> Does this sound like a plan?
> >>
> >> Henry
> >>
> >> On 22 Jan 2013, at 14:30, David Chadwick wrote:
> >>
> >>> I think a fully specified design document would be good before the
> implementation is hardened :-)
> >>>
> >>> On 22/01/2013 12:47, Adam Young wrote:
> >>>> On 01/22/2013 12:25 AM, Yee, Guang wrote:
> >>>>>
> >>>>> Is D) even possible, since token can only scope to one domain at a
> time?
> >>>>>
> >>>>> Guang
> >>>>>
> >>>>> *From:*Dolph Mathews [mailto:dolph.mathews at gmail.com]
> >>>>> *Sent:* Saturday, January 19, 2013 7:26 AM
> >>>>> *To:* OpenStack Development Mailing List
> >>>>> *Subject:* Re: [openstack-dev] [keystone] A default domain
> >>>>>
> >>>>> Yay! I'd be curious if anyone is particularly in favor of D,
> otherwise
> >>>>> I think we should run with A.
> >>>>>
> >>>>>
> >>>>> -Dolph
> >>>>>
> >>>>> On Sat, Jan 19, 2013 at 3:38 AM, Henry Nash <
> henryn at linux.vnet.ibm.com
> >>>>> <mailto:henryn at linux.vnet.ibm.com>> wrote:
> >>>>>
> >>>>> On 19 Jan 2013, at 05:19, Dolph Mathews wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Fri, Jan 18, 2013 at 8:23 AM, Henry Nash <
> henryn at linux.vnet.ibm.com
> >>>>> <mailto:henryn at linux.vnet.ibm.com>> wrote:
> >>>>>
> >>>>> Building on the question on how the v3 APIs might operation (e.g.
> >>>>> create user, project etc.) when the (optional) domain_id is
> >>>>> omitted....first some goals:
> >>>>>
> >>>>> 1) We want those cloud providers who don't need domains to be able to
> >>>>> use either the v2 or v3 api calls - i.e. they can use the latest s/w
> >>>>> and still operate their cloud like it was in Folsom (in terms of
> >>>>> keystone user-project relationships).
> >>>>>
> >>>>> 2) For operators that start using domains, we want it to be
> >>>>> conceptually obvious what sets of entities that various api calls
> will
> >>>>> be able to see.  This needs to take into account  domains with
> private
> >>>>> user or project namespaces.
> >>>>>
> >>>>> Taking this bp as a stating point in terms of having a default domain
> >>>>> (that will contain any pre-Girzzly user and projects/tenants), what
> >>>>> happens when a v3 API call is made to create a user or project
> without
> >>>>> specifying a domain?  The options are:
> >>>>>
> >>>>> a) Create the entity in the domain of the user doing the creation.
>  If
> >>>>> this is a user that exists in the default domain (e.g. a pre-Grizzly
> >>>>> user), then that's where the new resource goes (I would assume we
> >>>>> treat "admin" as being in the default domain).
> >>>>>
> >>>>> b) Always create the entity in the default domain
> >>>>>
> >>>>> c) Insist on the specification of a domain if more than just the
> >>>>> default domain exists (i.e. it's a multi-domain configuration)
> >>>>>
> >>>>> d) Always insist on the specification of a domain
> >>>>>
> >>>>> e) Create the entity in the domain of the user doing the creation,
> >>>>> unless another domain is specified.
> >>>>>
> >>>>> (A) is broken in use cases where I need to be allowed to create users
> >>>>> in other domains (creating domains and users to administer them, for
> >>>>> instance).
> >>>>>
> >>>>> (B) is broken for the same reason; I shouldn't have to create an
> >>>>> object and then move it to where I want it to go.
> >>>>>
> >>>>> (C) brings up some questions that I worry will only lead to bug
> >>>>> reports (what if I deleted the default domain but I still have this
> >>>>> other domain that doesn't match the default_domain_id, etc)
> >>>>>
> >>>>> (D) is obvious, but perhaps inconvenient for a subset of users (those
> >>>>> that ONLY administer their own domain).
> >>>>>
> >>>>> (E) offers the convenience of (A) with the power of (D). I can't
> think
> >>>>> of a use case that this breaks?
> >>>>>
> >>>>
> >>>> We create a component which is DomainResolutionStrategy.  There are 5
> >>>> concrete implementations, which map to A-E above.  Specify which to
> use
> >>>> in the config file.
> >>>>
> >>>>
> >>>>> Actually this is what I meant by (a)....since I was listing the
> >>>>> options for what we do when the user does NOT specify the optional
> >>>>> domain in the create call...so we are in violent agreement!
> >>>>>
> >>>>>
> >>>>>
> >>>>>    Allied to this is authentication....since a domain specifier is
> >>>>>    also optional in terms of the v3 auth details, which is relevant
> >>>>>    if username rather than user_id is specified:
> >>>>>
> >>>>>    i) user name (and project name for that matter) are still unique
> >>>>>    across all domains (including the default domain) except for those
> >>>>>    domains with a private name space.  So it would be perfectly
> >>>>>    possible to authenticate by searching for a user/project name in
> >>>>>    any domain other than those with private name spaces.  The
> >>>>>    advantage of this is that a domain specifier is ONLY required to
> >>>>>    access a domain with a private user namespace - access to all
> >>>>>    other domains doesn't need to worry about domains in terms of
> >>>>>    authentication (this is what is described in the domain-name-space
> >>>>>    blueprint).  The only question is whether this passes the test 2)
> >>>>>    above in terms of being obvious.  The alternative is to insist on
> >>>>>    a domain specifier to get to authenticate any user not in the
> >>>>>    default domain.
> >>>>>
> >>>>>    ii) The v2 authentication remains unchanged, of course, and will
> >>>>>    look for the user and tenant name in the default domain.  In
> >>>>>    theory, we could let such calls use the same search as i) to allow
> >>>>>    users who are not part of a private domain to authenticate via the
> >>>>>    v2 API.  However, I think this definitely fails the 2) obvious
> >>>>>    test and so we should not do this.
> >>>>>
> >>>>>    In terms of which of the options a), b) or c) we should chose in
> >>>>>    the creation question above, I think b) is unlikely to match
> >>>>>    typical use cases (i.e. if you have domains and have created users
> >>>>>    within them, you are unlikely to often want to create users in the
> >>>>>    default domain).  So the choice is between a) and c).  While c)
> >>>>>    certainly provides no ambiguity, I would think that a) would match
> >>>>>    the most common usage patterns, and is also not disruptive if you
> >>>>>    missed off specifying the domain by mistake (since you only affect
> >>>>>    your own domain).
> >>>>>
> >>>>>    Other ideas/comments?
> >>>>>
> >>>>>    Henry
> >>>>>
> >>>>>    On 16 Jan 2013, at 22:00, Dolph Mathews wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>    New installs run through the migration process of course, so they
> >>>>>    would end up with a default domain, even if there's nothing
> >>>>>    referencing it. The v2 API would not work out of the box,
> otherwise.
> >>>>>
> >>>>>    If you didn't want to support the v2 API in your deployment, you'd
> >>>>>    have to manually remove the v2-related pipelines from your
> >>>>>    keystone.conf, and then you could manually delete the default
> >>>>>    domain through SQL (if desired -- it's still a valid domain on
> >>>>>    v3). Attempting to delete it through the v3 API would break the v2
> >>>>>    API, hence the desire to deny that behavior and force a manual
> >>>>>    process. All of these constraints could be removed in the
> >>>>>    Grizzly+2 timeframe, if we see fit to no longer support v2 at all
> >>>>>    (at that point, the data migration could be revised to only create
> >>>>>    a default domain *if it was necessary based on existing data*, so
> >>>>>    fresh Grizzly+2 installs would be empty out of the box).
> >>>>>
> >>>>>    Alternatively, if you wanted to expose a different domain on v2,
> >>>>>    you could also create & configure it on v3, and then set your
> >>>>>    default_domain_id to that domain's ID, and then delete the unused
> >>>>>    'default' domain through the API (e.g. DELETE
> >>>>>    /v3/domains/default). You could use a similar process to
> >>>>>    completely circumvent the dont-delete-the-default-domain check.
> >>>>>
> >>>>>    LDAP support for domains is trailing at the moment, so I'm
> >>>>>    speaking mostly with an eye toward SQL, but the default_domain_id
> >>>>>    will apply there as well -- we just won't be able to create the
> >>>>>    domain for you.
> >>>>>
> >>>>>    All that said, although it's relatively early in the grizzly-m3
> >>>>>    cycle, I don't imagine you will want to deploy Grizzly without v2
> >>>>>    support as there will still be v2 clients in use, even among the
> >>>>>    core projects.
> >>>>>
> >>>>>    -Dolph
> >>>>>
> >>>>>    On Wed, Jan 16, 2013 at 1:57 PM, Brant Knudson <blk at acm.org
> >>>>>    <mailto:blk at acm.org>> wrote:
> >>>>>
> >>>>>    Dolph -
> >>>>>
> >>>>>    The bp mentions migration, but it doesn't mention new installs.
> >>>>>    Does a new install automatically get the default domain?
> >>>>>
> >>>>>    The bp says that you can also not have a default domain, but the
> >>>>>    default_domain_id configuration option has a default. What do I
> >>>>>    set the configuration option to if I don't have a default domain?
> >>>>>
> >>>>>    The bp says that an attempt to delete the default domain will
> >>>>>    result in 403 Forbidden. In the case where there is no default
> >>>>>    domain you should get a 404 Not Found rather than 403.
> >>>>>
> >>>>>    - Brant
> >>>>>
> >>>>>    On Tue, Jan 15, 2013 at 2:42 PM, Dolph Mathews
> >>>>>    <dolph.mathews at gmail.com <mailto:dolph.mathews at gmail.com>> wrote:
> >>>>>
> >>>>>        Per today's keystone meeting, I wrote a blueprint for the
> >>>>>        default domain solution, in order to provide an assumed scope
> >>>>>        for v2 API operations (which is not domain-aware), including
> >>>>>        authentication and validation, in the context of a deployment
> >>>>>        with v3 API users (which are domain-aware).
> >>>>>
> >>>>>
> https://blueprints.launchpad.net/keystone/+spec/default-domain
> >>>>>
> >>>>>        Feedback appreciated,
> >>>>>
> >>>>>        -Dolph
> >>>>>
> >>>>>        _______________________________________________
> >>>>>        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
> >>>>>
> >>>>>
> >>>>>    _______________________________________________
> >>>>>    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
> >>>>>
> >>>>>    _______________________________________________
> >>>>>    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
> >>>>>
> >>>>>
> >>>>>    _______________________________________________
> >>>>>    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
> >>>>>
> >>>>> _______________________________________________
> >>>>> 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
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> 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
> >>>>>
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> OpenStack-dev mailing list
> >>>>> OpenStack-dev at lists.openstack.org
> >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> OpenStack-dev mailing list
> >>>> OpenStack-dev at lists.openstack.org
> >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>>
> >>>
> >>> _______________________________________________
> >>> OpenStack-dev mailing list
> >>> OpenStack-dev at lists.openstack.org
> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>
> >>
> >>
> >> _______________________________________________
> >> OpenStack-dev mailing list
> >> OpenStack-dev at lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >
>
>
> _______________________________________________
> OpenStack-dev mailing list
> 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/20130123/0ff16071/attachment.html>