<div dir="ltr">On 5 January 2016 at 18:55, Ryan Rossiter <span dir="ltr"><<a href="mailto:rlrossit@linux.vnet.ibm.com" target="_blank">rlrossit@linux.vnet.ibm.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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?</blockquote><div><br></div><div>As far as I know (the design has iterated a bit, but I think I'm still right), there is no need for such a table - before you start a rolling upgrade, you call the 'pin now' api, and all of the services write their max supported version to the DB. Once the DB is written to by all services, the running services can then read that table and cache the max value. Any new services bought up will also build a max volume cache on startup. Once everything is upgraded, you can call 'pin now' again and the services can figure out a new (hopefully higher) version limit.<br></div></div></div></div>