Tiwari, Could you elaborate how to solve the issue by using unique role names ? With domain model, services like nova have to be aware of domain admin user and cloud admin user by roles. domain admin manage IAM resources and non-IAM resources by inheriting roles to projects, cloud admin have additional privilege to enable/disable OpenStack services. But the "admin" role can be granted by a domain user to its own user. How nova api identity a user is real admin user that in admin domain?
2014-05-10 2:23 GMT+08:00 Tiwari, Arvind <arvind.tiw...@hp.com>: > Hi All, > > > > Thanks for looking in to my proposal. Below are my comments and answers to > questions which is based on “my personal opinion”. > > > > *Why domain hierarchy, why not project hierarchy? *Because project > hierarchy is more impactful and need cross project changes. > > > > As per my understanding we all are trying to solve one business use > problem, which is “how to support VPC or Reseller” model on OS based cloud > deployment. As per problem described in different proposals, it is purely > a IAM use case, where different identities (users, admins, reseller ….) has > different perception about the system/resources (IAM and non IAM) and they > want ability to manage them. > > > > Keystone (OS IAM service) abstracts all the IAM complexity from lower > level services (Nova, Swift, cinder …) by providing unified integration > model (auth token and verification by auth middleware). Lover level > services trusts Keystone and allow access (for particular requests) to > actual resource based on subject’s roles provided by keystone. > > > > Each service supports multi tenancy and tenancy mapping is establish by > keystone through projects. If hierarchy enforced at project level then we > need to propagate the hierarchy info to all lower level services, where the > hierarchy info is not serving any good purpose but just used to map one > tenant. Enforcing the hierarchy at project level is more impactful because > all services have to change their implementation to consume the notion of > hierarchy. Propagating project hierarchy to services would make sense if > end resources (VMs, cinder volumes , swift resource ….) does obey the > hierarchy based on projects, I think that is not the case. > > > > As per definition domains are container for projects, users and groups and > maps well with a business entities (ProductionIT, SuperDevShop, > WidgetMaster, SPI, reseller .....). Using domain to establish hierarchy (as > per my design) will abstract the complexity from lower level services. > Services don’t have to worry about the domain hierarchy and we can retain > the current integration (Keystone project <-> service Tenant ) model and no > need to make big change in different service. Mostly one place change which > is Keystone. > > > > *Services has to be domain aware* > > > > IMO services (Nova, Swift …) don’t have to be domain aware (Unless I am > missing something) as they manage resources for keystone projects. Domain > is IAM concept which used to scope IAM resources and not very useful for > end services. I think what we are lacking is unique role (role name) per > service, having unique role names for each service (IAM, Nova, Swift ….) > will resolve the problem mentioned below by Yaguang Tang. > > > > Please let me know why services have to be domain aware? > > > > Thoughts? > > > > Thanks, > > Arvind > > > > Note: > > IAM Resources – Users, groups, projects … > > Non IAM resources – VMs, Swift objects, ……. > > > > *From:* Yaguang Tang [mailto:yaguang.t...@canonical.com] > *Sent:* Friday, May 09, 2014 4:33 AM > *To:* OpenStack Development Mailing List (not for usage questions) > > *Subject:* Re: [openstack-dev] Hierarchical administrative boundary > [keystone] > > > > *Frittoli,* > > > > I think for other services we could achieve that by modifying the > policy.json( add domain admin role and control what the cloud admin can do > ) so that domain admin user is able to manage resources belong to > > users and projects in that domain. > > > > 2014-05-09 15:24 GMT+08:00 Frittoli, Andrea (HP Cloud) <fritt...@hp.com>: > > *From:* Adam Young [mailto:ayo...@redhat.com] > *Sent:* 09 May 2014 04:19 > *To:* openstack-dev@lists.openstack.org > *Subject:* Re: [openstack-dev] Hierarchical administrative boundary > [keystone] > > > > On 05/08/2014 07:55 PM, Tiwari, Arvind wrote: > > Hi All, > > > > Below is my proposal to address VPC use case using hierarchical > administrative boundary. This topic is scheduled in Hierarchical > Multitenancy<http://junodesignsummit.sched.org/event/20465cd62e9054d4043dda156da5070e#.U2wYXXKLR_9>session > of Atlanta design summit. > > > > https://wiki.openstack.org/wiki/Hierarchical_administrative_boundary > > > > Please take a look. > > > > Thanks, > > Arvind > > > > > > _______________________________________________ > > OpenStack-dev mailing list > > > > OpenStack-dev@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > Looks very good. One question: Why hierarchical domains and not > Projects. I'm not disagreeing, mind you, just that I think the Nova team > is going for hierarchical Projects. > > > * ------------------------------ * > > Looks good, thank you! > > > > But for this to be even more interesting nova (and other services) should > be domain aware – e.g. so that a domain admin could have control on all > resources which belong to users and projects in that domain. > > > > andrea > > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > -- > > Tang Yaguang > > > > Canonical Ltd. | www.ubuntu.com | www.canonical.com > > Mobile: +86 152 1094 6968 > > gpg key: 0x187F664F > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Tang Yaguang Canonical Ltd. | www.ubuntu.com | www.canonical.com Mobile: +86 152 1094 6968 gpg key: 0x187F664F
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
