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/ __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
