On 12/07/2015 05:47 AM, Jay Pipes wrote:
Sorry, I guess I wasn't clear. I was not proposing to put all controller services in a single container. I was proposing simply to build the various container sets (nova-conductor, nova-api, etc) with the updated code for that service and then "flip the target IP or port" for that particular service from the existing container set's VIP to the new/updated container set's VIP.
That idea may work if the new containers will be running on the other nodes. That's because in Kolla we're not using network namespaces and we do net=host instead. So all the API services are bound directly to the host's net interface.
Of course we might try to use namespaces with default random port mapping, autodiscover OpenStack services and then your idea would be perfect. It would be great IMO and I'm +1 for that. But it would require a lot of work related with Marathon API and/or ZooKeeper usage. I'm not sure what the other folks would think about that and whether it's "doable" in Mitaka release. I also don't have a concrete imagination how Keystone service catalog would work in this model.
In Kubernetes-speak, you would create a new Pod with containers having the updated Nova conductor code, and would set the new Pod's selector to something different than the existing Pod's selector -- using the Git SHA1 hash for the selector would be perfect... You would then update the Service object's selector to target the new Pod instead of the old one. Or, alternately, you could use Kubernetes' support for rolling updates [1] of a service using a ReplicationController that essentially does the Pod and Service orchestration for you.
Mesos+Marathon has its upgrade scenario and it seems to be almost the same you're proposing in the first paragraph.
https://mesosphere.github.io/marathon/docs/deployment-design-doc.html Regards, Michal __________________________________________________________________________ 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
