[openstack-dev] [TripleO] Summit session wrapup

Robert Collins robertc at robertcollins.net
Thu Nov 28 06:04:55 UTC 2013


On 28 November 2013 09:54, Mark McLoughlin <markmc at redhat.com> wrote:

> We take away an awful lot of placement control away from the
> self-service in order to allow the operator to provide a usable,
> large-scale, multi-tenant service.
>
> The difference with TripleO is that we assume the undercloud operator
> and the undercloud user are one and the same. At least, that's what I
> assume we're designing for. I don't think we're designing for a
> situation where there is an undercloud operator serving the needs of
> multiple overcloud operators and it's important for the undercloud
> operator to have ultimate control over placement.

I think many organisations will have them be the same, and we should
indeed optimise for that.

But....

Several organisations have had discussions with Devananda and myself
(sometimes even at the same time! :)) about running multi-tenant
baremetal clouds. For instance, datacentre operators may want to run
infrastructure and let their clients run public clouds. There's
obviously a bunch of work needed to have baremetal multi-tenancy be a
sane thing, but I think TripleO needs to fit for these cases as well -
eventually. All we need to do about this today is to be clear that
folk deploying clouds - overcloud operators - should only need regular
tenant privs on the undercloud, vs being undercloud admins.

> That's hardly the end of the story here, but it is one useful
> distinction that could justify why this case might be different from the
> usual application-deployment-on-IaaS case.
>



> But yeah - my instinct is that all of that would show that we'd be
> fighting an uphill battle to persuade our users that this type of magic
> is what they want.

Radical idea : we could ask (e.g. on -operators) for a few potential
users who'd be willing to let us interview them.

-Rob



-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud



More information about the OpenStack-dev mailing list