Re: [openstack-dev] [horizon] Purpose of SetDomainContext / UnsetDomainContext button
On 13-12-08 12:07 AM, Lyle, David wrote: The set domain context functionality is for operators (admins) to refine the context that they are working in/viewing. Admins can limit the scope of identity visibility to one domain, rather than having to sort through the exhaustive lists of projects, users, and groups. If you are adding multiple users with the admin role, they will still have visibility across domains. They will be able to see all instances, volumes, networks, etc. Currently, the domain scoping is only implemented for the identity management panel group. The intention is to extend the scoping to services beyond keystone as well. But even once that's implemented, any user with the admin role will be able to view/modify any instance, volume, network, etc., via the CLI. The functionality you are looking for is a way to view things as a domain admin. The domain admin role does not explicitly exist in OpenStack. It needs to, but does not. If implemented, a user with domain admin capabilities would not have the admin role and see entities in their domain much like what is seen in the current project dashboard. There are several Horizon blueprints in Icehouse to add RBAC support for the integrated services and consolidate the project and admin dashboards. Once those are implemented, then creating a domain admin role and modifying the policy.json files Horizon uses would allow the behavior you desire -- assuming you are using a policy.json file for keystone that also supports a domain admin role. This will look very much like the identity management panel group does today when the domain context is set. -David Lyle -Original Message- From: Paul Belanger [mailto:paul.belan...@polybeacon.com] Sent: Saturday, December 07, 2013 7:49 PM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [horizon] Purpose of SetDomainContext / UnsetDomainContext button Greetings, I recently enabled multi-domain support on my dashboard and noticed a new domain context button. I was actually surprised to see I had to manually toggle the functionality to set the domain context, hiding domain foo resources from domain bar. My question is simple, what is the purpose of this functionality? For me, if I setup admins in 2 different domains, I don't want them to actually see the resources of the other, asking them to click said button seems to defeat the purpose. Right now, I am attempting to setup a configuration file settings that will force the domain_context to be setup on login, hence hiding external domain resources by default. But like I asked, trying to better understand the use case of the current functionality. Correct, I am in-fact trying to get 'domain admins' setup using horizon. Right now I've been struggling to get the policy.v3cloudsample.json[1] to properly work in keysone, let alone horizon. Because I was struggling with that, I was next focusing on the 'domain context' functionality in horizon to see if I could limit functionality. [1] https://github.com/openstack/keystone/blob/master/etc/policy.v3cloudsample.json -- Paul Belanger | PolyBeacon, Inc. Jabber: paul.belan...@polybeacon.com | IRC: pabelanger (Freenode) Github: https://github.com/pabelanger | Twitter: https://twitter.com/pabelanger ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon] Purpose of SetDomainContext / UnsetDomainContext button
The set domain context functionality is for operators (admins) to refine the context that they are working in/viewing. Admins can limit the scope of identity visibility to one domain, rather than having to sort through the exhaustive lists of projects, users, and groups. If you are adding multiple users with the admin role, they will still have visibility across domains. They will be able to see all instances, volumes, networks, etc. Currently, the domain scoping is only implemented for the identity management panel group. The intention is to extend the scoping to services beyond keystone as well. But even once that's implemented, any user with the admin role will be able to view/modify any instance, volume, network, etc., via the CLI. The functionality you are looking for is a way to view things as a domain admin. The domain admin role does not explicitly exist in OpenStack. It needs to, but does not. If implemented, a user with domain admin capabilities would not have the admin role and see entities in their domain much like what is seen in the current project dashboard. There are several Horizon blueprints in Icehouse to add RBAC support for the integrated services and consolidate the project and admin dashboards. Once those are implemented, then creating a domain admin role and modifying the policy.json files Horizon uses would allow the behavior you desire -- assuming you are using a policy.json file for keystone that also supports a domain admin role. This will look very much like the identity management panel group does today when the domain context is set. -David Lyle > -Original Message- > From: Paul Belanger [mailto:paul.belan...@polybeacon.com] > Sent: Saturday, December 07, 2013 7:49 PM > To: OpenStack Development Mailing List (not for usage questions) > Subject: [openstack-dev] [horizon] Purpose of SetDomainContext / > UnsetDomainContext button > > Greetings, > > I recently enabled multi-domain support on my dashboard and noticed a > new domain context button. I was actually surprised to see I had to > manually toggle the functionality to set the domain context, hiding > domain foo resources from domain bar. > > My question is simple, what is the purpose of this functionality? For > me, if I setup admins in 2 different domains, I don't want them to > actually see the resources of the other, asking them to click said > button seems to defeat the purpose. > > Right now, I am attempting to setup a configuration file settings that > will force the domain_context to be setup on login, hence hiding > external domain resources by default. > > But like I asked, trying to better understand the use case of the > current functionality. > > -- > Paul Belanger | PolyBeacon, Inc. > Jabber: paul.belan...@polybeacon.com | IRC: pabelanger (Freenode) > Github: https://github.com/pabelanger | Twitter: > https://twitter.com/pabelanger > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [horizon] Purpose of SetDomainContext / UnsetDomainContext button
Greetings, I recently enabled multi-domain support on my dashboard and noticed a new domain context button. I was actually surprised to see I had to manually toggle the functionality to set the domain context, hiding domain foo resources from domain bar. My question is simple, what is the purpose of this functionality? For me, if I setup admins in 2 different domains, I don't want them to actually see the resources of the other, asking them to click said button seems to defeat the purpose. Right now, I am attempting to setup a configuration file settings that will force the domain_context to be setup on login, hence hiding external domain resources by default. But like I asked, trying to better understand the use case of the current functionality. -- Paul Belanger | PolyBeacon, Inc. Jabber: paul.belan...@polybeacon.com | IRC: pabelanger (Freenode) Github: https://github.com/pabelanger | Twitter: https://twitter.com/pabelanger ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
