[openstack-dev] [heat] Rolling Upgrades

Grasza, Grzegorz grzegorz.grasza at intel.com
Mon Oct 24 08:18:14 UTC 2016


> From: Crag Wolfe [mailto:cwolfe at redhat.com]
> 
> On 10/20/2016 09:30 PM, Rabi Mishra wrote:
> > Thanks Crag on starting the thread. Few comments inline.
> >
...
> >
> >     For RPC changes, we don't have a great solution right now (looking
> >     specifically at heat/engine/service.py). If we add a field, an older
> >     running heat-engine will break if it receives a request from a newer
> >     running heat-engine. For a relevant example, consider adding the
> >     "root_id" as an argument (
> >     https://review.openstack.org/#/c/354621/13/heat/engine/service.py
> >     <https://review.openstack.org/#/c/354621/13/heat/engine/service.py>
> ).
> >
> >     Looking for the simplest solution -- if we introduce a mandatory
> >     "future_args" arg (a dict) now to all rpc methods (perhaps provide a
> >     decorator to do so), then we could follow this pattern post-Ocata:
> >
> >     legacy release: accepts the future_args param (but does nothing with
> >     it).
> >     release+1: accept the new parameter with a default of None,
> >                pass the value of the new parameter in future_args.
> >     release+2: accept the new parameter, pass the value of the new
> parameter
> >                in its proper placeholder, no longer in future_args.
> >
> > This is something similar to the one is being used by neutron for the
> > agents, i.e consistently capturing those new/unknown arguments with
> > keyword arguments and ignoring them on agent side; and by not
> > enforcing newer RPC entry point versions on server side. However,
> > this makes the rpc api less strict and not ideal.
> >
> 
> I'm not sure what the definition of ideal is here. But, full disclaimer is that I've
> thought about RPC a lot less than the DB side. :-)
> 
> FWIW, we might as well be explicit in stating that we only expect two minor
> versions to be running at once (during a rolling upgrade). That is a simpler
> problem than having to support N minor versions.
> 

For heat, RPC compatibility actually isn't that complicated, because you can run multiple heat versions with different AMQP virtual hosts, so they physically cannot talk to each other.

You begin the rolling upgrade by starting new instances of heat engine with a new virtual host, then upgrade all API nodes (connected with a new virtual host). When all jobs on the old part of the cluster are done, you can stop old heat engine instances.

/ Greg




More information about the OpenStack-dev mailing list