<div dir="ltr">Sean,<div><br></div><div style>That is a very valid point. It wouldn't really be a terrible plan to do the deprecation strategy you described; I totally agree this is far, far more reaching (and requires buy-in from far more people) than this discussion has been so far. Perhaps we should aim to get this on the docket for the next summit (if there is enough interest via the mailing list).</div>
<div style><br></div><div style>--Morgan</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, May 1, 2013 at 11:47 AM, Sean Dague <span dir="ltr"><<a href="mailto:sean@dague.net" target="_blank">sean@dague.net</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">On 05/01/2013 02:37 PM, Morgan Fainberg wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
While I would agree that it would be nice to support Essex to Grizzly<br>
upgrade patterns, I can see the difficulty in supporting the SQL Migrate<br>
scripts as a lot of the core pieces have changed (logging, config, etc)<br>
and with the volume of migrate scripts it is fairly nice to have it<br>
collapsed for "new" installs. Having to adjust every SQL Migrate script<br>
for the codebase structure changes (when you are in the 100s+) becomes<br>
very time consuming and typically will impact a (relatively) smaller<br>
subset of users: Essex -> Grizzly is a big jump (and skipping releases<br>
is tough to provide direct support).<br>
<br>
The approach we are taking is to have the migrate repo for Folsom used<br>
as part of the deployment process. Migrate with a stub Folsom checkout<br>
and then use the actual Folsom -> Grizzly upgrade path.<br>
<br>
I think that the best plan of action for Essex -> Grizzly is<br>
documentation. For the future, this might be something we may want to<br>
bring up as a discussion point (maintaining an upgrade pattern for<br>
skipping a given release, based upon the compliance requirements for<br>
interoperable installations).<br>
</blockquote>
<br></div>
Fair, but realize it's not just the db upgrade path (though that's the first visible explosion).<br>
<br>
To support skip upgrades you need to get all the core teams to commit to Deprecate in N, remove in N+2, instead of Deprecate in N, remove in N+1.<br>
<br>
It would mean that grizzly would have still shipped with nova-volume. It would mean that nova-network would need to still ship in I, as would the bare-metal virt driver (just for some examples).<br>
<br>
Not to say it's not worth a discussion, but realize that it's more than just leaving a few db migrations around.<span class="HOEnZb"><font color="#888888"><br>
<br>
-Sean</font></span><div class="im HOEnZb"><br>
<br>
-- <br>
Sean Dague<br>
<a href="http://dague.net" target="_blank">http://dague.net</a><br>
<br></div><div class="HOEnZb"><div class="h5">
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</div></div></blockquote></div><br></div>