Open Stack

On 10/30/2012 04:00 AM, Henry Nash wrote:
> Gabriel,
>
> So I think you are right to ask that this is made clear and concrete - 
> I'll work with the core contributors of Keystone to make it so.
>
> To your specific point:
> - Let's call the initial Domain, the "Global Domain", rather than the 
> default domain
No.  It is default.  It is not global.  The other domains do not nest 
inside this domain.  Calling it the Global domain is confusing.  I would 
accept: unnamed domain, or implicit domain,  but don't think either of 
those are an improvement to default.

> - If the Cloud Provider doesn't explicitly create any domains, then 
> everything exists in the Global Domain.  There is no need to specify a 
> domain in any calls, since everything will default to the Global 
> domain.  The v2 API will work just fine (which knows nothing about 
> domains)
That is correct
> - If they do create some domains, then they indicate (on creation) 
> whether each of these /share/ the namespace of the Global domain, or 
> have their own /private/ namespace.
No.  Domain are non-overlapping sets.
> - If all of these new domains were specified as /shared/ then all user 
> and tenant names are still globally unique.  A caller still does not 
> technically need to specify a domain, although scoping things down to 
> a domain (or of course project) is likely for most operations (just 
> like it is today)
I fail to see the benefit.
> - If, however, some of these new domains were specified as /private/ 
> then any users who are part of a private domain must specify the 
> domain in order to authenticate.  By design, authentication will fail 
> if they don't specify a domain (since you won't exist in the global 
> domain).  Once a user in a private domain is authenticated, they are 
> scoped to that domain. [implementation: we need to work out whether 
> the domainID is encoded in the token - this is my assumption since 
> this means the Domain Name/ID is NOT required for subsequent 
> requests....and validation, by Keystone, can still be achieved ]
We are reimplementing tokens/projects here.
> - It is perfectly possible (but of course up to the Cloud Provider) to 
> support a mixture of /shared/ and /private/ domains (representing 
> different customer types)....but the point being that the Cloud 
> Provider will tell their customers how they should access they system 
> (i.e. provide them with any domain specification that may or may not 
> be required).

I think that this complicates things.  I would instead recommend that a 
provider either go with a single domain or explicit domaiuns, as mixing 
the two is wierd, but some installations will need to make their 
existing deployments work.

I like the idea that the domain will be implicit from the hostname of 
the web front end, and also possibly of a Keystone endpoint. This can be 
done with vhosts for Apache, and a simple config value for Eventlet.


