Open Stack

Hey everybody, your favorite versioned objects guy is back!

So as I’m helping out more and more with the objects stuff around Cinder, I’m starting to notice something that may be a problem with rolling upgrades/object backporting. Feel free to say “you’re wrong” at any point during this email, I very well may have missed something.

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?

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).

I don’t mean to pile more work onto this, I understand that this is a big task to take on, and so far, it’s progressing very well. Michal’s been really helpful as a liaison so far, he’s been a lot of help :).

[1] https://github.com/openstack/oslo.versionedobjects/blob/master/oslo_versionedobjects/base.py#L522

-----
Thanks,

Ryan Rossiter (rlrossit)