Open Stack

Jay,

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.

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.

Until we know that the new "status as int" column is populated then we
cannot use it as a sortable column.

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

Thanks,
Steven Kaufer

Jay Pipes <jaypipes at gmail.com> wrote on 04/28/2014 09:05:51 AM:

> From: Jay Pipes <jaypipes at gmail.com>
> To: openstack-dev at lists.openstack.org,
> Date: 04/28/2014 09:07 AM
> Subject: Re: [openstack-dev] [Globalization] REST API sorting by
> status severity vs. alphabetical status key
>
> 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
>
>
>
> _______________________________________________
> 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/20140428/c2ddd22d/attachment.html>