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 [[email protected]] 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 [[email protected]] > 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 > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
