On Tue, 2013-12-10 at 09:40 +1300, Robert Collins wrote: > On 6 December 2013 14:11, Fox, Kevin M <kevin....@pnnl.gov> 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. > > > > 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. > > This is a super interesting discussion - thanks for kicking it off.
Indeed. A very enlightening conversation :) > I think it would be fantastic to be able to use containers for > deploying the cloud rather than full images while still running > entirely OpenStack control up and down the stack. > > Briefly, what we need to be able to do that is: > > - the ability to bring up an all in one node with everything on it to > 'seed' the environment. > - we currently do that by building a disk image, and manually > running virsh to start it Is this set in stone? In other words, is it a given that in order to create the seed undercloud, that you need to use DIB to do it? Instead of an image that is pre-constructed and virsh'd into, what about constructing one or more LXC templates, starting a set of LXC containers for the various undercloud support services (db, mq, OpenStack services, etc), installing those support services using config-mgmt-flavor-du-jour? Has this been considered as an option to DIB? (sorry if I'm late to the discussion!) :) > - the ability to reboot a machine *with no other machines running* - > we need to be able to power off and on a datacentre - and have the > containers on it come up correctly configured, networking working, > running etc. I think a container-based seed would work just fine here, yes? > - we explicitly want to be just using OpenStack APIs for all the > deployment operations after the seed is up; so no direct use of lxc or > docker or whathaveyou. Agreed. I'm talking about changing the thinking of the construction of the seed undercloud, not the overcloud. Best, -jay _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
