[openstack-dev] [cinder] Object backporting and the associated service
duncan.thomas at gmail.com
Tue Jan 5 09:48:26 UTC 2016
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" <rlrossit at 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  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 :).
> Ryan Rossiter (rlrossit)
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev