Open Stack

On Wed, 2014-04-23 at 22:07 -0500, Steven Kaufer wrote:
> > yeah, we're talking about thousands and thousands of rows that have
> to
> > be updated before the API can be restarted…
> > 
> > > 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.
> > 
> > I like that idea better, TBH, but we're probably talking about a
> > long-time deprecation here, like on the order of a couple of
> releases;
> > that would give plenty of time for the majority of the records to be
> > revisited and make the final migration run for a lot shorter time.
> > -- 
> 
> Thanks for the discussion.

No prob, sorry for the delayed response...

> So how would this new flow work?
> In Juno would there be an additional status_int column that would be
> populated and (eventually) replace the existing status (as string)
> column?

That would be the cleanest way, yes.

> How would the object versioning populate the new column for the
> existing records?

Within the nova.objects.instance.Instance object itself, we can put a
small check-and-transform function in the object to do the translation
in-line.

> Any examples or details that would help explain how this could work
> would be appreciated.

Probably worth putting a blueprint up about it. I can work with you on
it, if you'd like, though it will likely be after the summit until I
have time to work on it.

> Lastly, is there agreement that this is an issue that needs to be
> addressed? Note that this seems to be a pervasive problem, I've
> investigated the status column in cinder and nova but I suspect that
> the same issue exists in other components.

Yes, the same issue unfortunately exists in lots of the other
components, and they don't have the benefit of the nova objects work in
them, which makes it a lot more of a nuisance to migrate the database
schema. Though, personally I'm not entirely sure going through the
effort of doing a long-time in-object translation is worth it. A change
to the database schema, even on tens of millions of records wouldn't
take more than a couple minutes. But it all depends on the operator's
tolerance for downtime, since the instances table would certainly be
locked for the duration of the migration.

Best,
-jay

> Thanks,
> Steven Kaufer
> 
> 
> > Kevin L. Mitchell <kevin.mitchell at rackspace.com>
> > Rackspace
> > 
> > 
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev