Open Stack

On 02/11/15 18:33, Steven Dake (stdake) wrote:
>
> Blame the core team :)  I suspect you will end up retrying a lot of
> patterns we tried and failed with Kubernetes.  Kubernetes eventually was
> found to be non-viable by the delivery of this 2 week project:
>
> https://github.com/sdake/compute-upgrade
>
> Documented in this blog:
>
> http://sdake.io/2015/01/28/an-atomic-upgrade-process-for-openstack-compute-nodes/

I don't recognise half of the names of tools y'all have been talking 
about here, but I can't help wondering whether the assumption that 
exactly one of these tools has to do all of the things has gone 
unchallenged.

I think we all agree that using something _like_ Kubernetes would be 
extremely interesting for controller services, where you have a bunch of 
heterogeneous services with scheduling constraints (HA), that may need 
to be scaled out at different rates, &c. &c.

IMHO it's not interesting at all for compute nodes though, where the 
scheduling is not only fixed but well-defined in advance. (It's... one 
compute node per compute node. Duh.)

e.g. I could easily imagine a future containerised TripleO where the 
controller services were deployed with Magnum but the compute nodes were 
configured directly with Heat software deployments.

In such a scenario the fact that you can't use Kubernetes for compute 
nodes diminishes its value not at all. So while I'm guessing net=host is 
still a blocker (for Neutron services on the controller - although 
another message in this thread suggests that K8s now supports it 
anyway), I don't think pid=host needs to be since AFAICT it appears to 
be required only for libvirt.

Something to think about...

cheers,
Zane.