<br><br><div class="gmail_quote">On Thu, Feb 28, 2013 at 4:38 AM, Eoghan Glynn <span dir="ltr"><<a href="mailto:eglynn@redhat.com" target="_blank">eglynn@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
<br>
> >> From: "Doug Hellmann" <<a href="mailto:doug.hellmann@dreamhost.com">doug.hellmann@dreamhost.com</a>><br>
> >> To: "OpenStack Development Mailing List"<br>
> >> <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
> >> Sent: Wednesday, February 27, 2013 12:21:14 PM<br>
> >> Subject: Re: [openstack-dev] [keystone] re-ordering of schema<br>
> >> migrations<br>
> >><br>
> >> On Wed, Feb 27, 2013 at 9:59 AM, Dan Prince <<a href="mailto:dprince@redhat.com">dprince@redhat.com</a>><br>
> >> wrote:<br>
> >><br>
><br>
> >><br>
> >> Yeah. Let's not do that, though. Let's just add new migrations as<br>
> >> necessary. That way each migration is tested, and after it is<br>
> >> known<br>
> >> to work<br>
> >> it is not changed to something different that has to be re-tested.<br>
> ><br>
> ><br>
> > I don't think Keystone has reached this point either. At some point<br>
> > though the number or migrations becomes unwieldy and compacting<br>
> > things may make more sense though.<br>
><br>
> And to clarify, we have already done this a couple of times for nova:<br>
> once for Folsom and again for Grizzly.  In Grizzly we're up to 159,<br>
> but the migrate repo starts with a single migration to get up to 133.<br>
<br>
</div>Yeah, so I mentioned this nova practice of consolidating adjacent<br>
migrations around major releases, as an acceptable change.<br>
<br>
However, if I understood Doug correctly, he's raising this approach as<br>
a potential issue that should be discontinued.<br>
<br>
Doug - just to clarify, it's not the compaction per se that's potentially<br>
problematic for trunk-chasers, more the risk that in manually compacting<br>
multiple scripts some regression will creep in due to human error?<br></blockquote><div><br></div><div>Yes. There's no real runtime benefit (the migration framework skips the steps it doesn't need to perform) and there's a risk of having the results of the micro-migrations be different than the bulk migrations, which would make following trunk across a release more difficult.</div>
<div><br></div><div>Doug</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Cheers,<br>
Eoghan<br>
<div class="HOEnZb"><div class="h5"><br>
> --<br>
> Russell Bryant<br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br>