Open Stack

On 05/17/2016 09:40 PM, Crag Wolfe wrote:
 
<snip>

> That helps a lot, thanks! You are right, it would have to be a 3-step
> upgrade to avoid the issue you mentioned in 6.
>
> Another thing I am wondering about: if my particular object is not
> exposed by RPC, is it worth making it a full blown o.vo or not? I.e, I
> can do the 3 steps over 3 releases just in the object's .py file -- what
> additional value do I get from o.vo?

Unfortunately Zane's right - none. In case of DB schema compatibility
you can benefit from o.vo if you have something like nova-conductor -
upgraded atomically and being able to backport object to previous
versions getting data from newer DB schema. Also there shouldn't be DB
accesses in your n-cpu-like services.

o.vo are mostly useful in Cinder to model dictionaries sent over RPC
(like request_spec), which we're backporting if there are older versions
of services in the deployment. Versioning and well-defining dict blobs
is essential to control compatibility. Also sending whole o.vo instead
of plain id in RPC methods can give you more flexibility in complicated
compatibility issues, but it turns out in Cinder we haven't yet hit a
case when that would be useful.

> I'm also shying away from the idea of allowing for config-driven
> upgrades. The reason is, suppose an operator updates a config, then does
> a rolling restart to go from X to X+1. Then again (and probably again)
> as needed. Everything works great, run a victory lap. A few weeks later,
> some ansible or puppet automation accidentally blows away the config
> value saying that heat-engine should be running at the X+3 version for
> my_object. Ouch. Probably unlikely, but more likely than say
> accidentally deploying a .py file from three releases ago.