Open Stack

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