[openstack-dev] [Globalization] REST API sorting by status severity vs. alphabetical status key

Steven Kaufer kaufer at us.ibm.com
Thu Apr 24 03:07:01 UTC 2014


> 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.

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?
How would the object versioning populate the new column for the existing
records?

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

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.

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140423/dfb7bafa/attachment.html>


More information about the OpenStack-dev mailing list