of system VMs.
Consider the number of maintenance windows AWS opens where all or part of
its services are completely unavailable. Therefore, our tooling needs to
favor additive, non-destructive schema changes that allow database upgrades
to be applied while an older version of the management is still
"dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>" <
dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>>
Subject: RE: Let’s discuss database upgrades
Hi Guys, from the user's perspective, there are two points which come up
again and again -
1. lack a prescribed rol
onerous. Consider the number of
maintenance windows AWS opens where all or part of its services are completely
unavailable. Therefore, our tooling needs to favor additive, non-destructive
schema changes that allow database upgrades to be applied while an older
version of the management is still
e 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 are not the
>> intended recipient of th
;mailto:dev@cloudstack.apache.org>>
Subject: RE: Let’s discuss database upgrades
Hi Guys, from the user's perspective, there are two points which come up again
and again -
1. lack a prescribed roll back if an upgrade goes badly
2. The downtime involved in doing upgrades.
- Upgrades
--Original Message-
From: Erik Weber [mailto:terbol...@gmail.com]
Sent: 29 December 2015 21:45
To: dev <dev@cloudstack.apache.org>
Subject: Re: Let’s discuss database upgrades
On Mon, Dec 28, 2015 at 2:16 PM, Rafael Weingärtner <
rafaelweingart...@gmail.com> wrote:
> Hi all
<dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>>
Date: Wednesday 30 December 2015 10:10
To: "dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>"
<dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>>
Subject: RE: Let’s discuss da
t;>>>>>>> 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
>>>>>>>>>
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 t
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 fi
On Mon, Dec 28, 2015 at 2:16 PM, Rafael Weingärtner <
rafaelweingart...@gmail.com> wrote:
> Hi all devs,
> First of all, sorry the long text, but I hope we can start a discussion
> here and improve that part of ACS.
>
> A while ago I have faced the code that Apache CloudStack (ACS) uses to
>
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.
>
> Now, about the FS. I agree with Rohit that 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
gt;
>>> 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,
ise. 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
> >
ing 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
>>
gt;>>> 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
>>>>>>
; On Tue, Dec 29, 2015 at 8:15 AM, Wido den Hollander <w...@widodh.nl>
> > wrote:
> >
> > >
> > >
> > > On 28-12-15 21:34, Rafael Weingärtner wrote:
> > > > Hi Wido, Rohit,
> > > > I have just read the feature suggestion.
&g
; 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.
> >>>
> >>>
;>>>> 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
> >>>>>
; > 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
> upg
n 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 s
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
Hi all devs,
First of all, sorry the long text, but I hope we can start a discussion
here and improve that part of ACS.
A while ago I have faced the code that Apache CloudStack (ACS) uses to
upgrade from a version to newer one and that did not seem to be a good way
to execute our upgrades.
On 28-12-15 14:16, Rafael Weingärtner wrote:
> Hi all devs,
> First of all, sorry the long text, but I hope we can start a discussion
> here and improve that part of ACS.
>
> A while ago I have faced the code that Apache CloudStack (ACS) uses to
> upgrade from a version to newer one and that
Thanks for your contribution Wido,
I have not seen Rohit’s email; I will take a look at it.
About database schema changes happening only in X.Y, I also agree with you
(that is a convention we all could agree on, and such as conding and
release procedures we could have a wiki page for that).
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
On 28-12-15 16:21, Rafael Weingärtner wrote:
> Thanks for your contribution Wido,
> I have not seen Rohit’s email; I will take a look at it.
>
Ok, he has a FS here:
https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+Chimp
> About database schema changes happening only in X.Y, I
not want
to mix topics. Let’s keep this thread strict to discuss database upgrades.
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
The whole upgrade process can probably be divided into a few parts:
1. Apply new schema
2. Data Migration (this is the stored proc updates if you will)
3. Upgrade of system scripts and templates
4. Phased service (agent/management) shutdown and java updates.
As a first step if 1. and 2. can be
[mailto:darren.s.sheph...@gmail.com]
Sent: Tuesday, August 27, 2013 4:48 PM
To: dev@cloudstack.apache.org
Subject: database upgrades
It seems like on startup of the management server
DatabaseUpgradeChecker runs and upgrades the database performing DDL
and DML. Is there a way to upgrade
, August 27, 2013 4:48 PM
To: dev@cloudstack.apache.org
Subject: database upgrades
It seems like on startup of the management server
DatabaseUpgradeChecker runs and upgrades the database performing DDL
and DML. Is there a way to upgrade the database that doesn't include
starting
[mailto:darren.s.sheph...@gmail.com]
Sent: Wednesday, August 28, 2013 9:20 AM
To: dev@cloudstack.apache.org
Cc: dev@cloudstack.apache.org
Subject: Re: database upgrades
Having the ability to do DB migrations on startup isn't bad. Frankly it's
nice
when you don't care, like dev/test. You
It seems like on startup of the management server DatabaseUpgradeChecker
runs and upgrades the database performing DDL and DML. Is there a way
to upgrade the database that doesn't include starting the management server?
Darren
On Tue, Aug 27, 2013 at 04:48:02PM -0700, Darren Shepherd wrote:
It seems like on startup of the management server
DatabaseUpgradeChecker runs and upgrades the database performing DDL
and DML. Is there a way to upgrade the database that doesn't
include starting the management server?
This
Custom java code to manage the database is every DBAs worse nightmare. I'd be
very very interested into moving to an off the shelf DB migration tool. I'd
recommend flyway given the fact that CloudStack only supports mysql and is very
SQL DDL oriented as it stands.
I'll probably look into
36 matches
Mail list logo
