Open Stack

On Wed, 2014-04-23 at 17:19 -0500, Kevin L. Mitchell wrote:
> On Wed, 2014-04-23 at 15:29 -0500, Steven Kaufer wrote:
> > Thanks for the reply.  I agree that changing the datamodel would be
> > the ideal solution.  But, to be honest, the scope of that change
> > frightens me.
> > 
> > How would you recommend that a change like this would be handled (in
> > addition to the DB migration work)?  We obviously cannot break
> > existing codepaths that assume that the existing English key values
> > would be returned from the DB.
> > 
> > Is there an existing layer that would perform the mapping between the
> > enum values in the DB and the String keys?
> 
> Theoretically, at least, all the status values should be using and
> comparing against constants; see, for instance,
> nova/compute/vm_states.py.  Those could be converted to integers, with a
> translation table specified in the database migration.  The scary thing,
> though, is just how long that migration will end up taking

Worth it, IMO :)

There's also a possibility of adding support for the status codes, but
keeping the string columns in the database, and then using the nova
object versioning to "migrate" the object schema over time to the point
where the migration is a simple DROP COLUMN.

Best,
-jay