Open Stack

Today which machine a Vm runs on is determined by Nova-Scheduler based on resource availability and
meeting end user specified constraints (such as memory, number of vCPUs etc). The end-user should not care if the VM is migrated to another similar machine due to maintenance reasons (applying software patches, de-commissioning a physical machine etc). Any activity that is parallel to this would be management, a cloud super-user related activity ? It would be something the super user would embark upon regardless of
domain bounds.  Also something a super-user might undertake on a domain de-activate.

This would be regardless of allowing end-users  to request migration of their VM (to a cheaper machine? More reliable machine?)

Malini

From: Dolph Mathews [mailto:dolph.mathews at gmail.com]
Sent: Monday, April 22, 2013 5:39 PM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [keystone] Inherited domain roles

What makes any of those management-only capabilities? That seems like a deployment decision.

-Dolph

On Mon, Apr 22, 2013 at 4:28 PM, Bhandaru, Malini K <malini.k.bhandaru at intel.com<mailto:malini.k.bhandaru at intel.com>> wrote:
To address the cloud super (admin) -user issue (as opposed to this BP that address trickle down roles for the domain admin user),
Does it make sense to create a keystone-token of sub-type cloud-super-user, that provides management only capabilities such as
VM-migrate, shutdown etc, (de)activating a domain etc. While there are still roles and groups, for both kinds of tokens, there is no way that logged in with one set of credentials gives you access to the other set (as opposed to today's being logged in as admin, you can see user functionality).

Malini

From: Gabriel Hurley [mailto:Gabriel.Hurley at nebula.com<mailto:Gabriel.Hurley at nebula.com>]
Sent: Monday, April 22, 2013 12:09 PM

To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [keystone] Inherited domain roles

Depends on the interpretation of "[...]that of the lack of a "super user admin role"." Could go either way. As I said, I don't have any explicit problem with "trickle down" roles.


-        Gabriel

From: Dolph Mathews [mailto:dolph.mathews at gmail.com]
Sent: Monday, April 22, 2013 11:53 AM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [keystone] Inherited domain roles

Hmm, I didn't understand the solution to be addressing the "cloud admin" problem, but rather to simply make it trivial for a user with an admin role at the domain level (which cascades to projects owned by that domain) to administer resources across openstack using a single role assignment in keystone. So, when a domain admin creates a project, they inherently have a role on that project and can immediately work with it.

-Dolph

On Mon, Apr 22, 2013 at 11:36 AM, Gabriel Hurley <Gabriel.Hurley at nebula.com<mailto:Gabriel.Hurley at nebula.com>> wrote:
The BP solves *a* problem in a valid way; I've even suggested that roles should "trickle down" when discussing ideas such as hierarchical projects/tenants in the past. However, it still doesn't solve the problem that at some point you need a single source of truth from which authority over keystone/cloud administration originates.

Any solution which involves a user gaining power on the cloud outside of the scope on which the role was assigned (e.g. a "cloud admin" being empowered by granting an admin role on a domain, or on a project like it is now) is fundamentally flawed.

+1; I think this is a step towards enabling us to eliminate that flaw.

The notion of scope is fundamentally broken by that. Roles should only ever apply within the scope they're granted.

So, +0 on the BP, but I don't see it fixing the larger problem.

All the best,

    - Gabriel

> -----Original Message-----
> From: Henry Nash [mailto:henryn at linux.vnet.ibm.com<mailto:henryn at linux.vnet.ibm.com>]
> Sent: Sunday, April 21, 2013 10:42 AM
> To: OpenStack Development Mailing List
> Cc: Gabriel Hurley
> Subject: [keystone] Inherited domain roles
>
> Hi
>
> I have posted a havana blueprint for an extension to domain roles that would
> solve one of the issues that has arisen by the move to RBAC in the keystone
> v3 identity API - that of the lack of a "super user admin role".  This proposal
> attempts to solve the actual issue within RBAC, rather than simply recreating
> such a super admin.
>
> https://blueprints.launchpad.net/keystone/+spec/inherited-domain-roles
>
> Comments welcome.
>
> Henry



_______________________________________________
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130423/6a902b25/attachment-0001.html>