Open Stack

On 25/07/14 13:50, Clint Byrum wrote:
> Excerpts from Zane Bitter's message of 2014-07-24 12:09:39 -0700:
>> On 17/07/14 07:51, Ryan Brown wrote:
>>> On 07/17/2014 03:33 AM, Steven Hardy wrote:
>>>> On Thu, Jul 17, 2014 at 12:31:05AM -0400, Zane Bitter wrote:
>>>>> On 16/07/14 23:48, Manickam, Kanagaraj wrote:
>>>>>> SNIP
>>>>>> *Resource*
>>>>>>
>>>>>> Status & action should be enum of predefined status
>>>>>
>>>>> +1
>>>>>
>>>>>> Rsrc_metadata - make full name resource_metadata
>>>>>
>>>>> -0. I don't see any benefit here.
>>>>
>>>> Agreed
>>>
>>>
>>> I'd actually be in favor of the change from rsrc->resource, I feel like
>>> rsrc is a pretty opaque abbreviation.
>>
>> I'd just like to remind everyone that these changes are not free.
>> Database migrations are a pain to manage, and every new one slows down
>> our unit tests.
>>
>> We now support multiple heat-engines connected to the same database and
>> people want to upgrade their installations, so that means we have to be
>> able to handle different versions talking to the same database. Unless
>> somebody has a bright idea I haven't thought of, I assume that means
>> carrying code to handle both versions for 6 months before actually being
>> able to implement the migration. Or are we saying that you have to
>> completely shut down all instances of Heat to do an upgrade?
>>
>> The name of the "nova_instance" column is so egregiously misleading that
>> it's probably worth the pain. Using an enumeration for the states will
>> save a lot of space in the database (though it would be a much more
>> obvious win if we were querying on those columns). Changing a random
>> prefix that was added to avoid a namespace conflict to a slightly
>> different random prefix is well below the cost-benefit line IMO.
>
> In past lives managing apps like Heat, We've always kept supporting the
> previous schema in new code versions. So the process is:
>
> * Upgrade all code
> * Restart all services
> * Upgrade database schema
> * Wait a bit for reverts
> * Remove backward compatibility

OK, so we can put the migration in now but we still have to support the 
old DB format for 6 months. I'm fine with that; I think my point that 
trivial cosmetic changes don't justify the extra cruft stands.

I'm curious now if this is the upgrade process that we're documenting, 
though? I can think of a bunch of places where we added e.g. new tables 
or columns to the DB and AFAIK the code assumes that they'll be there 
(i.e. that the schema upgrade happened before trying to use that feature).

cheers,
Zane.

> Now this was always in more of a continuous delivery environment, so
> there was not more than a few weeks of waiting for reverts. In OpenStack
> we'd have a single release to wait.
>
> We're not special though, doesn't Nova have some sort of object versioning
> code that helps them manage the versions of each type of data for this
> very purpose?
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>