<div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif"><div class="gmail_default">The original spec to pin object and RPC versions is hhttps://<a href="http://review.openstack.org/#/c/192037/">review.openstack.org/#/c/192037/</a>.  There is an initial patch to register the versions - <a href="https://review.openstack.org/#/c/209701/">https://review.openstack.org/#/c/209701/</a>.</div><div class="gmail_default"><br></div><div class="gmail_default">Thang</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 5, 2016 at 1:55 PM, Ryan Rossiter <span dir="ltr"><<a href="mailto:rlrossit@linux.vnet.ibm.com" target="_blank">rlrossit@linux.vnet.ibm.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On Jan 5, 2016, at 7:13 AM, Michał Dulko <<a href="mailto:michal.dulko@intel.com">michal.dulko@intel.com</a>> wrote:<br>
><br>
> On 01/04/2016 11:41 PM, Ryan Rossiter wrote:<br>
>> 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?<br>
> What Duncan is describing is correct - we intent to backport objects on<br>
> sender's side in a similar manner like RPC methods backporting (version<br>
> pinning). This model was discussed a few times and seems to be fine, but<br>
> if you think otherwise - please let us know.<br>
</span>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:<br>
<br>
{‘liberty’: {‘volume’: ‘1.3’, …},<br>
 ‘mitaka’: {‘volume’: ‘1.8’, …}, }<br>
<br>
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.<br>
<span class=""><br>
>> 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).<br>
> We want to backport on sender's side, so no RPC calls should be needed.<br>
> This is also connected with the fact that in Cinder we have all the<br>
> services accessing the DB directly (and currently no plans to to change<br>
> it). This means that o.vo are of no use for us to support schema<br>
> upgrades in an upgradeable way (as described in [1]). We intent to use<br>
> o.vo just to version the payloads sent through RPC methods arguments.<br>
</span>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).<br>
<span class=""><br>
><br>
> This however rises a question that came to my mind a few times - why do<br>
> we even mark any of our o.vo methods as remoteable?<br>
</span>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 :)<br>
<span class=""><br>
><br>
> I really want to thank you for giving all this stuff in Cinder a good<br>
> double check. It's very helpful to have an insight of someone more<br>
> experienced with o.vo stuff. :)<br>
</span>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.<br>
<span class="">><br>
> I think we have enough bricks and blocks in place to show a complete<br>
> rolling upgrade case that will include DB schema upgrade, o.vo<br>
> backporting and RPC API version pinning. I'll be working on putting this<br>
> all together before the mid cycle meetup.<br>
</span>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.<br>
<span class="">><br>
> [1]<br>
> <a href="http://www.danplanet.com/blog/2015/10/07/upgrades-in-nova-database-migrations/" rel="noreferrer" target="_blank">http://www.danplanet.com/blog/2015/10/07/upgrades-in-nova-database-migrations/</a><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
</span>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!<br>
<br>
[1] <a href="https://github.com/openstack/cinder-specs/blob/master/specs/kilo/cinder-objects.rst" rel="noreferrer" target="_blank">https://github.com/openstack/cinder-specs/blob/master/specs/kilo/cinder-objects.rst</a><br>
<span class="im HOEnZb">-----<br>
Thanks,<br>
<br>
Ryan Rossiter (rlrossit)<br>
<br>
<br>
</span><div class="HOEnZb"><div class="h5">__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>