>
> Very keen to hear other concerns you may have.
>
> Henry
> On 27 Oct 2012, at 21:22, Gabriel Hurley wrote:
>
>> There are various options for how Horizon can handle the UX problems 
>> associated with adding additional domains. Making it a part of the 
>> URL is one which could be supported, but I'm not inclined to make 
>> that the only method. The implementation details can be hashed out 
>> when we get there.
>> I am more concerned about the experience for CLI/API users; adding 
>> more parameters they have to pass is quite unfriendly. And I have to 
>> say that Keystone's track record for handling "default" options has 
>> been quite poor (see "default tenant"). The mixed support for lookups 
>> via ID vs. name is also a mess. There needs to be consistency around 
>> what is unique and in what scope (which is where this thread 
>> started). So far I haven't heard a concrete answer on that.
>> For example, if tenants uniqueness is scoped to a domain, and lookups 
>> via tenant name are possible, and there's a default domain... well 
>> haven't you just painted yourself into a corner where tenant names in 
>> the default domain must be unique while names in any other domain do 
>> not? It's these kinds of issues that need to really be thought through.
>> -Gabriel
>> *From:*openstack-bounces+gabriel.hurley=nebula.com at lists.launchpad.net <mailto:openstack-bounces+gabriel.hurley=nebula.com at lists.launchpad.net> 
>> [mailto:openstack-bounces+gabriel.hurley=nebula.com at lists.launchpad.net 
>> <mailto:nebula.com at lists.launchpad.net>]*On Behalf Of*Adam Young
>> *Sent:*Friday, October 26, 2012 4:19 PM
>> *To:*Henry Nash
>> *Cc:*OpenStack Development Mailing List; 
>> openstack at lists.launchpad.net <mailto:openstack at lists.launchpad.net> 
>> (openstack at lists.launchpad.net <mailto:openstack at lists.launchpad.net>)
>> *Subject:*Re: [Openstack] [keystone] Domain Name Spaces
>> On 10/26/2012 07:17 PM, Henry Nash wrote:
>>
>>     So to pick up on a couple of the areas of contention:
>>     a) Roles.  I agree that role names must stay globally unique.
>>      One way of thinking about this is that it is not actually
>>     keystone that is creating the "role name space" it is the other
>>     services (Nova etc.) by specifying roles in their policy files.
>>      Until those services support domain specific segmentation, then
>>     role names stay global.
>>     b) Will multi-domains make it more complicated in terms of
>>     authorisation - e.g. will the users have to input a Domain Name
>>     into Horizon the whole time?  The first thing I would say is that
>>     if the cloud administrator has create multiple domains, then the
>>     keystone API should indeed require the domain specification.
>>      However, that should not mean it should be laborious for a
>>     Horizon user.  In the case where a Cloud Provider has created
>>     domains to encapsulate each of their customers - then if they
>>     want to let those customer use horizon as the UI, then I would
>>     think they want to be able to give each customer a unique URL
>>     which will point to a Horizon that "knows which domain to go to".
>>
>> Yes, I think that this is the solution.  It will involve HTTPD 
>> virtual hosts, and horizon can then get an additional config 
>> parameter "keystone_domain" as part of the wsgi config.
>>
>>
>>
>>  Maybe the url contains the Domain Name or ID in the path, and 
>> Horizon pulls this out of its own url (assuming that's possible) and 
>> hence the user is never given an option to chose a domain.  A Cloud 
>> Admin would use a "non domain qualified url" to get to Horizon 
>> (basically as it is now) and hence be able to see the different 
>> domains.  Likewise, in the case of where the Cloud Provider has not 
>> chosen to create any individual domains (and is just running the 
>> cloud in the default domain), then the  "non domain qualified url" 
>> would be used to a Horizon that only showed one, default domain and 
>> hence no choice is required.
>> Henry
>> On 26 Oct 2012, at 17:31, heckj wrote:
>>
>>
>> Bringing conversation for domains in Keystone to the broader mailing 
>> lists.
>> On Oct 26, 2012, at 5:18 AM, Dolph Mathews <dolph.mathews at gmail.com 
>> <mailto:dolph.mathews at gmail.com>> wrote:
>>
>>     I think this discussion would be great for both mailing lists.
>>
>>     -Dolph
>>
>>     On Fri, Oct 26, 2012 at 5:18 AM, Henry Nash <henry.nash at mac.com
>>     <mailto:henry.nash at mac.com>> wrote:
>>     Hi
>>     <Not sure where best to have this discussion - here, as a comment
>>     to the v3api doc, or elsewhere - appreciate some guidance and
>>     will transfer this to the right place>
>>     At the Summit we started a discussion on whether things like user
>>     name, tenant name etc. should be globally unique or unique within
>>     a domain.  I'd like to widen that discussion to try and a) agree
>>     a direction, b) agree some changes to our current spec. Here's my
>>     view as an opening gambit:
>>     - When a Keystone instance is first started, there is only one,
>>     default, Domain.  The Cloud Provider does not need to create any
>>     new domains, all projects can exist in this default domain, as
>>     will the users etc.  There is one, global, name space.  Clients
>>     using the v2 API will work just fine.
>>     +1
>>
>> Very much what we were thinking for the initial implemenation and 
>> rollout to make it backwards "compatible" with the V2 (non-domain) 
>> core API
>>
>>
>>     - If the Cloud Provider wants to provide their customers with
>>     regions they can administer themselves and be self-contained,
>>     then they create a Domain for each customer.  It should be
>>     possible for users/roles to be scoped to a Domain so that
>>     (effectively) administrative duties can be delegated to some
>>     users in that Domain.  So far so good - all this can be done with
>>     the v3 API.
>>
>> Not clear on if you're referring to endpoint regions, or just 
>> describing domain isolation?
>> I believe you're describing the key use cases behind the domains 
>> mechanism to begin with - user and project partitioning to allow for 
>> administration of those to be clearly "owned" and managed appropriately.
>>
>>
>>     - We still have work to do to make sure items in other OS
>>     projects that reference tenants (e.g. Images) can take a Domain
>>     or Project ID, but we'll get to that soon enough
>>
>> Everything will continue to work with projects, but once middleware 
>> starts providing a DOMAIN_ID and DOMAIN_NAME to the underlying 
>> service, it'll be up to them to take advantage of it. Images per 
>> domain is an excellent example use case.
>>
>>
>>         - However, Cloud Providers want to start enabling enterprise
>>         customers to run more and more of the workloads in OpenStack
>>         clouds - over and above, the smaller sized companies that are
>>         doing this today.  For this to work, the encapsulation of a
>>         Domain need, I think, to be able to be stricter - and this is
>>         where the name space comes into play.  I think we need to
>>         allow for a Domain to have its own namespace (i.e. users,
>>         roles, projects etc.) as an option.  I see this as a first
>>         step to allowing each Domain to have its own AuthZ/N service
>>         (.e.g external ldap owned and hosted by the customer who will
>>         be using the Domain)
>>         Implementation:
>>         - A simplistic version would just allow a flag to specified
>>         on Domain creation that said whether this a "private" or
>>         "shared" Domain.  Shared would use the current global name
>>         space (and probably be the default for compatibility reasons).
>>
>>     I like the direction of this -- need to digest implications :)
>>
>> I like the idea conceptually - but let's be clear on the implications 
>> to the end users:
>> Where we're starting is preserving a global name space for project 
>> names and user names. Allowing a mix of segregated and global name 
>> spaces imposes a burden of additional data being needed to uniquely 
>> place authentication and authorization.
>> We've been keeping to 2 key pieces of info (username, password) to 
>> get authenticated - and then (via CLI or Horizon dashboard) you can 
>> choose from a list of protential projects and carry on. In most 
>> practical circumstances, any user working primarily from the CLI is 
>> already providing 3-4 pieces of information:
>> * username
>> * password
>> * tenant name
>> * auth_url
>> to access and use the cloud.
>> By allowing domains to be their own namespaces, we're adding another 
>> element that will be absolutely required to identify the person 
>> authenticating:
>>  * domain name
>> implying a cascade of changes to the user experience all the way down 
>> through horizon.
>>
>>
>>     - A more flexible approach would be to allow the specification of
>>     where the various sub-services of Keystone (e.g. AuthN/Z, Service
>>     Catalogue, Resources (i.e Users, Projects)) are hosted.  The
>>     defaults would all point back to the default domain (i.e. are
>>     global and shared), but instead could be specified as "self"
>>     (I.e. the new Domain), or, in the future, some other external
>>     location, e.g. for a remote ldap.
>>     - As an aside, this multi-name space model could also allow the
>>     Cloud Provider their own name space, separate from their
>>     customers - i.e. they will have a need to create admins who can
>>     just create domains and on-board customers into those domains.
>>      These users & roles could exist in the default domain, while all
>>     the customers' users/roles exist solely within their own domains.
>>     - One potential problem I do see is with roles.  Today, the role
>>     name is, if I understand it correctly, a kind of shared secret
>>     between, other services and Keystone - e.g. it is the actual name
>>     of a given role, say "ProjectAdmin" , that must match in, say,
>>     the Nova policy file and the role assignment in Keystone (please
>>     correct me if I have this wrong).
>>
>> You're 100% correct.
>>
>>     How would that work if the role names were not unique across Domains?
>>
>> Not that we would want admins to ever see Role ID's, or edit policy 
>> files with role ID's, but they provide a potential solution.
>> The different role names would need to be accounted for in the policy 
>> files the way they're set up today - the enforcement there is all at 
>> the service level. There's no current provision for evaluating policy 
>> differently based on domain. While that's possible, it sounds like a 
>> tremendous cascade of additional complication, as the policy, and 
>> roles, are all set up and managed by deployers.
>> I think this might be an interesting addition in the future, but want 
>> to keep the initial implementation and roll-out of the policy 
>> mechanisms and domains consistent and simple for a first roll-out 
>> iteration.
>>
>>         What is the desired functionality for a Cloud Provider
>>         wanting to give their enterprise customers this level of
>>         flexibility - will they have dedicated Nova endpoints anyway?
>>          Sounds too rigid.  This might tie into another bp we are
>>         working on at IBM in terms of using Availability zones to
>>         allow Cloud Providers to divide up their compute resources in
>>         a more flexible way.
>>         - Finally, I wanted to raise the subject of whether we should
>>         make it a goal to remain compatible with the v2 API/once the
>>         cloud provider starts creating additional domains/.
>>
>>     Joe and I briefly discussed this at the summit. As a migration to
>>     v3, we'd obviously be creating the default domain and mapping all
>>     existing users/projectse/etc to it. I'd be fine if the v2
>>     implementation ONLY interacted with resources in that default
>>     domain; i.e. if you want to use domains, upgrade to a v3 client.
>>
>>         As stated above, if just the default domain is being used,
>>         then fine.  And while I agree that, technically, the v2 API
>>         should still work with the above if all the other domains
>>         point back to the default domain for their sub-services - it
>>         feels overly flexible (and maybe wrong conceptually) to
>>         support v2 semantics across a multi-domain installation.
>>
>>     +1
>>
>>         Interested in everyone else's view.
>>         Henry
>>
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp

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