<html><body>
<p><font size="2" face="sans-serif">Jay,</font><br>
<br>
<font size="2" face="sans-serif">Thanks again for the reply. If this migration is implemented using the object "versioning", then the new "status as int" column cannot be utilized (ie, sorted on) until the existing "status as string" column is eventually dropped.</font><br>
<br>
<font size="2" face="sans-serif">Is this correct? If so, then this approach will not actually solve the globalization sort problem until more release cycles have completed -- this does not seem like a viable solution.</font><br>
<br>
<font size="2" face="sans-serif">Until we know that the new "status as int" column is populated then we cannot use it as a sortable column.</font><br>
<br>
<font size="2" face="sans-serif">In theory, a deployer could conditionally choose to migrate to the new column if they needed that function and were willing to take the hit during the migration. However, this just complicates the sorting logic since we would then need to know which column to use during the sort (the new int column if the migration has completed or the old string column if the migration has not completed).</font><br>
<br>
<font size="2" face="sans-serif">Thanks,</font><br>
<font size="2" face="sans-serif">Steven Kaufer<br>
</font><br>
<tt><font size="2">Jay Pipes <jaypipes@gmail.com> wrote on 04/28/2014 09:05:51 AM:<br>
<br>
> From: Jay Pipes <jaypipes@gmail.com></font></tt><br>
<tt><font size="2">> To: openstack-dev@lists.openstack.org, </font></tt><br>
<tt><font size="2">> Date: 04/28/2014 09:07 AM</font></tt><br>
<tt><font size="2">> Subject: Re: [openstack-dev] [Globalization] REST API sorting by <br>
> status severity vs. alphabetical status key</font></tt><br>
<tt><font size="2">> <br>
> On Wed, 2014-04-23 at 22:07 -0500, Steven Kaufer wrote:<br>
> > > yeah, we're talking about thousands and thousands of rows that have<br>
> > to<br>
> > > be updated before the API can be restarted…<br>
> > > <br>
> > > > There's also a possibility of adding support for the status codes,<br>
> > but<br>
> > > > keeping the string columns in the database, and then using the<br>
> > nova<br>
> > > > object versioning to "migrate" the object schema over time to the<br>
> > point<br>
> > > > where the migration is a simple DROP COLUMN.<br>
> > > <br>
> > > I like that idea better, TBH, but we're probably talking about a<br>
> > > long-time deprecation here, like on the order of a couple of<br>
> > releases;<br>
> > > that would give plenty of time for the majority of the records to be<br>
> > > revisited and make the final migration run for a lot shorter time.<br>
> > > -- <br>
> > <br>
> > Thanks for the discussion.<br>
> <br>
> No prob, sorry for the delayed response...<br>
> <br>
> > So how would this new flow work?<br>
> > In Juno would there be an additional status_int column that would be<br>
> > populated and (eventually) replace the existing status (as string)<br>
> > column?<br>
> <br>
> That would be the cleanest way, yes.<br>
> <br>
> > How would the object versioning populate the new column for the<br>
> > existing records?<br>
> <br>
> Within the nova.objects.instance.Instance object itself, we can put a<br>
> small check-and-transform function in the object to do the translation<br>
> in-line.<br>
> <br>
> > Any examples or details that would help explain how this could work<br>
> > would be appreciated.<br>
> <br>
> Probably worth putting a blueprint up about it. I can work with you on<br>
> it, if you'd like, though it will likely be after the summit until I<br>
> have time to work on it.<br>
> <br>
> > Lastly, is there agreement that this is an issue that needs to be<br>
> > addressed? Note that this seems to be a pervasive problem, I've<br>
> > investigated the status column in cinder and nova but I suspect that<br>
> > the same issue exists in other components.<br>
> <br>
> Yes, the same issue unfortunately exists in lots of the other<br>
> components, and they don't have the benefit of the nova objects work in<br>
> them, which makes it a lot more of a nuisance to migrate the database<br>
> schema. Though, personally I'm not entirely sure going through the<br>
> effort of doing a long-time in-object translation is worth it. A change<br>
> to the database schema, even on tens of millions of records wouldn't<br>
> take more than a couple minutes. But it all depends on the operator's<br>
> tolerance for downtime, since the instances table would certainly be<br>
> locked for the duration of the migration.<br>
> <br>
> Best,<br>
> -jay<br>
> <br>
> > Thanks,<br>
> > Steven Kaufer<br>
> > <br>
> > <br>
> > > Kevin L. Mitchell <kevin.mitchell@rackspace.com><br>
> > > Rackspace<br>
> > > <br>
> > > <br>
> > > _______________________________________________<br>
> > > OpenStack-dev mailing list<br>
> > > OpenStack-dev@lists.openstack.org<br>
> > > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> > <br>
> > <br>
> > _______________________________________________<br>
> > OpenStack-dev mailing list<br>
> > OpenStack-dev@lists.openstack.org<br>
> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> <br>
> <br>
> <br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> OpenStack-dev@lists.openstack.org<br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</font></tt></body></html>