cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daan Hoogland <daan.hoogl...@gmail.com>
Subject Re: Let’s discuss database upgrades
Date Tue, 29 Dec 2015 17:01:52 GMT
You are right Ron, but there is always security fixes that might require db
changes on a point release.

On Tue, Dec 29, 2015 at 5:39 PM, Ron Wheeler <rwheeler@artifact-software.com
> wrote:

> As an old-timer but a  new cloudstack user, it strikes me as a bit odd
> that changes to the database are allowed within a minor version change.
> This seems to cause a lot more problems than it solves.
>
> It could delay the release of someone's pet enhancement or bug fix but the
> idea of not being able to upgrade from 4.5.3 to 4.6.2 is frightening.
> The prospect of having upgrade scripts for 4.5.2 to 4.6.0, 4.6.1 and4.6.2
> as well as as a separate upgrade from 4.5.3 to 4.6.2 and similar scripts
> for 4.5.4, 4.5.5, etc. to 4.6.2, 4.6.3, 4.6.4 and so on, is unpleasant.
> This would have to continue until someone says that 4.5.x is dead and no
> upgrade scripts to new 4.6.x releases will be available.
>
> In projects that I have run, a change to the database required a new major
> release so a single conversion will take one from 4.5.x to 4.6.x
>
> The nice thing about release numbers is that one never runs out!
>
> Ron
>
>
>
> On 29/12/2015 10:08 AM, Daan Hoogland wrote:
>
>> CCYY == YYYY
>>
>> On Tue, Dec 29, 2015 at 3:06 PM, Rafael Weingärtner <
>> rafaelweingartner@gmail.com> wrote:
>>
>> I also liked the date-format, what did you mean with CCYY?
>>>
>>>
>>>
>>> The way I think we might have a problem, would be to commits/PRs that end
>>> up creating files with same names. Then, we would have to agree upon a
>>> way
>>> to solve those conflicts, such as appending an extra character to
>>> indicate
>>> a sequence to be followed or adding more data such as HH and mm to the
>>> naming convention (YYYY-MM-DD-HH-mm).
>>>
>>>
>>> I liked the way Wido suggested, we could just remove the “-” from
>>> “YYYY-MM-DD-HH-mm” and use the value as an integer (YYYYMMDDHHmm).
>>>
>>>
>>>
>>> It seems that we are reaching a consensus. I would love to hear back from
>>> other devs though, especially committers.
>>>
>>>
>>>
>>> BTW: do I have permission to create a page on the wiki so I can add
>>> everything we discuss and agree upon here? This way, we could add that
>>> page
>>> to the guidelines for devs creating PRs and committers reviewing and
>>> merging them.
>>>
>>> On Tue, Dec 29, 2015 at 12:00 PM, Wido den Hollander <wido@widodh.nl>
>>> wrote:
>>>
>>>
>>>> On 29-12-15 14:46, Daan Hoogland wrote:
>>>>
>>>>> Wido, Rafael,
>>>>>
>>>>> I like the date-format but then of course CCYY-MM-DD. I can still think
>>>>>
>>>> of
>>>>
>>>>> ways to screw up that (or the plain int;)
>>>>>
>>>>> 20151229 is a valid integer which you can simply use to compare with.
>>>>
>>>> 100, 101, 102 or 20151229, 20160103, 20160104, I don't care that much.
>>>>
>>>> My point is that the database version should be separated from the code
>>>> base.
>>>>
>>>> Wido
>>>>
>>>> On Tue, Dec 29, 2015 at 1:40 PM, Rafael Weingärtner <
>>>>> rafaelweingartner@gmail.com> wrote:
>>>>>
>>>>> Wido, that is true, you are right; the naming on upgrade routines can
>>>>>>
>>>>> use a
>>>>
>>>>> numeric value independent of the number of the version. The numeric
>>>>>>
>>>>> value
>>>>
>>>>> can be a simple integer that is incremented each routine that is added
>>>>>>
>>>>> or a
>>>>
>>>>> time stamp when the routine was added. The point is that we would have
>>>>>>
>>>>> to
>>>>
>>>>> link a version to a number. That would enable us to use flywaydb.
>>>>>>
>>>>>> To use that approach I think we might need to break compatibility
as
>>>>>>
>>>>> you
>>>
>>>> pointed out earlier, but I believe that the benefits of an improved
>>>>>>
>>>>> way
>>>
>>>> to
>>>>
>>>>> manage upgrade routines will compensate by the breaking of
>>>>>>
>>>>> compatibility.
>>>>
>>>>> On Tue, Dec 29, 2015 at 10:25 AM, Wido den Hollander <wido@widodh.nl>
>>>>>> wrote:
>>>>>>
>>>>>>
>>>>>>> On 29-12-15 13:21, Rafael Weingärtner wrote:
>>>>>>>
>>>>>>>> I got your point Daan.
>>>>>>>>
>>>>>>>> Well, and if we linked a version of ACS with a time stamp
in the
>>>>>>>>
>>>>>>> format
>>>>
>>>>> of
>>>>>>>
>>>>>>>> DD.MM.YYYY?
>>>>>>>>
>>>>>>>> In that case you could also say.
>>>>>>>
>>>>>>> ACS 4.6.0 == db ver X
>>>>>>>
>>>>>>> You don't have to say ver >= X, you can also say ver = X.
>>>>>>>
>>>>>>> We could then use the time stamp in the same format to name upgrade
>>>>>>>> routines. This way the idea of running all of the routines
in
>>>>>>>>
>>>>>>> between
>>>
>>>> version during upgrades could be applied.
>>>>>>>>
>>>>>>>> Same goes for giving all database changes a simple numeric
int which
>>>>>>> keeps incrementing each time a change is applied ;)
>>>>>>>
>>>>>>> Wido
>>>>>>>
>>>>>>> On Tue, Dec 29, 2015 at 10:03 AM, Daan Hoogland <
>>>>>>>>
>>>>>>> daan.hoogland@gmail.com
>>>>>>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Rafael,
>>>>>>>>>
>>>>>>>>> On Tue, Dec 29, 2015 at 12:22 PM, Rafael Weingärtner
<
>>>>>>>>> rafaelweingartner@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>> Thanks, Daan and Wido for your contributions, I will
discuss them
>>>>>>>>>>
>>>>>>>>> as
>>>
>>>> follows.
>>>>>>>>>>
>>>>>>>>>> Daan, about the idea of per commit upgrades. Do you
mean that we
>>>>>>>>>>
>>>>>>>>> separate
>>>>>>>
>>>>>>>> each change in the database that is introduced by PRs/Commits
in a
>>>>>>>>>> different file (routine upgrade) per ACS version?
>>>>>>>>>> So we would have, V_480_A.sql (for a PR),V_480_B.sql
(for another
>>>>>>>>>>
>>>>>>>>> PR)
>>>>
>>>>> and
>>>>>>>
>>>>>>>> so forth
>>>>>>>>>>
>>>>>>>>>> If that is the case, we can achieve that using a
simple convention
>>>>>>>>>>
>>>>>>>>> naming
>>>>>>>
>>>>>>>> as I suggested. Each developer when she/he needs to change
or add
>>>>>>>>>>
>>>>>>>>> something
>>>>>>>>>
>>>>>>>>>> in the database creates an upgrade routine separately
and gives it
>>>>>>>>>>
>>>>>>>>> an
>>>>
>>>>> execution order to be taken by Flywaydb. I think that could help
>>>>>>>>>>
>>>>>>>>> RMs
>>>
>>>> to
>>>>>>
>>>>>>> track and isolate the problem, right?
>>>>>>>>>>
>>>>>>>>>> ​Yes, with one little caveat. We do not know in
what version a
>>>>>>>>>
>>>>>>>> feature/PR
>>>>>>>
>>>>>>>> will end up at the time of implementing, so a name containing
the
>>>>>>>>>
>>>>>>>> version
>>>>>>>
>>>>>>>> would not be ideal.
>>>>>>>>> ​
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Hi Wido, now I understand your example.
>>>>>>>>>> I understand your worry about upgrade paths, and
that is the
>>>>>>>>>>
>>>>>>>>> point I
>>>
>>>> want
>>>>>>>
>>>>>>>> to discuss and solve. In your example, if we release a 4.6.0
and
>>>>>>>>>>
>>>>>>>>> later
>>>>>>
>>>>>>> a
>>>>>>>
>>>>>>>> 4.5.3. You said that there would be no upgrade path from
4.5.3 to
>>>>>>>>>>
>>>>>>>>> 4.6.0.
>>>>>>>
>>>>>>>> Well, today that is what happens. However, if we change the
>>>>>>>>>>
>>>>>>>>> technology
>>>>>>
>>>>>>> we
>>>>>>>
>>>>>>>> use to upgrade the database (using a tool such as Flywaydb)
and if
>>>>>>>>>>
>>>>>>>>> we
>>>>
>>>>> define a standard to create upgrade routines that would not be a
>>>>>>>>>>
>>>>>>>>> problem.
>>>>>>>
>>>>>>>> As I have written in my first email, to go from a version
to
>>>>>>>>>>
>>>>>>>>> another
>>>
>>>> we
>>>>>>
>>>>>>> should be able to run all of the upgrade routines in between
them
>>>>>>>>>> (including the upgrade routine of the goal version).
Therefore, if
>>>>>>>>>>
>>>>>>>>> we
>>>>
>>>>> release a version 4.6.0, and then 4.5.3, if someone upgrades to
>>>>>>>>>>
>>>>>>>>> 4.5.3
>>>>
>>>>> from
>>>>>>>>>
>>>>>>>>>> any other version, and then wants to upgrade to 4.6.0,
that would
>>>>>>>>>>
>>>>>>>>> not
>>>>
>>>>> be
>>>>>>>
>>>>>>>> a
>>>>>>>>>
>>>>>>>>>> problem, it would be a metter of running only the
routine upgrade
>>>>>>>>>>
>>>>>>>>> of
>>>
>>>> 4.6.0
>>>>>>>>>
>>>>>>>>>> version. We do not need to explicitly create upgrade
paths. They
>>>>>>>>>>
>>>>>>>>> should
>>>>>>
>>>>>>> be
>>>>>>>>>
>>>>>>>>>> implicit by our upgrade conventions.
>>>>>>>>>>
>>>>>>>>>> About creating versions of the code that rely on
some version of
>>>>>>>>>>
>>>>>>>>> the
>>>
>>>> database. I do not like much because of compatibility issues that
>>>>>>>>>>
>>>>>>>>> might
>>>>>>
>>>>>>> arise. For instance, let’s say version X of ACS depends on
version
>>>>>>>>>>
>>>>>>>>> =Y
>>>>>>> of
>>>>>>>
>>>>>>>> the database. If I upgrade the database to version Y + 1
or +2,
>>>>>>>>>>
>>>>>>>>> the
>>>
>>>> same
>>>>>>>
>>>>>>>> ACS version has to keep running nice and shiny. My worry
is that
>>>>>>>>>>
>>>>>>>>> may
>>>
>>>> bring
>>>>>>>>>
>>>>>>>>>> some complications, such as to remove columns that
cease to be
>>>>>>>>>>
>>>>>>>>> used
>>>
>>>> or
>>>>>>
>>>>>>> data
>>>>>>>>>
>>>>>>>>>> structure that we might want to improve.
>>>>>>>>>>
>>>>>>>>>> I normally see that the database version and the
code base are
>>>>>>>>>>
>>>>>>>>> tied
>>>
>>>> in
>>>>>>
>>>>>>> a
>>>>>>>
>>>>>>>> mapping 1 to 1. Maybe I am having troubles identifying the
>>>>>>>>>>
>>>>>>>>> benefits
>>>
>>>> of
>>>>>>
>>>>>>> that
>>>>>>>>>
>>>>>>>>>> change.
>>>>>>>>>>
>>>>>>>>>> Thanks for your time ;)
>>>>>>>>>>
>>>>>>>>>> On Tue, Dec 29, 2015 at 8:15 AM, Wido den Hollander
<
>>>>>>>>>>
>>>>>>>>> wido@widodh.nl
>>>
>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> On 28-12-15 21:34, Rafael Weingärtner wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi Wido, Rohit,
>>>>>>>>>>>> I have just read the feature suggestion.
>>>>>>>>>>>>
>>>>>>>>>>>> Wido, I am not trying to complicate things,
quite the opposite,
>>>>>>>>>>>>
>>>>>>>>>>> I
>>>
>>>> just
>>>>>>>>>
>>>>>>>>>> illustrate a simple thing that can happen and is
happening; I
>>>>>>>>>>>>
>>>>>>>>>>> just
>>>
>>>> pointed
>>>>>>>>>>>
>>>>>>>>>>>> how it can be easily solved.
>>>>>>>>>>>>
>>>>>>>>>>>> About the release of .Z, releases more constant
and others, I do
>>>>>>>>>>>>
>>>>>>>>>>> not
>>>>>>
>>>>>>> want
>>>>>>>>>>
>>>>>>>>>>> to mix topics. Let’s keep this thread strict
to discuss database
>>>>>>>>>>>>
>>>>>>>>>>> upgrades.
>>>>>>>>>>> I do not want to start the release discussion,
but what I meant
>>>>>>>>>>>
>>>>>>>>>> is
>>>
>>>> that
>>>>>>>
>>>>>>>> we try to find a technical solution to something which might
be
>>>>>>>>>>>
>>>>>>>>>> solved
>>>>>>
>>>>>>> easier by just changing the way we release.
>>>>>>>>>>>
>>>>>>>>>>> 4.6.0 is released and afterwards 4.5.3 is released.
How does
>>>>>>>>>>>
>>>>>>>>>> somebody
>>>>>>
>>>>>>> upgrade from 4.5.3 to 4.6.0? He can't, since the 4.6.0 code
>>>>>>>>>>>
>>>>>>>>>> doesn't
>>>
>>>> support that path.
>>>>>>>>>>>
>>>>>>>>>>> So my idea is to split the database version from
the code
>>>>>>>>>>>
>>>>>>>>>> version.
>>>
>>>> The code requires database version >= X and during boot it simply
>>>>>>>>>>>
>>>>>>>>>> checks
>>>>>>>>>
>>>>>>>>>> that.
>>>>>>>>>>>
>>>>>>>>>>> The database migration tool can indeed do the
DB migration, it
>>>>>>>>>>>
>>>>>>>>>> doesn't
>>>>>>
>>>>>>> have to be the mgmt server who does the upgrade.
>>>>>>>>>>>
>>>>>>>>>>> Now, about the FS. I agree with Rohit that we
should have only
>>>>>>>>>>>>
>>>>>>>>>>> one
>>>
>>>> way
>>>>>>>>>
>>>>>>>>>> of
>>>>>>>>>>
>>>>>>>>>>> managing database upgrades and creation. I just
do not like the
>>>>>>>>>>>>
>>>>>>>>>>> idea
>>>>>>
>>>>>>> of
>>>>>>>>>
>>>>>>>>>> creating a tool that work as a wrapper on frameworks/tools
such
>>>>>>>>>>>>
>>>>>>>>>>> as
>>>
>>>> flywaydb. I think that those frameworks already work pretty good
>>>>>>>>>>>>
>>>>>>>>>>> as
>>>>
>>>>> they
>>>>>>>>>>
>>>>>>>>>>> are; and, I would rather maintain configurations
than some
>>>>>>>>>>>>
>>>>>>>>>>> wrapper
>>>
>>>> code.
>>>>>>>>>>
>>>>>>>>>>> I personally like the way ACS works during upgrades
(I just do
>>>>>>>>>>>>
>>>>>>>>>>> not
>>>
>>>> like
>>>>>>>>>
>>>>>>>>>> the
>>>>>>>>>>>
>>>>>>>>>>>> code itself and how things are structured),
as a system
>>>>>>>>>>>>
>>>>>>>>>>> administrator I
>>>>>>>>>
>>>>>>>>>> like to change the version in the
>>>>>>>>>>>>
>>>>>>>>>>> “/etc/apt/sources.list.d/cloudstack.list”
>>>>>>>>>>>
>>>>>>>>>>>> and use the "apt-get" "update" and "install"
from the command
>>>>>>>>>>>>
>>>>>>>>>>> line. I
>>>>>>
>>>>>>> do
>>>>>>>>>>
>>>>>>>>>>> not see the need to add another tool that is
just a wrapper to
>>>>>>>>>>>>
>>>>>>>>>>> the
>>>
>>>> mix.
>>>>>>>>>
>>>>>>>>>> If
>>>>>>>>>>>
>>>>>>>>>>>> I update ACS code to 4.7.0, why would I let
the database schema
>>>>>>>>>>>>
>>>>>>>>>>> in
>>>
>>>> an
>>>>>>
>>>>>>> older
>>>>>>>>>>>
>>>>>>>>>>>> version? And if we want version DB schemas
and application code
>>>>>>>>>>>>
>>>>>>>>>>> separately
>>>>>>>>>>>
>>>>>>>>>>>> maintaining somehow compatibility between
them, which would
>>>>>>>>>>>>
>>>>>>>>>>> bring
>>>
>>>> a
>>>>
>>>>> whole
>>>>>>>>>>
>>>>>>>>>>> other level of complexity to the code; I think
we should avoid
>>>>>>>>>>>>
>>>>>>>>>>> that.
>>>>>>
>>>>>>> The flywaydb can be easily integrated with everything we have
>>>>>>>>>>>>
>>>>>>>>>>> now;
>>>
>>>> we
>>>>>>
>>>>>>> could
>>>>>>>>>>>
>>>>>>>>>>>> have a maven profile for developers and integrate
it in ACS
>>>>>>>>>>>>
>>>>>>>>>>> bootstrap
>>>>>>
>>>>>>> using
>>>>>>>>>>>
>>>>>>>>>>>> its API as a Spring bean. Therefore, we could
remove the current
>>>>>>>>>>>> “DatabaseUpgradeChecker “, “DbUpgrade”
and other classes that
>>>>>>>>>>>>
>>>>>>>>>>> aim
>>>
>>>> to
>>>>>>
>>>>>>> do
>>>>>>>>>
>>>>>>>>>> that. We could even add the creation of the schema
into the
>>>>>>>>>>>>
>>>>>>>>>>> first
>>>
>>>> time
>>>>>>>>>
>>>>>>>>>> it
>>>>>>>>>>
>>>>>>>>>>> boots using flywaydb and retire the “cloudstack-setup-database”
>>>>>>>>>>>>
>>>>>>>>>>> script,
>>>>>>>>>
>>>>>>>>>> or
>>>>>>>>>>>
>>>>>>>>>>>> at least make it less complicated, using
it just to configure
>>>>>>>>>>>>
>>>>>>>>>>> the
>>>
>>>> database
>>>>>>>>>>>
>>>>>>>>>>>> URL and users.
>>>>>>>>>>>>
>>>>>>>>>>>> The point is that to use Flywaydb we would
have to agree upon a
>>>>>>>>>>>>
>>>>>>>>>>> convention
>>>>>>>>>>>
>>>>>>>>>>>> on creating routines (java and SQL) to execute
upgrades.
>>>>>>>>>>>>
>>>>>>>>>>> Moreover,
>>>
>>>> using
>>>>>>>>>>
>>>>>>>>>>> a
>>>>>>>>>>>
>>>>>>>>>>>> tool such as Flywaydb we do not need to worry
about upgrade
>>>>>>>>>>>>
>>>>>>>>>>> paths.
>>>
>>>> As I
>>>>>>>>>
>>>>>>>>>> wrote in the email I used to start this thread, the
upgrade has
>>>>>>>>>>>>
>>>>>>>>>>> to
>>>
>>>> be
>>>>>>
>>>>>>> straightforward, to go to a version we have to run all of the
>>>>>>>>>>>>
>>>>>>>>>>> upgrade
>>>>>>
>>>>>>> routines between the current version until the desired one. Our
>>>>>>>>>>>>
>>>>>>>>>>> job
>>>>
>>>>> is
>>>>>>>>>
>>>>>>>>>> to
>>>>>>>>>>
>>>>>>>>>>> create upgrade routines that work and name them
properly, the
>>>>>>>>>>>>
>>>>>>>>>>> job
>>>
>>>> of
>>>>>>
>>>>>>> the
>>>>>>>>>>
>>>>>>>>>>> tool is to check the current version, the desired
one, the
>>>>>>>>>>>>
>>>>>>>>>>> upgrades
>>>>
>>>>> that
>>>>>>>>>>
>>>>>>>>>>> it
>>>>>>>>>>>
>>>>>>>>>>>> needs to run and execute everything properly.
>>>>>>>>>>>>
>>>>>>>>>>>> Yes, indeed. I just wanted to start the discussion
if we
>>>>>>>>>>>
>>>>>>>>>> shouldn't
>>>
>>>> version the database differently from the code.
>>>>>>>>>>>
>>>>>>>>>>> Additionally, I do not see the need to break
compatibility as
>>>>>>>>>>>>
>>>>>>>>>>> Rohit
>>>>
>>>>> suggested in the FS; in my opinion, everything we have up today
>>>>>>>>>>>>
>>>>>>>>>>> can
>>>>
>>>>> be
>>>>>>>>>
>>>>>>>>>> migrated to the new structure I proposed. If we use
a tool such
>>>>>>>>>>>>
>>>>>>>>>>> as
>>>
>>>> Flywaydb, I even volunteered for that. The only thing we have to
>>>>>>>>>>>>
>>>>>>>>>>> discuss
>>>>>>>>>>
>>>>>>>>>>> and agree upon is the naming conventions for
upgrades routines,
>>>>>>>>>>>>
>>>>>>>>>>> where
>>>>>>
>>>>>>> to
>>>>>>>>>>
>>>>>>>>>>> put them and the configurations for flywaydb.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks for your contribution and time.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Mon, Dec 28, 2015 at 2:10 PM, Rohit Yadav
<
>>>>>>>>>>>>
>>>>>>>>>>> rohit.yadav@shapeblue.com>
>>>>>>>>>>
>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Hi Rafael and Wido,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks for starting a conversation in
this regard, I could not
>>>>>>>>>>>>>
>>>>>>>>>>>> pursue
>>>>>>>>>
>>>>>>>>>> the
>>>>>>>>>>>
>>>>>>>>>>>> Chimp tool due to other $dayjob work though
it’s good to see
>>>>>>>>>>>>>
>>>>>>>>>>>> some
>>>
>>>> discussion has started again. Hope we’ll solve this in 2016.
>>>>>>>>>>>>>
>>>>>>>>>>>>> In my opinion, we will need to first
separate the database
>>>>>>>>>>>>>
>>>>>>>>>>>> init/migration
>>>>>>>>>>>
>>>>>>>>>>>> tooling away from mgmt server (right now
the mgmt server does
>>>>>>>>>>>>>
>>>>>>>>>>>> db
>>>
>>>> migrations
>>>>>>>>>>>
>>>>>>>>>>>> when it starts and there is a code/db version
mismatch) and
>>>>>>>>>>>>>
>>>>>>>>>>>> secondly
>>>>>>
>>>>>>> make
>>>>>>>>>>>
>>>>>>>>>>>> sure that we’re using the same code/tool
to deploy database
>>>>>>>>>>>>>
>>>>>>>>>>>> (right
>>>>
>>>>> now,
>>>>>>>>>>
>>>>>>>>>>> users use the cloudstack-setup-database python
tool while
>>>>>>>>>>>>>
>>>>>>>>>>>> developer
>>>>>>
>>>>>>> use
>>>>>>>>>>
>>>>>>>>>>> the
>>>>>>>>>>>
>>>>>>>>>>>> maven/java DatabaseCreator activated by the
-Ddeploydb flag).
>>>>>>>>>>>>>
>>>>>>>>>>>>> After we’ve addressed these two issues
we can look into how we
>>>>>>>>>>>>>
>>>>>>>>>>>> can
>>>>
>>>>> support
>>>>>>>>>>>
>>>>>>>>>>>> minor releases workflow (or decide to do
something else, like
>>>>>>>>>>>>>
>>>>>>>>>>>> not
>>>
>>>> support
>>>>>>>>>>>
>>>>>>>>>>>> .Z releases like Wido mentioned), and see
if we can or want to
>>>>>>>>>>>>>
>>>>>>>>>>>> use
>>>>
>>>>> any
>>>>>>>>>
>>>>>>>>>> existing migration tool or write a wrapper tool “chimp”
that
>>>>>>>>>>>>>
>>>>>>>>>>>> uses
>>>
>>>> existing
>>>>>>>>>>>
>>>>>>>>>>>> tools (some of those are mentioned in the
Chimp FS like
>>>>>>>>>>>>>
>>>>>>>>>>>> flywaydb
>>>
>>>> etc).
>>>>>>>>>
>>>>>>>>>> For
>>>>>>>>>>>
>>>>>>>>>>>> allowing users to go back and forth from
a db schema/version,
>>>>>>>>>>>>>
>>>>>>>>>>>> we’ll
>>>>>>
>>>>>>> also
>>>>>>>>>>
>>>>>>>>>>> need some new DB migration
>>>>>>>>>>>>>
>>>>>>>>>>>> conventions/versioning/rules/static-checking,
>>>>>>>>>>
>>>>>>>>>>> and how developer need to write such paths (forward
and
>>>>>>>>>>>>>
>>>>>>>>>>>> reverse)
>>>
>>>> etc.
>>>>>>>>>
>>>>>>>>>> The best approach I figured at the time was to decide
that
>>>>>>>>>>>>>
>>>>>>>>>>>> we’ll
>>>
>>>> use
>>>>>>
>>>>>>> the
>>>>>>>>>>
>>>>>>>>>>> previous db upgrade path mechanism till a certain
CloudStack
>>>>>>>>>>>>>
>>>>>>>>>>>> version
>>>>>>
>>>>>>> (say
>>>>>>>>>>>
>>>>>>>>>>>> 4.8.0) and after that we’ll use the new
approach or tooling to
>>>>>>>>>>>>> upgrade/downgrade DB schemas (thereby
retiring away from the
>>>>>>>>>>>>>
>>>>>>>>>>>> old
>>>
>>>> DB
>>>>>>
>>>>>>> upgrade
>>>>>>>>>>>
>>>>>>>>>>>> path mess).
>>>>>>>>>>>>>
>>>>>>>>>>>>> [image: ShapeBlue] <http://www.shapeblue.com>
Rohit Yadav
>>>>>>>>>>>>>
>>>>>>>>>>>> Software
>>>>>>
>>>>>>> Architect ,  ShapeBlue d:  * | s: +44 203 603 0540*
>>>>>>>>>>>>> <%7C%20s:%20+44%20203%20603%200540>
 |  m:  *+91 8826230892*
