Open Stack

Lance,

I had understood that the resellers was about having users/groups at the different points in the tree.

I think the basic resource management is being looked at as part of the nested quotas functionality. For CERN, we’d look to delegate the quota and roles management but not support sub-tree user/groups.

Tim

From: Lance Bragstad <lbragstad at gmail.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>
Date: Friday, 17 March 2017 at 00:23
To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [keystone][all] Reseller - do we need it?


On Thu, Mar 16, 2017 at 5:54 PM, Fox, Kevin M <Kevin.Fox at pnnl.gov<mailto:Kevin.Fox at pnnl.gov>> wrote:
At our site, we have some larger projects that would be really nice if we could just give a main project all the resources they need, and let them suballocate it as their own internal subprojects needs change. Right now, we have to deal with all the subprojects directly. The reseller concept may fit this use case?

Sounds like this might also be solved by better RBAC that allows real project administrators to control their own subtrees. Is there a use case to limit visibility either up or down the tree? If not, would it be a nice-to-have?


Thanks,
Kevin
________________________________
From: Lance Bragstad [lbragstad at gmail.com<mailto:lbragstad at gmail.com>]
Sent: Thursday, March 16, 2017 2:10 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [keystone][all] Reseller - do we need it?
Hey folks,

The reseller use case [0] has been popping up frequently in various discussions [1], including unified limits.

For those who are unfamiliar with the reseller concept, it came out of early discussions regarding hierarchical multi-tenancy (HMT). It essentially allows a certain level of opaqueness within project trees. This opaqueness would make it easier for providers to "resell" infrastructure, without having customers/providers see all the way up and down the project tree, hence it was termed reseller. Keystone originally had some ideas of how to implement this after the HMT implementation laid the ground work, but it was never finished.

With it popping back up in conversations, I'm looking for folks who are willing to represent the idea. Participating in this thread doesn't mean you're on the hook for implementing it or anything like that.

Are you interested in reseller and willing to provide use-cases?



[0] http://specs.openstack.org/openstack/keystone-specs/specs/keystone/mitaka/reseller.html#problem-description

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe<http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
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/20170317/cf6c49a9/attachment.html>