Open Stack

On 01/05/2016 07:55 PM, Ryan Rossiter wrote:
> 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.

Can't we simply make it accept both object versions and release aliases.
If someone want to deploy continuously he need to check out what version
is installed and pin it.

>> 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 :)

Sure, if it doesn't cost us anything - then let's leave it. :)