On 04/11/15 16:26, Michal Rostecki wrote:
On 11/03/2015 10:27 PM, Zane Bitter wrote:
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...
One of the goals of Kolla (and idea of containerizing OpenStack services
in general) is to simplify upgrades. Scaling and scheduling are
obviously important points of Kolla, but they are not the only.
The model of upgrade where images of nova-compute, Neutron agents etc.
are build once, pushed to registry and then pulled on compute nodes
looks much better for me than traditional upgrade of packages. It also
may decrease probability of breaking some common dependency during
upgrades.
I don't disagree with any of that, but I'm struggling to figure out how
it has anything to do with what I wrote. Did you accidentally reply to
the wrong message?
- ZB
__________________________________________________________________________
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