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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
