Open Stack

On Tue, 2013-12-10 at 09:40 +1300, Robert Collins wrote:
> On 6 December 2013 14:11, Fox, Kevin M <kevin.fox at 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