Open Stack

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

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?