On 11/3/15, 2:27 PM, "Zane Bitter" <zbit...@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-requ...@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 > __________________________________________________________________________ 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