>>>>>>>>>>>>> <+91%208826230892> e:  *rohit.yadav@shapeblue.com
| t: *
>>>>>>>>>>>>> <rohit.yadav@shapeblue.com%20%7C%20t:>
 |  w:  *
>>>>>>>>>>>>>
>>>>>>>>>>>> www.shapeblue.com
>>>>
>>>>> *
>>>>>>
>>>>>>> <http://www.shapeblue.com> a:
>>>>>>>>>>>>> 53 Chandos Place, Covent Garden London
WC2N 4HS UK Shape Blue
>>>>>>>>>>>>>
>>>>>>>>>>>> Ltd
>>>
>>>> is a
>>>>>>>>>
>>>>>>>>>> company incorporated in England & Wales. ShapeBlue
Services
>>>>>>>>>>>>>
>>>>>>>>>>>> India
>>>
>>>> LLP
>>>>>>>>>
>>>>>>>>>> is a
>>>>>>>>>>>
>>>>>>>>>>>> company incorporated in India and is operated
under license
>>>>>>>>>>>>>
>>>>>>>>>>>> from
>>>
>>>> Shape
>>>>>>>>>
>>>>>>>>>> Blue
>>>>>>>>>>>
>>>>>>>>>>>> Ltd. Shape Blue Brasil Consultoria Ltda is
a company
>>>>>>>>>>>>>
>>>>>>>>>>>> incorporated
>>>
>>>> in
>>>>>>
>>>>>>> Brasil
>>>>>>>>>>>
>>>>>>>>>>>> and is operated under license from Shape
Blue Ltd. ShapeBlue SA
>>>>>>>>>>>>>
>>>>>>>>>>>> Pty
>>>>>>
>>>>>>> Ltd
>>>>>>>>>>
>>>>>>>>>>> is
>>>>>>>>>>>
>>>>>>>>>>>> a company registered by The Republic of South
Africa and is
>>>>>>>>>>>>>
>>>>>>>>>>>> traded
>>>>
>>>>> under
>>>>>>>>>>
>>>>>>>>>>> license from Shape Blue Ltd. ShapeBlue is a registered
>>>>>>>>>>>>>
>>>>>>>>>>>> trademark.
>>>
>>>> This email and any attachments to it may be confidential and
>>>>>>>>>>>>>
>>>>>>>>>>>> are
>>>
>>>> intended
>>>>>>>>>>>
>>>>>>>>>>>> solely for the use of the individual to whom
it is addressed.
>>>>>>>>>>>>>
>>>>>>>>>>>> Any
>>>
>>>> views
>>>>>>>>>>
>>>>>>>>>>> or
>>>>>>>>>>>
>>>>>>>>>>>> opinions expressed are solely those of the
author and do not
>>>>>>>>>>>>>
>>>>>>>>>>>> necessarily
>>>>>>>>>>
>>>>>>>>>>> represent those of Shape Blue Ltd or related
companies. If you
>>>>>>>>>>>>
>>>>>>>>>>>>


-- 
Daan

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message