Open Stack

The original spec to pin object and RPC versions is hhttps://
review.openstack.org/#/c/192037/.  There is an initial patch to register
the versions - https://review.openstack.org/#/c/209701/.

Thang

On Tue, Jan 5, 2016 at 1:55 PM, Ryan Rossiter <rlrossit at linux.vnet.ibm.com>
wrote:

>
> > On Jan 5, 2016, at 7:13 AM, Michał Dulko <michal.dulko at intel.com> wrote:
> >
> > 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.
> This is definitely good to know. Are you planning on setting up something
> off to the side of o.vo within that holds a dictionary of all values for a
> release? Something like:
>
> {‘liberty’: {‘volume’: ‘1.3’, …},
>  ‘mitaka’: {‘volume’: ‘1.8’, …}, }
>
> With the possibility of replacing the release name with the RPC version or
> some other version placeholder. Playing devil’s advocate, how does this
> work out if I want to be continuously deploying Cinder from HEAD? I will be
> pinned to the previous release’s version until the new release comes out
> right? I don’t think that’s a bad thing, just something to think about.
> Nova’s ability to be continuously deployable off of HEAD is still a big
> magical black box to me, so to be fair I have no idea how a rolling upgrade
> works when doing CD off of HEAD.
>
> >> 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.
> Is this documented in specs/bps somewhere? This is a pretty big detail
> that I didn’t know about. The only thing I could find was [1] from kilo
> (which I totally understand if it hasn’t been updated since merging, I
> don’t think *any* project that I’ve seen keeps the merged specs up to date).
>
> >
> > 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?
> Well, is there hope to change over to do o.vo more like Nova in the
> future? If so, then there’s basically no cost to doing @base.remotable
> right now if you want to add it in the future. But that’s not for me to
> decide :)
>
> >
> > 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 try to make Dan Smith proud ;). I can’t hold a candle to Dan’s knowledge
> of this stuff, but I definitely have more free time than he does.
> >
> > 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.
> Record it, document it, post it somewhere when you get it done! I’ve never
> actually done a rolling upgrade on my own (thank goodness for grenade) and
> I would love to see it.
> >
> > [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-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> This is definitely a huge undertaking that takes multiple releases to get
> done. I think you are doing a good job of taking this in smaller parts, and
> it looks like doing so is allowing you to start doing rolling upgrades very
> quickly. Well done!
>
> [1]
> https://github.com/openstack/cinder-specs/blob/master/specs/kilo/cinder-objects.rst
> -----
> Thanks,
>
> Ryan Rossiter (rlrossit)
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160105/dea62017/attachment.html>