cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Miguel Ferreira <>
Subject RE: [DISCUSS] Enabling databse upgrades on master branch
Date Tue, 11 Mar 2014 09:58:29 GMT
Hi Rajani,

Indeed I see the overlap with the previous discussion that is taking place. I actually tried
to chip-in that discussion.
I do agree with you on introducing tools that can support the database upgrade process, but
meanwhile a small change in the way developers maintain the database related code could already
bring us very far.

As of now I'm working on a separate project with the following roadmap:
- detect potential conflicts (and collect data about them)
- learn from the data collected which conflicts can we resolve automatically, which we cannot
- for the conflicts that we cannot resolve automatically, provide some guidance to the operator
on how proceed with the upgrade

I'm working on a repository that is not accessible from the outside of Schuberg Philis, but
the intention is to move it to ASAP.

I'm very interested in aligning efforts with the rest of the community, and I'm available
to help out in whatever is decided. Meanwhile, I will continue to develop the ideas we have,
and anyone interested in helping out with that is very welcome.

If you have any ideas on how to collaborate, please let me know.


-----Original Message-----
From: Rajani Karuturi [] 
Sent: dinsdag 11 maart 2014 7:19
Cc: Alex Huang
Subject: Re: [DISCUSS] Enabling databse upgrades on master branch

Hi Miguel,

This is in-line with discussions related to db changes we are having at [1] and [2]

I think it would be better to use existing tools like [liquibase] or [flyway] instead of writing
a new one. A good comparison of the both is available at [3].

Also, how do we join the efforts? Is there any design doc? Are you working on a separate branch
or as separate project?



On 10-Mar-2014, at 8:35 pm, Miguel Ferreira <<>>

Hi all,

At Schuberg Philis we are interested in upgrading our running installation of ACS more frequently
than the current release cycle.
To that end, we are working on tooling to detect potentially conflict introducing changes
to the ACS database and upgrade software.
By conflict introducing change I mean a change to ACS that requires a clean database to start
with. Thus, rendering a database of a running installation useless.
Once we can detect the changes that introduce conflicts, we will start to monitor them to
better understand how to mitigate and possibly work around the conflicts.

One thing we can already foresee as problematic is the way the upgrade software (SQL scripts
and Java classes) are being maintained. It is part of the current way-of-working to make all
kinds of changes to the upgrade software in the master branch. Say, if a create statement
was introduced in a SQL script in commit C1, then the same create statement might be changed
in commit C2, or even further down the line. If we want to continuously upgrade our running
installation, we would not be able to upgrade past C1 without at least losing some data. One
possible way out of this problem is to add an alter statement in C2 instead of changing the
create statement introduced in C1.

We are in favor of all changes to the upgrade software being made in such a way that they
can be applied independently and incrementally. We do realize that this entails more effort
from developers, but we also see the benefit of enabling continuous delivery: we basically
get a shorter feedback loop on the quality of ACS in a real-world scenario.

We are making all tools related to this open source, so anyone that shares the same interest
is welcome to join the effort.
Lastly, we would like to hear your opinions about the issue I described, as well as, the proposed
solution and any other solutions you might come up with.

Kind regards,
Miguel Ferreira

Mission Critical Engineer
Schuberg Philis
Boeingavenue 271
1119 PD Schiphol-Rijk<>

+31 207506617
+31 610907106

View raw message