The current plan is not to use a conductor, and to pin object versions to to current version before starting a rolling upgrade. This means version downgraded will be done on the sender side before sending I think. I need to look more closely at the patches again to be honest. On 5 Jan 2016 00:41, "Ryan Rossiter" <rlros...@linux.vnet.ibm.com> wrote:
> 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) > > > __________________________________________________________________________ > 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 >
__________________________________________________________________________ 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
