Open Stack

On 11/3/15, 2:27 PM, "Zane Bitter" <zbitter at redhat.com> wrote:

>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-comput
>>e-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-request at lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Zane,

Not necessarily disagreeing with you that running the controller nodes
under a high-powered orchestration system and the compute nodes under some
other simple orchestration system (such as bash:) might be simpler, I
think what people do desire is one tool to rule them all (in this case
Mesos).  Running with Ansible does offer a tidy upgrade execution
environment for compute nodes.  This could be done without ansible/mesos
on those nodes, but it would be a bespoke solution specific to the problem
at hand.

Regards
-steve

>