Open Stack

I think an obvious first step of domain support outside keystone is for images.  Today, I believe, an image can be global or project based.  There is definitely a use case for a third state of being domain based - and hence available to all projects in that domain, but not to those in other domains.

From a Nova perspective, where domains might be relevant is in how a cloud provider divides up their infrastructure, for example, I think there are use cases for when a cloud provider might want to specify on a domain-basis:
- availability zones and/or host aggregates
- quotas
- IP ranges (ok, maybe a quantum discussion)

Henry
On 1 Oct 2013, at 06:45, Dolph Mathews <dolph.mathews at gmail.com> wrote:

> 
> On Mon, Sep 30, 2013 at 11:42 PM, Christopher Yeoh <cbkyeoh at gmail.com> wrote:
> Hi,
> 
> I've been looking into how Nova might support Keystone V3 domains and I'm having a bit of trouble getting my head around exactly how we'd use domain scoped tokens.
> 
> With the V3 Nova API we no longer specify the tenant id in the url as it is implicit in the token used to authorize with. This is true for Keystone V3  tenant scoped tokens, but not for domain scoped tokens.  If we're going to use domain scoped tokens with the Nova API is the idea that a client would pass the tenant id in a header as well as the domain scoped token and Nova would check that the tenant passed belongs to the domain that is implicit with the token?
> 
> Without a specific use case to support domain-based operations, I'd be opposed to handling this scenario "implicitly." I have yet to hear a use case for domain awareness in nova, so I'd expect nova to return a 401 for any domain-based token.
>  
> 
> Also, should we be updating the Nova policy code to be able to handle domains?
> 
> Keystone supports domain-based authorization on two levels: domain-specific role assignments and domain-specific role assignments that are inherited to all projects/tenants owned by that domain.
> 
> With inheritance, a domain administrator can request authorization on any project in the domain (from keystone, per usual) and nova's policy doesn't have to handle anything special (it'll just be a regular project/tenant scoped token).
>  
>  
> 
> Regards,
> 
> Chris
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> 
> -- 
> 
> -Dolph
> _______________________________________________
> 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/20131001/9fbdd691/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131001/9fbdd691/attachment-0001.pgp>