[openstack-dev] [kolla][tripleo] Mesos orchestration as discussed at mid cycle (action required from core reviewers)

Zane Bitter zbitter at redhat.com
Mon Nov 9 17:16:56 UTC 2015


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




More information about the OpenStack-dev mailing list