cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Nalley <da...@gnsa.us>
Subject Re: Cherry-picking fix that may change 4.3.1 schema
Date Tue, 02 Sep 2014 19:27:52 GMT
On Tue, Sep 2, 2014 at 10:48 AM, Rohit Yadav <rohit.yadav@shapeblue.com> wrote:
>
> On 02-Sep-2014, at 4:38 pm, David Nalley <david@gnsa.us> wrote:
>> I agree - how will users upgrade from 4.3.1 to 4.4.x or later - schema
>> changes aren't necessarily going to screw up the upgrade process, but
>> certainly have a high likelihood of doing so. What happens when
>> 4.3.0-to-4.4.0.sql runs? The table already exists - and upgrade will
>> puke. 4.4.0 is already released; so not like you can roll that change
>> back.
>
> Since 4.4.0 is already released, people who will install 4.3.1 won’t be able to upgrade
to 4.4.0 as the 4.4.0 artifacts won’t have an upgrade path from 4.3.1 to 4.4.0; but this
can be only fixed (i.e. have an upgrade path) in 4.4.1.
>

Yes, I understand that, but think about all of the changes in 4.4.0 -
those changes (including the duplicated ones you're proposing) still
have to run against the database - e.g. - the database has to go
through the cycles to make it to 4.4.0, even if it is but an interim
step. Unless you are talking about obviating the need to run the 4.4.0
schema changes entirely - and that also scares me. That's new upgrade
path from 4.4.1, while we think we have a decent upgrade path at
present.

> For 4.3.1, we can still have the changes but 4.3.1 users would only be able to upgrade
to 4.4.1 or later releases and not 4.4.0 because there is no path from 4.3.1 to 4.4.0 in 4.4.0
release.
>

Think in database releases rather than code release - you can't get to
4.4.1 without traversing 4.4.0 - there are other changes; unless you
are talking rebuilding the database upgrade portion entirely....and
skipping 4.4.0.


> This is true for all ACS releases, only the latest releases know and have upgrade paths.
So, what I also proposed here was to refactor the whole upgrade logic as a tool and maintain
it separately and this tool can perhaps has its own release process that is faster than the
ACS releases and this tool knows about all the releases and has the necessary upgrade paths.
>

Honestly the db upgrade process does concern me - others have
mentioned tools like flyway and I like the idea - esp if we do
database design in such a way that we can downgrade as well as
upgrade. I would love to see a proposal on doing this better, though I
don't think it would solve this particular problem.

Mime
View raw message