Open Stack

On 01/04/2016 11:41 PM, Ryan Rossiter wrote:
> My first question is: what will be handling the object backports that the different cinder services need? In Nova, we have the conductor service, which handles all of the messy RPC and DB work. When anyone needs something backported, they ask conductor, and it handles everything. That also gives us a starting point for the rolling upgrades: start with conductor, and now he has the new master list of objects, and can handle the backporting of objects when giving them to the older services. From what I see, the main services in cinder are API, scheduler, and volume. Does there need to be another service added to handle RPC stuff?
What Duncan is describing is correct - we intent to backport objects on
sender's side in a similar manner like RPC methods backporting (version
pinning). This model was discussed a few times and seems to be fine, but
if you think otherwise - please let us know.
> The next question is: are there plans to do manifest backports? That is a very o.vo-jargoned question, but basically from what I can see, Cinder’s obj_to_primitive() calls do not use o.vo’s newer method of backporting, which uses a big dictionary of known versions (a manifest) to do one big backport instead of clogging up RPC with multiple backport requests every time a subobject needs to be backported after a parent has been backported (see [1] if you’re interested). I think this is a pretty simple change that I can help out with if need be (/me knocks on wood).
We want to backport on sender's side, so no RPC calls should be needed.
This is also connected with the fact that in Cinder we have all the
services accessing the DB directly (and currently no plans to to change
it). This means that o.vo are of no use for us to support schema
upgrades in an upgradeable way (as described in [1]). We intent to use
o.vo just to version the payloads sent through RPC methods arguments.

This however rises a question that came to my mind a few times - why do
we even mark any of our o.vo methods as remoteable?

I really want to thank you for giving all this stuff in Cinder a good
double check. It's very helpful to have an insight of someone more
experienced with o.vo stuff. :)

I think we have enough bricks and blocks in place to show a complete
rolling upgrade case that will include DB schema upgrade, o.vo
backporting and RPC API version pinning. I'll be working on putting this
all together before the mid cycle meetup.

[1]
http://www.danplanet.com/blog/2015/10/07/upgrades-in-nova-database-migrations/