Open Stack

I'm thinking more generic:

The cloud provider will provide one or more "suballocating" images. The one Triple O uses to take a bare metal node and make vm's available would be the obvious one to make available initially. I think that one should not have a security concern since it is already being used in that way safely.

I think a docker based one shouldn't have the safety concern either, since I think docker containerizes network resources too? I could be wrong though.

Thanks,
Kevin

________________________________________
From: Keith Basil [kbasil at redhat.com]
Sent: Monday, December 09, 2013 8:50 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Nova][TripleO] Nested resources

On Dec 5, 2013, at 8:11 PM, Fox, Kevin M wrote:

> I think the security issue can be handled by not actually giving the underlying resource to the user in the first place.
>
> So, for example, if I wanted a bare metal node's worth of resource for my own containering, I'd ask for a bare metal node and use a "blessed" image that contains docker+nova bits that would hook back to the cloud. I wouldn't be able to login to it, but containers started on it would be able to access my tenant's networks. All access to it would have to be through nova suballocations. The bare resource would count against my quotas, but nothing run under it.
>
        So this would be an extremely light weight hypervisor alternative, then?

        It's interesting because "bare-metal-to-tenant" security issues are tricky
        to overcome.

        -k

> Come to think of it, this sounds somewhat similar to what is planned for Neutron service vm's. They count against the user's quota on one level but not all access is directly given to the user. Maybe some of the same implementation bits could be used.
>
> Thanks,
> Kevin
> ________________________________________
> From: Mark McLoughlin [markmc at redhat.com]
> Sent: Thursday, December 05, 2013 1:53 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Nova][TripleO] Nested resources
>
> Hi Kevin,
>
> On Mon, 2013-12-02 at 12:39 -0800, Fox, Kevin M wrote:
>> Hi all,
>>
>> I just want to run a crazy idea up the flag pole. TripleO has the
>> concept of an under and over cloud. In starting to experiment with
>> Docker, I see a pattern start to emerge.
>>
>> * As a User, I may want to allocate a BareMetal node so that it is
>> entirely mine. I may want to run multiple VM's on it to reduce my own
>> cost. Now I have to manage the BareMetal nodes myself or nest
>> OpenStack into them.
>> * As a User, I may want to allocate a VM. I then want to run multiple
>> Docker containers on it to use it more efficiently. Now I have to
>> manage the VM's myself or nest OpenStack into them.
>> * As a User, I may want to allocate a BareMetal node so that it is
>> entirely mine. I then want to run multiple Docker containers on it to
>> use it more efficiently. Now I have to manage the BareMetal nodes
>> myself or nest OpenStack into them.
>>
>> I think this can then be generalized to:
>> As a User, I would like to ask for resources of one type (One AZ?),
>> and be able to delegate resources back to Nova so that I can use Nova
>> to subdivide and give me access to my resources as a different type.
>> (As a different AZ?)
>>
>> I think this could potentially cover some of the TripleO stuff without
>> needing an over/under cloud. For that use case, all the BareMetal
>> nodes could be added to Nova as such, allocated by the "services"
>> tenant as running a nested VM image type resource stack, and then made
>> available to all tenants. Sys admins then could dynamically shift
>> resources from VM providing nodes to BareMetal Nodes and back as
>> needed.
>>
>> This allows a user to allocate some raw resources as a group, then
>> schedule higher level services to run only in that group, all with the
>> existing api.
>>
>> Just how crazy an idea is this?
>
> FWIW, I don't think it's a crazy idea at all - indeed I mumbled
> something similar a few times in conversation with random people over
> the past few months :)
>
> With the increasing interest in containers, it makes a tonne of sense -
> you provision a number of VMs and now you want to carve them up by
> allocating containers on them. Right now, you'd need to run your own
> instance of Nova for that ... which is far too heavyweight.
>
> It is a little crazy in the sense that it's a tonne of work, though.
> There's not a whole lot of point in discussing it too much until someone
> shows signs of wanting to implement it :)
>
> One problem is how the API would model this nesting, another problem is
> making the scheduler aware that some nodes are only available to the
> tenant which owns them but maybe a bigger problem is the security model
> around allowing a node managed by an untrusted become a compute node.
>
> Mark.
>
>
> _______________________________________________
> OpenStack-dev mailing list
> 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
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev