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.
> 
> 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.

Where I think it gets really interesting is to be able to auto-scale
controller services (think nova-api based on request latency) in small
increments just you'd expect to be able to manage a scale-out app on a
cloud.

i.e. our overcloud Heat stack would allocate some baremetal machines,
but then just schedule the controller services to run in small
containers (or VMs) on any of those machines, and then have them
auto-scale.

> 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

I'm not sure that would need to change.

>  - 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.

That's tricky because your undercloud Nova DB/conductor needs to be
available for the machine to know what services it's supposed to be
running. It sounds like a reasonable thing to want even for standard KVM
compute nodes too, though.

>  - 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.

Yes.

Mark.