<div dir="ltr">On Wed, May 1, 2013 at 12:53 PM, Russell Bryant <span dir="ltr"><<a href="mailto:rbryant@redhat.com" target="_blank">rbryant@redhat.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">

<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:47 PM, Sean Dague wrote:<br>
> On 05/01/2013 02:37 PM, Morgan Fainberg wrote:<br>
>> 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>
><br>
> Fair, but realize it's not just the db upgrade path (though that's the<br>
> first visible explosion).<br>
<br>
</div>I think this is the key point here.  Right now as a project we are only<br>
supporting N-1 to N upgrades.  Supporting more than that will take more<br>
consideration than just how we handle db migrations.  It also impacts<br>
the deprecation cycle (as pointed out below), what we need to be<br>
testing, how long we maintain internal API compatibility with rpc, the<br>
range of schema differences our code needs to be able to handle once we<br>
get to rolling upgrades, and more, I'm sure.<br>
<div class="im"><br>
> To support skip upgrades you need to get all the core teams to commit to<br>
> 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<br>
> would mean that nova-network would need to still ship in I, as would the<br>
> 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<br>
> just leaving a few db migrations around.<br>
<br>
</div>The ship has long since sailed on the Essex -> Grizzly question, so<br>
there's not much use in debating that at this point.  We can discuss<br>
increasing the support for the future, but right now I'm generally<br>
against it.<br>
<br>
OpenStack is still relatively young and is still moving very fast.  I<br>
think we're still a ways off before we want to start increasing how long<br>
we are supporting things upstream.<br>
<span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br></div><div></div></div></div><div class="gmail_extra" style>essex -> folsom and folsom -> grizzly schema changes will be the same forever. They never need to change. Just because we don't want to support essex -> grizzly upgrades, doesn't mean we need to actively remove things that will continue to work forever.</div>

<div class="gmail_extra" style><br></div><div class="gmail_extra" style>Obviously people are going to have to change their config files and they may need to replace entire services, but we should have data migration paths going back forever. All we have to do for this is leave them alone.</div>

<div class="gmail_extra" style><br></div><div class="gmail_extra" style>- Ryan</div></div>