On Thu, Mar 16, 2017 at 5:54 PM, Fox, Kevin M <kevin....@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 [lbrags...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
