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. __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
