You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Rohit Yadav <ro...@shapeblue.com> on 2014/09/02 15:20:00 UTC
Cherry-picking fix that may change 4.3.1 schema
Hi,
I’m going through list of issues that affect 4.3.0 and 4.3.1 and cherry-picking those which are already fixed elsewhere. This is the issue which would involve some modifications to the schema: https://issues.apache.org/jira/browse/CLOUDSTACK-6756
@Sebatien: can you please take a look at this bug and cherry-pick if we want it in 4.3.1?
It is doable either in the schema upgrade path 4.3.0 to 4.3.1 (sql file) or in the upgrade class.
Since, we’re going to have 4.4.1 soon as well, it makes it tricky how to to deal with upgrade paths. So, at present if 4.4.1 is out already, people on 4.3.1 (in near future) won’t be able to upgrade to 4.4.1 etc. Should in such a case try to release 4.3.1 out first and then 4.4.1?
What about if in future we have more such situations, we perhaps need to fix release management process and policies, one way is to refactor out the db upgrade logic as a separate tool that has a more quick release cycle like cloudmonkey?
Regards,
Rohit Yadav
Software Architect, ShapeBlue
M. +41 779015219 | rohit.yadav@shapeblue.com
Blog: bhaisaab.org | Twitter: @_bhaisaab
Find out more about ShapeBlue and our range of CloudStack related services
IaaS Cloud Design & Build<http://shapeblue.com/iaas-cloud-design-and-build//>
CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/>
CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/>
CloudStack Infrastructure Support<http://shapeblue.com/cloudstack-infrastructure-support/>
CloudStack Bootcamp Training Courses<http://shapeblue.com/cloudstack-training/>
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 are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. 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.
Re: Cherry-picking fix that may change 4.3.1 schema
Posted by Rohit Yadav <ro...@shapeblue.com>.
On 02-Sep-2014, at 6:05 pm, Marcus <sh...@gmail.com> wrote:
> I think we're discussing the matter of policy, rather than this case. Can
> we make this one work, I'm confident you can, Rohit. But as a policy, do
> we want to make changes to DB schemas in minor (bugfix) releases, and I
> think the answer being given is no. Perhaps that means the concrete
> solution is that we don't fix a known bug. Given our track record and that
> we're juggling 4.4.1 and the upcoming 4.5, I'm not entirely sure 4.3.1 will
> even get the time to be tested and released.
As a policy I think we should *not* be doing this, but we also need to support major releases with minor ones as we have to understand that we’ve users using ACS in production.
FYI — we’ve been modifying databases in minor releases as well, checkout Upgrade421to430 and Upgrade420to421, we’re certainly changing databases. Just that we’re not adding new tables, doing something drastic but we’re certainly doing db migrations.
4.3.1 will be unique as it will be released after 4.4.0, and from my $dayjob I know there are some users interested in 4.3.1 and I don’t want to fork ACS for them or create a new distribution.
Regards,
Rohit Yadav
Software Architect, ShapeBlue
M. +41 779015219 | rohit.yadav@shapeblue.com
Blog: bhaisaab.org | Twitter: @_bhaisaab
Find out more about ShapeBlue and our range of CloudStack related services
IaaS Cloud Design & Build<http://shapeblue.com/iaas-cloud-design-and-build//>
CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/>
CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/>
CloudStack Infrastructure Support<http://shapeblue.com/cloudstack-infrastructure-support/>
CloudStack Bootcamp Training Courses<http://shapeblue.com/cloudstack-training/>
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 are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. 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.
Re: Cherry-picking fix that may change 4.3.1 schema
Posted by Marcus <sh...@gmail.com>.
I think we're discussing the matter of policy, rather than this case. Can
we make this one work, I'm confident you can, Rohit. But as a policy, do
we want to make changes to DB schemas in minor (bugfix) releases, and I
think the answer being given is no. Perhaps that means the concrete
solution is that we don't fix a known bug. Given our track record and that
we're juggling 4.4.1 and the upcoming 4.5, I'm not entirely sure 4.3.1 will
even get the time to be tested and released.
On Tue, Sep 2, 2014 at 9:56 AM, Rohit Yadav <ro...@shapeblue.com>
wrote:
>
> On 02-Sep-2014, at 5:40 pm, Rajani Karuturi <ra...@apache.org> wrote:
> > The right way to do this is to do commit to commit migrations and use
> some
> > db versioning tools like liquibase or flywaydb which will execute the new
> > change sets. We discussed this before and IIRC, someone started working
> on
> > it.
>
> This is not a proposal thread to introduce new tools and I would certainly
> avoid the “right way to do things” as I’m a fan of iterative development.
>
> I’m interested in a concrete solution to the concrete issue I raised.
> Here’s how I will do it:
>
> - Fix the issue on 4.3.1, cherry pick and get rid of the 4.3.0 to 4.4.0
> upgrade path
> - Put the db changes in upgrade path from 4.3.0 to 4.3.1, on 4.3 branch
> - Add an upgrade path from 4.3.1 to 4.4.1 on 4.4 branch which counts for
> the above change
> - On 4.4 branch, in the upgrade (db upgrader) map there won’t be an
> upgrade path from 4.3.1 for any class except for the map entry where
> version is 4.3.1
> - Users who upgrade to 4.3.1 can upgrade only to 4.4.1 (they don’t have a
> choice) and the upgrade path will exist only in 4.4.1 and later releases
>
> I think if I do the above, no one will have any issue. I’m sharing them to
> run by you all in case you find any issue?
>
> >
> >
> > On Tue, Sep 2, 2014 at 20:58 PM, Rohit Yadav <ro...@shapeblue.com>
> > wrote:
> >
> >
> > On 02-Sep-2014, at 5:07 pm, Francois Gaudreault <
> fgaudreault@cloudops.com
> > <javascript:;>> wrote:
> >> I see. Well, I think we were impacted by that too, and we made the
> > decision to move on 4.4.1-snap (even if it's technically less stable?)
> and
> > then upgrade to 4.4.1 GA (next week?)
> >>
> >> I personally don't think pulling back DB changes in lower releases is a
> > good idea :S
> >>
> >> But that's only my opinion :)
> >
> > I raised a concrete issue regarding 4.3.1/4.4.1 release and I would like
> to
> > stick to that only. I understand there are too many numbers, versions and
> > branches to follow, so please if you can try to understand the issue;
> >
> > This issue — https://issues.apache.org/jira/browse/CLOUDSTACK-6756
> requires
> > that there are some extra columns in the database to do book keeping when
> > delete ips so you don’t actually delete db/table rows.
> >
> > The issue above is fixed in an upgrade path from 4.3.0 to 4.4.0:
> >
> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blobdiff;f=setup/db/db/schema-430to440.sql;h=226260804523c79e3ce3cfa3c407b5ac698d749c;hp=3b525c41a1befd94c5ffc324c357b566606a97d0;hb=ce6a53e;hpb=d0f806b3a486c58b033083fc57f39dd686e31750
> >
> > But, we already have 4.4.0 release and db upgrade paths are always in the
> > next release versions.
> >
> > So, there is no upgrade path from 4.3.1 to 4.4.0; as 4.3.1 version does
> not
> > care about 4.4.0 schema changes. There is only an upgrade path from 4.3.0
> > to 4.3.1. So, the limitation is that people won’t be able to upgrade from
> > 4.3.1 to 4.4.0, because 4.4.0 is already released.
> >
> > If we release 4.4.1 before 4.3.1, we’ll have the same issue. So, we can
> put
> > the fix from the JIRA issue on 4.3 branch so the issue is fixed for
> 4.3.1.
> > The fix will be in the 4.3.0 to 4.3.1 upgrade path. And, if we release
> > 4.4.1 after 4.3.1, we can fix the upgrade path from 4.3.1 to 4.4.1 on 4.4
> > branch such that
> >
> > The abstract issue is — we’ll have such issue in future, how do we fix
> it.
> > I suggested — we make a separate tool that does (rolling) upgrades.
> >
> > Regards,
> > Rohit Yadav
> > Software Architect, ShapeBlue
> > M. +41 779015219 | rohit.yadav@shapeblue.com <javascript:;>
> > Blog: bhaisaab.org | Twitter: @_bhaisaab
> >
> >
> >
> > Find out more about ShapeBlue and our range of CloudStack related
> services
> >
> > IaaS Cloud Design & Build<
> http://shapeblue.com/iaas-cloud-design-and-build//
> >>
> > CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/>
> > CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/>
> > CloudStack Infrastructure Support<
> > http://shapeblue.com/cloudstack-infrastructure-support/>
> > CloudStack Bootcamp Training Courses<
> > http://shapeblue.com/cloudstack-training/>
> >
> > 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 are not
> the
> > intended recipient of this email, you must neither take any action based
> > upon its contents, nor copy or show it to anyone. Please contact the
> sender
> > if you believe you have received this email in error. 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.
> >
> >
> >
> > --
> > ~Rajani
> > Sent from Windows Phone
>
> Regards,
> Rohit Yadav
> Software Architect, ShapeBlue
> M. +41 779015219 | rohit.yadav@shapeblue.com
> Blog: bhaisaab.org | Twitter: @_bhaisaab
>
>
>
> Find out more about ShapeBlue and our range of CloudStack related services
>
> IaaS Cloud Design & Build<
> http://shapeblue.com/iaas-cloud-design-and-build//>
> CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/>
> CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/>
> CloudStack Infrastructure Support<
> http://shapeblue.com/cloudstack-infrastructure-support/>
> CloudStack Bootcamp Training Courses<
> http://shapeblue.com/cloudstack-training/>
>
> 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 are not the
> intended recipient of this email, you must neither take any action based
> upon its contents, nor copy or show it to anyone. Please contact the sender
> if you believe you have received this email in error. 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.
>
Re: Cherry-picking fix that may change 4.3.1 schema
Posted by Rohit Yadav <ro...@shapeblue.com>.
On 02-Sep-2014, at 6:19 pm, Will Stevens <ws...@cloudops.com> wrote:
> I think this covers the main use case we have to be concerned about, so I
> think this is fine. I don't think we should have to worry about upgrading
> from 4.3.1 to 4.4.0. I agree that if we maintain an upgrade path from
> 4.3.1 to 4.4.1, we should be fine.
Alright so I’m dropping this issue, we’re not going to cherry pick it on 4.3. I would still go ahead and implement an upgrade path from 4.3.1 to 4.4.1. I’ll add an upgrade path and have a hotfix branch for Daan to review.
> *Will STEVENS*
> Lead Developer
>
> *CloudOps* *| *Cloud Solutions Experts
> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
> w cloudops.com *|* tw @CloudOps_
>
>
> On Tue, Sep 2, 2014 at 11:56 AM, Rohit Yadav <ro...@shapeblue.com>
> wrote:
>
>>
>> On 02-Sep-2014, at 5:40 pm, Rajani Karuturi <ra...@apache.org> wrote:
>>> The right way to do this is to do commit to commit migrations and use
>> some
>>> db versioning tools like liquibase or flywaydb which will execute the new
>>> change sets. We discussed this before and IIRC, someone started working
>> on
>>> it.
>>
>> This is not a proposal thread to introduce new tools and I would certainly
>> avoid the “right way to do things” as I’m a fan of iterative development.
>>
>> I’m interested in a concrete solution to the concrete issue I raised.
>> Here’s how I will do it:
>>
>> - Fix the issue on 4.3.1, cherry pick and get rid of the 4.3.0 to 4.4.0
>> upgrade path
>> - Put the db changes in upgrade path from 4.3.0 to 4.3.1, on 4.3 branch
>> - Add an upgrade path from 4.3.1 to 4.4.1 on 4.4 branch which counts for
>> the above change
>> - On 4.4 branch, in the upgrade (db upgrader) map there won’t be an
>> upgrade path from 4.3.1 for any class except for the map entry where
>> version is 4.3.1
>> - Users who upgrade to 4.3.1 can upgrade only to 4.4.1 (they don’t have a
>> choice) and the upgrade path will exist only in 4.4.1 and later releases
>>
>> I think if I do the above, no one will have any issue. I’m sharing them to
>> run by you all in case you find any issue?
>>
>>>
>>>
>>> On Tue, Sep 2, 2014 at 20:58 PM, Rohit Yadav <ro...@shapeblue.com>
>>> wrote:
>>>
>>>
>>> On 02-Sep-2014, at 5:07 pm, Francois Gaudreault <
>> fgaudreault@cloudops.com
>>> <javascript:;>> wrote:
>>>> I see. Well, I think we were impacted by that too, and we made the
>>> decision to move on 4.4.1-snap (even if it's technically less stable?)
>> and
>>> then upgrade to 4.4.1 GA (next week?)
>>>>
>>>> I personally don't think pulling back DB changes in lower releases is a
>>> good idea :S
>>>>
>>>> But that's only my opinion :)
>>>
>>> I raised a concrete issue regarding 4.3.1/4.4.1 release and I would like
>> to
>>> stick to that only. I understand there are too many numbers, versions and
>>> branches to follow, so please if you can try to understand the issue;
>>>
>>> This issue — https://issues.apache.org/jira/browse/CLOUDSTACK-6756
>> requires
>>> that there are some extra columns in the database to do book keeping when
>>> delete ips so you don’t actually delete db/table rows.
>>>
>>> The issue above is fixed in an upgrade path from 4.3.0 to 4.4.0:
>>>
>> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blobdiff;f=setup/db/db/schema-430to440.sql;h=226260804523c79e3ce3cfa3c407b5ac698d749c;hp=3b525c41a1befd94c5ffc324c357b566606a97d0;hb=ce6a53e;hpb=d0f806b3a486c58b033083fc57f39dd686e31750
>>>
>>> But, we already have 4.4.0 release and db upgrade paths are always in the
>>> next release versions.
>>>
>>> So, there is no upgrade path from 4.3.1 to 4.4.0; as 4.3.1 version does
>> not
>>> care about 4.4.0 schema changes. There is only an upgrade path from 4.3.0
>>> to 4.3.1. So, the limitation is that people won’t be able to upgrade from
>>> 4.3.1 to 4.4.0, because 4.4.0 is already released.
>>>
>>> If we release 4.4.1 before 4.3.1, we’ll have the same issue. So, we can
>> put
>>> the fix from the JIRA issue on 4.3 branch so the issue is fixed for
>> 4.3.1.
>>> The fix will be in the 4.3.0 to 4.3.1 upgrade path. And, if we release
>>> 4.4.1 after 4.3.1, we can fix the upgrade path from 4.3.1 to 4.4.1 on 4.4
>>> branch such that
>>>
>>> The abstract issue is — we’ll have such issue in future, how do we fix
>> it.
>>> I suggested — we make a separate tool that does (rolling) upgrades.
>>>
>>> Regards,
>>> Rohit Yadav
>>> Software Architect, ShapeBlue
>>> M. +41 779015219 | rohit.yadav@shapeblue.com <javascript:;>
>>> Blog: bhaisaab.org | Twitter: @_bhaisaab
>>>
>>>
>>>
>>> Find out more about ShapeBlue and our range of CloudStack related
>> services
>>>
>>> IaaS Cloud Design & Build<
>> http://shapeblue.com/iaas-cloud-design-and-build//
>>>>
>>> CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/>
>>> CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/>
>>> CloudStack Infrastructure Support<
>>> http://shapeblue.com/cloudstack-infrastructure-support/>
>>> CloudStack Bootcamp Training Courses<
>>> http://shapeblue.com/cloudstack-training/>
>>>
>>> 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 are not
>> the
>>> intended recipient of this email, you must neither take any action based
>>> upon its contents, nor copy or show it to anyone. Please contact the
>> sender
>>> if you believe you have received this email in error. 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.
>>>
>>>
>>>
>>> --
>>> ~Rajani
>>> Sent from Windows Phone
>>
>> Regards,
>> Rohit Yadav
>> Software Architect, ShapeBlue
>> M. +41 779015219 | rohit.yadav@shapeblue.com
>> Blog: bhaisaab.org | Twitter: @_bhaisaab
>>
>>
>>
>> Find out more about ShapeBlue and our range of CloudStack related services
>>
>> IaaS Cloud Design & Build<
>> http://shapeblue.com/iaas-cloud-design-and-build//>
>> CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/>
>> CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/>
>> CloudStack Infrastructure Support<
>> http://shapeblue.com/cloudstack-infrastructure-support/>
>> CloudStack Bootcamp Training Courses<
>> http://shapeblue.com/cloudstack-training/>
>>
>> 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 are not the
>> intended recipient of this email, you must neither take any action based
>> upon its contents, nor copy or show it to anyone. Please contact the sender
>> if you believe you have received this email in error. 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.
>>
Regards,
Rohit Yadav
Software Architect, ShapeBlue
M. +41 779015219 | rohit.yadav@shapeblue.com
Blog: bhaisaab.org | Twitter: @_bhaisaab
Find out more about ShapeBlue and our range of CloudStack related services
IaaS Cloud Design & Build<http://shapeblue.com/iaas-cloud-design-and-build//>
CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/>
CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/>
CloudStack Infrastructure Support<http://shapeblue.com/cloudstack-infrastructure-support/>
CloudStack Bootcamp Training Courses<http://shapeblue.com/cloudstack-training/>
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 are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. 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.
Re: Cherry-picking fix that may change 4.3.1 schema
Posted by Will Stevens <ws...@cloudops.com>.
I think this covers the main use case we have to be concerned about, so I
think this is fine. I don't think we should have to worry about upgrading
from 4.3.1 to 4.4.0. I agree that if we maintain an upgrade path from
4.3.1 to 4.4.1, we should be fine.
*Will STEVENS*
Lead Developer
*CloudOps* *| *Cloud Solutions Experts
420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
w cloudops.com *|* tw @CloudOps_
On Tue, Sep 2, 2014 at 11:56 AM, Rohit Yadav <ro...@shapeblue.com>
wrote:
>
> On 02-Sep-2014, at 5:40 pm, Rajani Karuturi <ra...@apache.org> wrote:
> > The right way to do this is to do commit to commit migrations and use
> some
> > db versioning tools like liquibase or flywaydb which will execute the new
> > change sets. We discussed this before and IIRC, someone started working
> on
> > it.
>
> This is not a proposal thread to introduce new tools and I would certainly
> avoid the “right way to do things” as I’m a fan of iterative development.
>
> I’m interested in a concrete solution to the concrete issue I raised.
> Here’s how I will do it:
>
> - Fix the issue on 4.3.1, cherry pick and get rid of the 4.3.0 to 4.4.0
> upgrade path
> - Put the db changes in upgrade path from 4.3.0 to 4.3.1, on 4.3 branch
> - Add an upgrade path from 4.3.1 to 4.4.1 on 4.4 branch which counts for
> the above change
> - On 4.4 branch, in the upgrade (db upgrader) map there won’t be an
> upgrade path from 4.3.1 for any class except for the map entry where
> version is 4.3.1
> - Users who upgrade to 4.3.1 can upgrade only to 4.4.1 (they don’t have a
> choice) and the upgrade path will exist only in 4.4.1 and later releases
>
> I think if I do the above, no one will have any issue. I’m sharing them to
> run by you all in case you find any issue?
>
> >
> >
> > On Tue, Sep 2, 2014 at 20:58 PM, Rohit Yadav <ro...@shapeblue.com>
> > wrote:
> >
> >
> > On 02-Sep-2014, at 5:07 pm, Francois Gaudreault <
> fgaudreault@cloudops.com
> > <javascript:;>> wrote:
> >> I see. Well, I think we were impacted by that too, and we made the
> > decision to move on 4.4.1-snap (even if it's technically less stable?)
> and
> > then upgrade to 4.4.1 GA (next week?)
> >>
> >> I personally don't think pulling back DB changes in lower releases is a
> > good idea :S
> >>
> >> But that's only my opinion :)
> >
> > I raised a concrete issue regarding 4.3.1/4.4.1 release and I would like
> to
> > stick to that only. I understand there are too many numbers, versions and
> > branches to follow, so please if you can try to understand the issue;
> >
> > This issue — https://issues.apache.org/jira/browse/CLOUDSTACK-6756
> requires
> > that there are some extra columns in the database to do book keeping when
> > delete ips so you don’t actually delete db/table rows.
> >
> > The issue above is fixed in an upgrade path from 4.3.0 to 4.4.0:
> >
> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blobdiff;f=setup/db/db/schema-430to440.sql;h=226260804523c79e3ce3cfa3c407b5ac698d749c;hp=3b525c41a1befd94c5ffc324c357b566606a97d0;hb=ce6a53e;hpb=d0f806b3a486c58b033083fc57f39dd686e31750
> >
> > But, we already have 4.4.0 release and db upgrade paths are always in the
> > next release versions.
> >
> > So, there is no upgrade path from 4.3.1 to 4.4.0; as 4.3.1 version does
> not
> > care about 4.4.0 schema changes. There is only an upgrade path from 4.3.0
> > to 4.3.1. So, the limitation is that people won’t be able to upgrade from
> > 4.3.1 to 4.4.0, because 4.4.0 is already released.
> >
> > If we release 4.4.1 before 4.3.1, we’ll have the same issue. So, we can
> put
> > the fix from the JIRA issue on 4.3 branch so the issue is fixed for
> 4.3.1.
> > The fix will be in the 4.3.0 to 4.3.1 upgrade path. And, if we release
> > 4.4.1 after 4.3.1, we can fix the upgrade path from 4.3.1 to 4.4.1 on 4.4
> > branch such that
> >
> > The abstract issue is — we’ll have such issue in future, how do we fix
> it.
> > I suggested — we make a separate tool that does (rolling) upgrades.
> >
> > Regards,
> > Rohit Yadav
> > Software Architect, ShapeBlue
> > M. +41 779015219 | rohit.yadav@shapeblue.com <javascript:;>
> > Blog: bhaisaab.org | Twitter: @_bhaisaab
> >
> >
> >
> > Find out more about ShapeBlue and our range of CloudStack related
> services
> >
> > IaaS Cloud Design & Build<
> http://shapeblue.com/iaas-cloud-design-and-build//
> >>
> > CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/>
> > CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/>
> > CloudStack Infrastructure Support<
> > http://shapeblue.com/cloudstack-infrastructure-support/>
> > CloudStack Bootcamp Training Courses<
> > http://shapeblue.com/cloudstack-training/>
> >
> > 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 are not
> the
> > intended recipient of this email, you must neither take any action based
> > upon its contents, nor copy or show it to anyone. Please contact the
> sender
> > if you believe you have received this email in error. 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.
> >
> >
> >
> > --
> > ~Rajani
> > Sent from Windows Phone
>
> Regards,
> Rohit Yadav
> Software Architect, ShapeBlue
> M. +41 779015219 | rohit.yadav@shapeblue.com
> Blog: bhaisaab.org | Twitter: @_bhaisaab
>
>
>
> Find out more about ShapeBlue and our range of CloudStack related services
>
> IaaS Cloud Design & Build<
> http://shapeblue.com/iaas-cloud-design-and-build//>
> CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/>
> CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/>
> CloudStack Infrastructure Support<
> http://shapeblue.com/cloudstack-infrastructure-support/>
> CloudStack Bootcamp Training Courses<
> http://shapeblue.com/cloudstack-training/>
>
> 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 are not the
> intended recipient of this email, you must neither take any action based
> upon its contents, nor copy or show it to anyone. Please contact the sender
> if you believe you have received this email in error. 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.
>
Re: Cherry-picking fix that may change 4.3.1 schema
Posted by David Nalley <da...@gnsa.us>.
On Wed, Sep 3, 2014 at 3:02 AM, Sebastien Goasguen <ru...@gmail.com> wrote:
>
> On Sep 2, 2014, at 11:59 PM, Rajani Karuturi <ra...@apache.org> wrote:
>
>> this was to your suggestion of "a separate tool that does (rolling)
>> upgrades" which i think is a new proposal. I should have made it clear in
>> my mail about it and should have started it with "right way according to
>> me".
>>
>> "right way to do things" is in no way against iterative development. May be
>> at a stage one would realise it was not the right way.
>>
>> Anyways, thanks for the gyan. I would stay away from any such discussions
>> in future.
>>
>
> Please don't. Discussion is important and sometimes they are hard.
>
> We are dealing with several important changes right now (git, CI, db, releases etc..) and we need to keep at it.
>
> Folks will have different opinions and express them differently but we need to keep discussing to make progress :)
>
Yes; please - don't stop discussing such things.
Occasionally there are disagreements and there are frustrations, but
thats part of the process; such discussions are valuable.
--David
Re: Cherry-picking fix that may change 4.3.1 schema
Posted by Sebastien Goasguen <ru...@gmail.com>.
On Sep 2, 2014, at 11:59 PM, Rajani Karuturi <ra...@apache.org> wrote:
> this was to your suggestion of "a separate tool that does (rolling)
> upgrades" which i think is a new proposal. I should have made it clear in
> my mail about it and should have started it with "right way according to
> me".
>
> "right way to do things" is in no way against iterative development. May be
> at a stage one would realise it was not the right way.
>
> Anyways, thanks for the gyan. I would stay away from any such discussions
> in future.
>
Please don't. Discussion is important and sometimes they are hard.
We are dealing with several important changes right now (git, CI, db, releases etc..) and we need to keep at it.
Folks will have different opinions and express them differently but we need to keep discussing to make progress :)
> ~Rajani
>
>
> On Tue, Sep 2, 2014 at 9:26 PM, Rohit Yadav <ro...@shapeblue.com>
> wrote:
>
>>
>> On 02-Sep-2014, at 5:40 pm, Rajani Karuturi <ra...@apache.org> wrote:
>>> The right way to do this is to do commit to commit migrations and use
>> some
>>> db versioning tools like liquibase or flywaydb which will execute the new
>>> change sets. We discussed this before and IIRC, someone started working
>> on
>>> it.
>>
>> This is not a proposal thread to introduce new tools and I would certainly
>> avoid the “right way to do things” as I’m a fan of iterative development.
>>
>> I’m interested in a concrete solution to the concrete issue I raised.
>> Here’s how I will do it:
>>
>> - Fix the issue on 4.3.1, cherry pick and get rid of the 4.3.0 to 4.4.0
>> upgrade path
>> - Put the db changes in upgrade path from 4.3.0 to 4.3.1, on 4.3 branch
>> - Add an upgrade path from 4.3.1 to 4.4.1 on 4.4 branch which counts for
>> the above change
>> - On 4.4 branch, in the upgrade (db upgrader) map there won’t be an
>> upgrade path from 4.3.1 for any class except for the map entry where
>> version is 4.3.1
>> - Users who upgrade to 4.3.1 can upgrade only to 4.4.1 (they don’t have a
>> choice) and the upgrade path will exist only in 4.4.1 and later releases
>>
>> I think if I do the above, no one will have any issue. I’m sharing them to
>> run by you all in case you find any issue?
>>
>>>
>>>
>>> On Tue, Sep 2, 2014 at 20:58 PM, Rohit Yadav <ro...@shapeblue.com>
>>> wrote:
>>>
>>>
>>> On 02-Sep-2014, at 5:07 pm, Francois Gaudreault <
>> fgaudreault@cloudops.com
>>> <javascript:;>> wrote:
>>>> I see. Well, I think we were impacted by that too, and we made the
>>> decision to move on 4.4.1-snap (even if it's technically less stable?)
>> and
>>> then upgrade to 4.4.1 GA (next week?)
>>>>
>>>> I personally don't think pulling back DB changes in lower releases is a
>>> good idea :S
>>>>
>>>> But that's only my opinion :)
>>>
>>> I raised a concrete issue regarding 4.3.1/4.4.1 release and I would like
>> to
>>> stick to that only. I understand there are too many numbers, versions and
>>> branches to follow, so please if you can try to understand the issue;
>>>
>>> This issue — https://issues.apache.org/jira/browse/CLOUDSTACK-6756
>> requires
>>> that there are some extra columns in the database to do book keeping when
>>> delete ips so you don’t actually delete db/table rows.
>>>
>>> The issue above is fixed in an upgrade path from 4.3.0 to 4.4.0:
>>>
>> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blobdiff;f=setup/db/db/schema-430to440.sql;h=226260804523c79e3ce3cfa3c407b5ac698d749c;hp=3b525c41a1befd94c5ffc324c357b566606a97d0;hb=ce6a53e;hpb=d0f806b3a486c58b033083fc57f39dd686e31750
>>>
>>> But, we already have 4.4.0 release and db upgrade paths are always in the
>>> next release versions.
>>>
>>> So, there is no upgrade path from 4.3.1 to 4.4.0; as 4.3.1 version does
>> not
>>> care about 4.4.0 schema changes. There is only an upgrade path from 4.3.0
>>> to 4.3.1. So, the limitation is that people won’t be able to upgrade from
>>> 4.3.1 to 4.4.0, because 4.4.0 is already released.
>>>
>>> If we release 4.4.1 before 4.3.1, we’ll have the same issue. So, we can
>> put
>>> the fix from the JIRA issue on 4.3 branch so the issue is fixed for
>> 4.3.1.
>>> The fix will be in the 4.3.0 to 4.3.1 upgrade path. And, if we release
>>> 4.4.1 after 4.3.1, we can fix the upgrade path from 4.3.1 to 4.4.1 on 4.4
>>> branch such that
>>>
>>> The abstract issue is — we’ll have such issue in future, how do we fix
>> it.
>>> I suggested — we make a separate tool that does (rolling) upgrades.
>>>
>>> Regards,
>>> Rohit Yadav
>>> Software Architect, ShapeBlue
>>> M. +41 779015219 | rohit.yadav@shapeblue.com <javascript:;>
>>> Blog: bhaisaab.org | Twitter: @_bhaisaab
>>>
>>>
>>>
>>> Find out more about ShapeBlue and our range of CloudStack related
>> services
>>>
>>> IaaS Cloud Design & Build<
>> http://shapeblue.com/iaas-cloud-design-and-build//
>>>>
>>> CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/>
>>> CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/>
>>> CloudStack Infrastructure Support<
>>> http://shapeblue.com/cloudstack-infrastructure-support/>
>>> CloudStack Bootcamp Training Courses<
>>> http://shapeblue.com/cloudstack-training/>
>>>
>>> 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 are not
>> the
>>> intended recipient of this email, you must neither take any action based
>>> upon its contents, nor copy or show it to anyone. Please contact the
>> sender
>>> if you believe you have received this email in error. 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.
>>>
>>>
>>>
>>> --
>>> ~Rajani
>>> Sent from Windows Phone
>>
>> Regards,
>> Rohit Yadav
>> Software Architect, ShapeBlue
>> M. +41 779015219 | rohit.yadav@shapeblue.com
>> Blog: bhaisaab.org | Twitter: @_bhaisaab
>>
>>
>>
>> Find out more about ShapeBlue and our range of CloudStack related services
>>
>> IaaS Cloud Design & Build<
>> http://shapeblue.com/iaas-cloud-design-and-build//>
>> CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/>
>> CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/>
>> CloudStack Infrastructure Support<
>> http://shapeblue.com/cloudstack-infrastructure-support/>
>> CloudStack Bootcamp Training Courses<
>> http://shapeblue.com/cloudstack-training/>
>>
>> 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 are not the
>> intended recipient of this email, you must neither take any action based
>> upon its contents, nor copy or show it to anyone. Please contact the sender
>> if you believe you have received this email in error. 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.
>>
Re: Cherry-picking fix that may change 4.3.1 schema
Posted by Rajani Karuturi <ra...@apache.org>.
this was to your suggestion of "a separate tool that does (rolling)
upgrades" which i think is a new proposal. I should have made it clear in
my mail about it and should have started it with "right way according to
me".
"right way to do things" is in no way against iterative development. May be
at a stage one would realise it was not the right way.
Anyways, thanks for the gyan. I would stay away from any such discussions
in future.
~Rajani
On Tue, Sep 2, 2014 at 9:26 PM, Rohit Yadav <ro...@shapeblue.com>
wrote:
>
> On 02-Sep-2014, at 5:40 pm, Rajani Karuturi <ra...@apache.org> wrote:
> > The right way to do this is to do commit to commit migrations and use
> some
> > db versioning tools like liquibase or flywaydb which will execute the new
> > change sets. We discussed this before and IIRC, someone started working
> on
> > it.
>
> This is not a proposal thread to introduce new tools and I would certainly
> avoid the “right way to do things” as I’m a fan of iterative development.
>
> I’m interested in a concrete solution to the concrete issue I raised.
> Here’s how I will do it:
>
> - Fix the issue on 4.3.1, cherry pick and get rid of the 4.3.0 to 4.4.0
> upgrade path
> - Put the db changes in upgrade path from 4.3.0 to 4.3.1, on 4.3 branch
> - Add an upgrade path from 4.3.1 to 4.4.1 on 4.4 branch which counts for
> the above change
> - On 4.4 branch, in the upgrade (db upgrader) map there won’t be an
> upgrade path from 4.3.1 for any class except for the map entry where
> version is 4.3.1
> - Users who upgrade to 4.3.1 can upgrade only to 4.4.1 (they don’t have a
> choice) and the upgrade path will exist only in 4.4.1 and later releases
>
> I think if I do the above, no one will have any issue. I’m sharing them to
> run by you all in case you find any issue?
>
> >
> >
> > On Tue, Sep 2, 2014 at 20:58 PM, Rohit Yadav <ro...@shapeblue.com>
> > wrote:
> >
> >
> > On 02-Sep-2014, at 5:07 pm, Francois Gaudreault <
> fgaudreault@cloudops.com
> > <javascript:;>> wrote:
> >> I see. Well, I think we were impacted by that too, and we made the
> > decision to move on 4.4.1-snap (even if it's technically less stable?)
> and
> > then upgrade to 4.4.1 GA (next week?)
> >>
> >> I personally don't think pulling back DB changes in lower releases is a
> > good idea :S
> >>
> >> But that's only my opinion :)
> >
> > I raised a concrete issue regarding 4.3.1/4.4.1 release and I would like
> to
> > stick to that only. I understand there are too many numbers, versions and
> > branches to follow, so please if you can try to understand the issue;
> >
> > This issue — https://issues.apache.org/jira/browse/CLOUDSTACK-6756
> requires
> > that there are some extra columns in the database to do book keeping when
> > delete ips so you don’t actually delete db/table rows.
> >
> > The issue above is fixed in an upgrade path from 4.3.0 to 4.4.0:
> >
> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blobdiff;f=setup/db/db/schema-430to440.sql;h=226260804523c79e3ce3cfa3c407b5ac698d749c;hp=3b525c41a1befd94c5ffc324c357b566606a97d0;hb=ce6a53e;hpb=d0f806b3a486c58b033083fc57f39dd686e31750
> >
> > But, we already have 4.4.0 release and db upgrade paths are always in the
> > next release versions.
> >
> > So, there is no upgrade path from 4.3.1 to 4.4.0; as 4.3.1 version does
> not
> > care about 4.4.0 schema changes. There is only an upgrade path from 4.3.0
> > to 4.3.1. So, the limitation is that people won’t be able to upgrade from
> > 4.3.1 to 4.4.0, because 4.4.0 is already released.
> >
> > If we release 4.4.1 before 4.3.1, we’ll have the same issue. So, we can
> put
> > the fix from the JIRA issue on 4.3 branch so the issue is fixed for
> 4.3.1.
> > The fix will be in the 4.3.0 to 4.3.1 upgrade path. And, if we release
> > 4.4.1 after 4.3.1, we can fix the upgrade path from 4.3.1 to 4.4.1 on 4.4
> > branch such that
> >
> > The abstract issue is — we’ll have such issue in future, how do we fix
> it.
> > I suggested — we make a separate tool that does (rolling) upgrades.
> >
> > Regards,
> > Rohit Yadav
> > Software Architect, ShapeBlue
> > M. +41 779015219 | rohit.yadav@shapeblue.com <javascript:;>
> > Blog: bhaisaab.org | Twitter: @_bhaisaab
> >
> >
> >
> > Find out more about ShapeBlue and our range of CloudStack related
> services
> >
> > IaaS Cloud Design & Build<
> http://shapeblue.com/iaas-cloud-design-and-build//
> >>
> > CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/>
> > CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/>
> > CloudStack Infrastructure Support<
> > http://shapeblue.com/cloudstack-infrastructure-support/>
> > CloudStack Bootcamp Training Courses<
> > http://shapeblue.com/cloudstack-training/>
> >
> > 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 are not
> the
> > intended recipient of this email, you must neither take any action based
> > upon its contents, nor copy or show it to anyone. Please contact the
> sender
> > if you believe you have received this email in error. 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.
> >
> >
> >
> > --
> > ~Rajani
> > Sent from Windows Phone
>
> Regards,
> Rohit Yadav
> Software Architect, ShapeBlue
> M. +41 779015219 | rohit.yadav@shapeblue.com
> Blog: bhaisaab.org | Twitter: @_bhaisaab
>
>
>
> Find out more about ShapeBlue and our range of CloudStack related services
>
> IaaS Cloud Design & Build<
> http://shapeblue.com/iaas-cloud-design-and-build//>
> CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/>
> CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/>
> CloudStack Infrastructure Support<
> http://shapeblue.com/cloudstack-infrastructure-support/>
> CloudStack Bootcamp Training Courses<
> http://shapeblue.com/cloudstack-training/>
>
> 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 are not the
> intended recipient of this email, you must neither take any action based
> upon its contents, nor copy or show it to anyone. Please contact the sender
> if you believe you have received this email in error. 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.
>
Re: Cherry-picking fix that may change 4.3.1 schema
Posted by Sebastien Goasguen <ru...@gmail.com>.
On Sep 2, 2014, at 11:56 AM, Rohit Yadav <ro...@shapeblue.com> wrote:
>
> On 02-Sep-2014, at 5:40 pm, Rajani Karuturi <ra...@apache.org> wrote:
>> The right way to do this is to do commit to commit migrations and use some
>> db versioning tools like liquibase or flywaydb which will execute the new
>> change sets. We discussed this before and IIRC, someone started working on
>> it.
>
> This is not a proposal thread to introduce new tools and I would certainly avoid the “right way to do things” as I’m a fan of iterative development.
>
> I’m interested in a concrete solution to the concrete issue I raised. Here’s how I will do it:
>
> - Fix the issue on 4.3.1, cherry pick and get rid of the 4.3.0 to 4.4.0 upgrade path
> - Put the db changes in upgrade path from 4.3.0 to 4.3.1, on 4.3 branch
> - Add an upgrade path from 4.3.1 to 4.4.1 on 4.4 branch which counts for the above change
> - On 4.4 branch, in the upgrade (db upgrader) map there won’t be an upgrade path from 4.3.1 for any class except for the map entry where version is 4.3.1
> - Users who upgrade to 4.3.1 can upgrade only to 4.4.1 (they don’t have a choice) and the upgrade path will exist only in 4.4.1 and later releases
>
> I think if I do the above, no one will have any issue. I’m sharing them to run by you all in case you find any issue?
>
Or:
#1: we don't release 4.3.1
The main reason that I wanted to do 4.3.1 is to start providing some sort of LTS…but maybe our LTS strategy is to move towards rolling upgrades.
>>
>>
>> On Tue, Sep 2, 2014 at 20:58 PM, Rohit Yadav <ro...@shapeblue.com>
>> wrote:
>>
>>
>> On 02-Sep-2014, at 5:07 pm, Francois Gaudreault <fgaudreault@cloudops.com
>> <javascript:;>> wrote:
>>> I see. Well, I think we were impacted by that too, and we made the
>> decision to move on 4.4.1-snap (even if it's technically less stable?) and
>> then upgrade to 4.4.1 GA (next week?)
>>>
>>> I personally don't think pulling back DB changes in lower releases is a
>> good idea :S
>>>
>>> But that's only my opinion :)
>>
>> I raised a concrete issue regarding 4.3.1/4.4.1 release and I would like to
>> stick to that only. I understand there are too many numbers, versions and
>> branches to follow, so please if you can try to understand the issue;
>>
>> This issue — https://issues.apache.org/jira/browse/CLOUDSTACK-6756 requires
>> that there are some extra columns in the database to do book keeping when
>> delete ips so you don’t actually delete db/table rows.
>>
>> The issue above is fixed in an upgrade path from 4.3.0 to 4.4.0:
>> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blobdiff;f=setup/db/db/schema-430to440.sql;h=226260804523c79e3ce3cfa3c407b5ac698d749c;hp=3b525c41a1befd94c5ffc324c357b566606a97d0;hb=ce6a53e;hpb=d0f806b3a486c58b033083fc57f39dd686e31750
>>
>> But, we already have 4.4.0 release and db upgrade paths are always in the
>> next release versions.
>>
>> So, there is no upgrade path from 4.3.1 to 4.4.0; as 4.3.1 version does not
>> care about 4.4.0 schema changes. There is only an upgrade path from 4.3.0
>> to 4.3.1. So, the limitation is that people won’t be able to upgrade from
>> 4.3.1 to 4.4.0, because 4.4.0 is already released.
>>
>> If we release 4.4.1 before 4.3.1, we’ll have the same issue. So, we can put
>> the fix from the JIRA issue on 4.3 branch so the issue is fixed for 4.3.1.
>> The fix will be in the 4.3.0 to 4.3.1 upgrade path. And, if we release
>> 4.4.1 after 4.3.1, we can fix the upgrade path from 4.3.1 to 4.4.1 on 4.4
>> branch such that
>>
>> The abstract issue is — we’ll have such issue in future, how do we fix it.
>> I suggested — we make a separate tool that does (rolling) upgrades.
>>
>> Regards,
>> Rohit Yadav
>> Software Architect, ShapeBlue
>> M. +41 779015219 | rohit.yadav@shapeblue.com <javascript:;>
>> Blog: bhaisaab.org | Twitter: @_bhaisaab
>>
>>
>>
>> Find out more about ShapeBlue and our range of CloudStack related services
>>
>> IaaS Cloud Design & Build<http://shapeblue.com/iaas-cloud-design-and-build//
>>>
>> CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/>
>> CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/>
>> CloudStack Infrastructure Support<
>> http://shapeblue.com/cloudstack-infrastructure-support/>
>> CloudStack Bootcamp Training Courses<
>> http://shapeblue.com/cloudstack-training/>
>>
>> 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 are not the
>> intended recipient of this email, you must neither take any action based
>> upon its contents, nor copy or show it to anyone. Please contact the sender
>> if you believe you have received this email in error. 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.
>>
>>
>>
>> --
>> ~Rajani
>> Sent from Windows Phone
>
> Regards,
> Rohit Yadav
> Software Architect, ShapeBlue
> M. +41 779015219 | rohit.yadav@shapeblue.com
> Blog: bhaisaab.org | Twitter: @_bhaisaab
>
>
>
> Find out more about ShapeBlue and our range of CloudStack related services
>
> IaaS Cloud Design & Build<http://shapeblue.com/iaas-cloud-design-and-build//>
> CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/>
> CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/>
> CloudStack Infrastructure Support<http://shapeblue.com/cloudstack-infrastructure-support/>
> CloudStack Bootcamp Training Courses<http://shapeblue.com/cloudstack-training/>
>
> 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 are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. 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.
Re: Cherry-picking fix that may change 4.3.1 schema
Posted by Rohit Yadav <ro...@shapeblue.com>.
On 02-Sep-2014, at 5:40 pm, Rajani Karuturi <ra...@apache.org> wrote:
> The right way to do this is to do commit to commit migrations and use some
> db versioning tools like liquibase or flywaydb which will execute the new
> change sets. We discussed this before and IIRC, someone started working on
> it.
This is not a proposal thread to introduce new tools and I would certainly avoid the “right way to do things” as I’m a fan of iterative development.
I’m interested in a concrete solution to the concrete issue I raised. Here’s how I will do it:
- Fix the issue on 4.3.1, cherry pick and get rid of the 4.3.0 to 4.4.0 upgrade path
- Put the db changes in upgrade path from 4.3.0 to 4.3.1, on 4.3 branch
- Add an upgrade path from 4.3.1 to 4.4.1 on 4.4 branch which counts for the above change
- On 4.4 branch, in the upgrade (db upgrader) map there won’t be an upgrade path from 4.3.1 for any class except for the map entry where version is 4.3.1
- Users who upgrade to 4.3.1 can upgrade only to 4.4.1 (they don’t have a choice) and the upgrade path will exist only in 4.4.1 and later releases
I think if I do the above, no one will have any issue. I’m sharing them to run by you all in case you find any issue?
>
>
> On Tue, Sep 2, 2014 at 20:58 PM, Rohit Yadav <ro...@shapeblue.com>
> wrote:
>
>
> On 02-Sep-2014, at 5:07 pm, Francois Gaudreault <fgaudreault@cloudops.com
> <javascript:;>> wrote:
>> I see. Well, I think we were impacted by that too, and we made the
> decision to move on 4.4.1-snap (even if it's technically less stable?) and
> then upgrade to 4.4.1 GA (next week?)
>>
>> I personally don't think pulling back DB changes in lower releases is a
> good idea :S
>>
>> But that's only my opinion :)
>
> I raised a concrete issue regarding 4.3.1/4.4.1 release and I would like to
> stick to that only. I understand there are too many numbers, versions and
> branches to follow, so please if you can try to understand the issue;
>
> This issue — https://issues.apache.org/jira/browse/CLOUDSTACK-6756 requires
> that there are some extra columns in the database to do book keeping when
> delete ips so you don’t actually delete db/table rows.
>
> The issue above is fixed in an upgrade path from 4.3.0 to 4.4.0:
> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blobdiff;f=setup/db/db/schema-430to440.sql;h=226260804523c79e3ce3cfa3c407b5ac698d749c;hp=3b525c41a1befd94c5ffc324c357b566606a97d0;hb=ce6a53e;hpb=d0f806b3a486c58b033083fc57f39dd686e31750
>
> But, we already have 4.4.0 release and db upgrade paths are always in the
> next release versions.
>
> So, there is no upgrade path from 4.3.1 to 4.4.0; as 4.3.1 version does not
> care about 4.4.0 schema changes. There is only an upgrade path from 4.3.0
> to 4.3.1. So, the limitation is that people won’t be able to upgrade from
> 4.3.1 to 4.4.0, because 4.4.0 is already released.
>
> If we release 4.4.1 before 4.3.1, we’ll have the same issue. So, we can put
> the fix from the JIRA issue on 4.3 branch so the issue is fixed for 4.3.1.
> The fix will be in the 4.3.0 to 4.3.1 upgrade path. And, if we release
> 4.4.1 after 4.3.1, we can fix the upgrade path from 4.3.1 to 4.4.1 on 4.4
> branch such that
>
> The abstract issue is — we’ll have such issue in future, how do we fix it.
> I suggested — we make a separate tool that does (rolling) upgrades.
>
> Regards,
> Rohit Yadav
> Software Architect, ShapeBlue
> M. +41 779015219 | rohit.yadav@shapeblue.com <javascript:;>
> Blog: bhaisaab.org | Twitter: @_bhaisaab
>
>
>
> Find out more about ShapeBlue and our range of CloudStack related services
>
> IaaS Cloud Design & Build<http://shapeblue.com/iaas-cloud-design-and-build//
>>
> CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/>
> CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/>
> CloudStack Infrastructure Support<
> http://shapeblue.com/cloudstack-infrastructure-support/>
> CloudStack Bootcamp Training Courses<
> http://shapeblue.com/cloudstack-training/>
>
> 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 are not the
> intended recipient of this email, you must neither take any action based
> upon its contents, nor copy or show it to anyone. Please contact the sender
> if you believe you have received this email in error. 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.
>
>
>
> --
> ~Rajani
> Sent from Windows Phone
Regards,
Rohit Yadav
Software Architect, ShapeBlue
M. +41 779015219 | rohit.yadav@shapeblue.com
Blog: bhaisaab.org | Twitter: @_bhaisaab
Find out more about ShapeBlue and our range of CloudStack related services
IaaS Cloud Design & Build<http://shapeblue.com/iaas-cloud-design-and-build//>
CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/>
CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/>
CloudStack Infrastructure Support<http://shapeblue.com/cloudstack-infrastructure-support/>
CloudStack Bootcamp Training Courses<http://shapeblue.com/cloudstack-training/>
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 are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. 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.
Re: Cherry-picking fix that may change 4.3.1 schema
Posted by Rajani Karuturi <ra...@apache.org>.
The right way to do this is to do commit to commit migrations and use some
db versioning tools like liquibase or flywaydb which will execute the new
change sets. We discussed this before and IIRC, someone started working on
it.
On Tue, Sep 2, 2014 at 20:58 PM, Rohit Yadav <ro...@shapeblue.com>
wrote:
On 02-Sep-2014, at 5:07 pm, Francois Gaudreault <fgaudreault@cloudops.com
<javascript:;>> wrote:
> I see. Well, I think we were impacted by that too, and we made the
decision to move on 4.4.1-snap (even if it's technically less stable?) and
then upgrade to 4.4.1 GA (next week?)
>
> I personally don't think pulling back DB changes in lower releases is a
good idea :S
>
> But that's only my opinion :)
I raised a concrete issue regarding 4.3.1/4.4.1 release and I would like to
stick to that only. I understand there are too many numbers, versions and
branches to follow, so please if you can try to understand the issue;
This issue — https://issues.apache.org/jira/browse/CLOUDSTACK-6756 requires
that there are some extra columns in the database to do book keeping when
delete ips so you don’t actually delete db/table rows.
The issue above is fixed in an upgrade path from 4.3.0 to 4.4.0:
https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blobdiff;f=setup/db/db/schema-430to440.sql;h=226260804523c79e3ce3cfa3c407b5ac698d749c;hp=3b525c41a1befd94c5ffc324c357b566606a97d0;hb=ce6a53e;hpb=d0f806b3a486c58b033083fc57f39dd686e31750
But, we already have 4.4.0 release and db upgrade paths are always in the
next release versions.
So, there is no upgrade path from 4.3.1 to 4.4.0; as 4.3.1 version does not
care about 4.4.0 schema changes. There is only an upgrade path from 4.3.0
to 4.3.1. So, the limitation is that people won’t be able to upgrade from
4.3.1 to 4.4.0, because 4.4.0 is already released.
If we release 4.4.1 before 4.3.1, we’ll have the same issue. So, we can put
the fix from the JIRA issue on 4.3 branch so the issue is fixed for 4.3.1.
The fix will be in the 4.3.0 to 4.3.1 upgrade path. And, if we release
4.4.1 after 4.3.1, we can fix the upgrade path from 4.3.1 to 4.4.1 on 4.4
branch such that
The abstract issue is — we’ll have such issue in future, how do we fix it.
I suggested — we make a separate tool that does (rolling) upgrades.
Regards,
Rohit Yadav
Software Architect, ShapeBlue
M. +41 779015219 | rohit.yadav@shapeblue.com <javascript:;>
Blog: bhaisaab.org | Twitter: @_bhaisaab
Find out more about ShapeBlue and our range of CloudStack related services
IaaS Cloud Design & Build<http://shapeblue.com/iaas-cloud-design-and-build//
>
CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/>
CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/>
CloudStack Infrastructure Support<
http://shapeblue.com/cloudstack-infrastructure-support/>
CloudStack Bootcamp Training Courses<
http://shapeblue.com/cloudstack-training/>
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 are not the
intended recipient of this email, you must neither take any action based
upon its contents, nor copy or show it to anyone. Please contact the sender
if you believe you have received this email in error. 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.
--
~Rajani
Sent from Windows Phone
Re: Cherry-picking fix that may change 4.3.1 schema
Posted by Sebastien Goasguen <ru...@gmail.com>.
On Sep 3, 2014, at 4:32 AM, Daan Hoogland <da...@gmail.com> wrote:
> 4.3.1 to 4.4.1 then should contain all effort that is also in 4.3.0 to 4.4.0
>
> I don't look forward to the work but it is doable.
>
> What bothers me most is that we are putting so much enegy into 4.3.1 at the
> moment while 4.4.1 is about to be rc'd.
Who is putting energy in 4.3.1 ? me a bit, and Rohit+Ian who helped with Travis (even though it's not 4.3.1 specific).
I am more concerned about the energy spent cleaning up a release branch which never benefits the next release...
-sebastien
>
> --
> an anonymous commit to commit upgrade advocate / release manager
>
>
> On Wed, Sep 3, 2014 at 9:39 AM, Sebastien Goasguen <ru...@gmail.com> wrote:
>
>>
>> On Sep 2, 2014, at 11:28 AM, Rohit Yadav <ro...@shapeblue.com>
>> wrote:
>>
>>>
>>> On 02-Sep-2014, at 5:07 pm, Francois Gaudreault <
>> fgaudreault@cloudops.com> wrote:
>>>> I see. Well, I think we were impacted by that too, and we made the
>> decision to move on 4.4.1-snap (even if it's technically less stable?) and
>> then upgrade to 4.4.1 GA (next week?)
>>>>
>>>> I personally don't think pulling back DB changes in lower releases is a
>> good idea :S
>>>>
>>>> But that's only my opinion :)
>>>
>>> I raised a concrete issue regarding 4.3.1/4.4.1 release and I would like
>> to stick to that only. I understand there are too many numbers, versions
>> and branches to follow, so please if you can try to understand the issue;
>>
>> I think Francois understands the issue (in terms of the bug been talked
>> about), and his solution has been to move to 4.4.1-snap. It is a different
>> type of solution than a solution at the code/release level but if it works
>> for him..fine :)
>>
>>>
>>> This issue — https://issues.apache.org/jira/browse/CLOUDSTACK-6756
>> requires that there are some extra columns in the database to do book
>> keeping when delete ips so you don’t actually delete db/table rows.
>>>
>>> The issue above is fixed in an upgrade path from 4.3.0 to 4.4.0:
>>>
>> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blobdiff;f=setup/db/db/schema-430to440.sql;h=226260804523c79e3ce3cfa3c407b5ac698d749c;hp=3b525c41a1befd94c5ffc324c357b566606a97d0;hb=ce6a53e;hpb=d0f806b3a486c58b033083fc57f39dd686e31750
>>>
>>> But, we already have 4.4.0 release and db upgrade paths are always in
>> the next release versions.
>>>
>>> So, there is no upgrade path from 4.3.1 to 4.4.0; as 4.3.1 version does
>> not care about 4.4.0 schema changes. There is only an upgrade path from
>> 4.3.0 to 4.3.1. So, the limitation is that people won’t be able to upgrade
>> from 4.3.1 to 4.4.0, because 4.4.0 is already released.
>>>
>>> If we release 4.4.1 before 4.3.1, we’ll have the same issue. So, we can
>> put the fix from the JIRA issue on 4.3 branch so the issue is fixed for
>> 4.3.1. The fix will be in the 4.3.0 to 4.3.1 upgrade path. And, if we
>> release 4.4.1 after 4.3.1, we can fix the upgrade path from 4.3.1 to 4.4.1
>> on 4.4 branch such that
>>>
>>> The abstract issue is — we’ll have such issue in future, how do we fix
>> it. I suggested — we make a separate tool that does (rolling) upgrades.
>>>
>>
>> So two things:
>>
>> -How to fix now
>> -How to fix later (if we want to keep some type of long term release
>> branches)
>>
>> I am ready to release 4.3.1 so if we put an upgrade path from 4.3.1 to
>> 4.4.1 , that's fine with me, especially if there is precedent of database
>> changes in the 4.2.x series.
>>
>>> Regards,
>>> Rohit Yadav
>>> Software Architect, ShapeBlue
>>> M. +41 779015219 | rohit.yadav@shapeblue.com
>>> Blog: bhaisaab.org | Twitter: @_bhaisaab
>>>
>>>
>>>
>>> Find out more about ShapeBlue and our range of CloudStack related
>> services
>>>
>>> IaaS Cloud Design & Build<
>> http://shapeblue.com/iaas-cloud-design-and-build//>
>>> CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/>
>>> CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/>
>>> CloudStack Infrastructure Support<
>> http://shapeblue.com/cloudstack-infrastructure-support/>
>>> CloudStack Bootcamp Training Courses<
>> http://shapeblue.com/cloudstack-training/>
>>>
>>> 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
>> are not the intended recipient of this email, you must neither take any
>> action based upon its contents, nor copy or show it to anyone. Please
>> contact the sender if you believe you have received this email in error.
>> 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.
>>
>>
>
>
> --
> Daan
Re: Cherry-picking fix that may change 4.3.1 schema
Posted by Daan Hoogland <da...@gmail.com>.
4.3.1 to 4.4.1 then should contain all effort that is also in 4.3.0 to 4.4.0
I don't look forward to the work but it is doable.
What bothers me most is that we are putting so much enegy into 4.3.1 at the
moment while 4.4.1 is about to be rc'd.
--
an anonymous commit to commit upgrade advocate / release manager
On Wed, Sep 3, 2014 at 9:39 AM, Sebastien Goasguen <ru...@gmail.com> wrote:
>
> On Sep 2, 2014, at 11:28 AM, Rohit Yadav <ro...@shapeblue.com>
> wrote:
>
> >
> > On 02-Sep-2014, at 5:07 pm, Francois Gaudreault <
> fgaudreault@cloudops.com> wrote:
> >> I see. Well, I think we were impacted by that too, and we made the
> decision to move on 4.4.1-snap (even if it's technically less stable?) and
> then upgrade to 4.4.1 GA (next week?)
> >>
> >> I personally don't think pulling back DB changes in lower releases is a
> good idea :S
> >>
> >> But that's only my opinion :)
> >
> > I raised a concrete issue regarding 4.3.1/4.4.1 release and I would like
> to stick to that only. I understand there are too many numbers, versions
> and branches to follow, so please if you can try to understand the issue;
>
> I think Francois understands the issue (in terms of the bug been talked
> about), and his solution has been to move to 4.4.1-snap. It is a different
> type of solution than a solution at the code/release level but if it works
> for him..fine :)
>
> >
> > This issue — https://issues.apache.org/jira/browse/CLOUDSTACK-6756
> requires that there are some extra columns in the database to do book
> keeping when delete ips so you don’t actually delete db/table rows.
> >
> > The issue above is fixed in an upgrade path from 4.3.0 to 4.4.0:
> >
> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blobdiff;f=setup/db/db/schema-430to440.sql;h=226260804523c79e3ce3cfa3c407b5ac698d749c;hp=3b525c41a1befd94c5ffc324c357b566606a97d0;hb=ce6a53e;hpb=d0f806b3a486c58b033083fc57f39dd686e31750
> >
> > But, we already have 4.4.0 release and db upgrade paths are always in
> the next release versions.
> >
> > So, there is no upgrade path from 4.3.1 to 4.4.0; as 4.3.1 version does
> not care about 4.4.0 schema changes. There is only an upgrade path from
> 4.3.0 to 4.3.1. So, the limitation is that people won’t be able to upgrade
> from 4.3.1 to 4.4.0, because 4.4.0 is already released.
> >
> > If we release 4.4.1 before 4.3.1, we’ll have the same issue. So, we can
> put the fix from the JIRA issue on 4.3 branch so the issue is fixed for
> 4.3.1. The fix will be in the 4.3.0 to 4.3.1 upgrade path. And, if we
> release 4.4.1 after 4.3.1, we can fix the upgrade path from 4.3.1 to 4.4.1
> on 4.4 branch such that
> >
> > The abstract issue is — we’ll have such issue in future, how do we fix
> it. I suggested — we make a separate tool that does (rolling) upgrades.
> >
>
> So two things:
>
> -How to fix now
> -How to fix later (if we want to keep some type of long term release
> branches)
>
> I am ready to release 4.3.1 so if we put an upgrade path from 4.3.1 to
> 4.4.1 , that's fine with me, especially if there is precedent of database
> changes in the 4.2.x series.
>
> > Regards,
> > Rohit Yadav
> > Software Architect, ShapeBlue
> > M. +41 779015219 | rohit.yadav@shapeblue.com
> > Blog: bhaisaab.org | Twitter: @_bhaisaab
> >
> >
> >
> > Find out more about ShapeBlue and our range of CloudStack related
> services
> >
> > IaaS Cloud Design & Build<
> http://shapeblue.com/iaas-cloud-design-and-build//>
> > CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/>
> > CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/>
> > CloudStack Infrastructure Support<
> http://shapeblue.com/cloudstack-infrastructure-support/>
> > CloudStack Bootcamp Training Courses<
> http://shapeblue.com/cloudstack-training/>
> >
> > 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
> are not the intended recipient of this email, you must neither take any
> action based upon its contents, nor copy or show it to anyone. Please
> contact the sender if you believe you have received this email in error.
> 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.
>
>
--
Daan
Re: Cherry-picking fix that may change 4.3.1 schema
Posted by Sebastien Goasguen <ru...@gmail.com>.
On Sep 2, 2014, at 11:28 AM, Rohit Yadav <ro...@shapeblue.com> wrote:
>
> On 02-Sep-2014, at 5:07 pm, Francois Gaudreault <fg...@cloudops.com> wrote:
>> I see. Well, I think we were impacted by that too, and we made the decision to move on 4.4.1-snap (even if it's technically less stable?) and then upgrade to 4.4.1 GA (next week?)
>>
>> I personally don't think pulling back DB changes in lower releases is a good idea :S
>>
>> But that's only my opinion :)
>
> I raised a concrete issue regarding 4.3.1/4.4.1 release and I would like to stick to that only. I understand there are too many numbers, versions and branches to follow, so please if you can try to understand the issue;
I think Francois understands the issue (in terms of the bug been talked about), and his solution has been to move to 4.4.1-snap. It is a different type of solution than a solution at the code/release level but if it works for him..fine :)
>
> This issue — https://issues.apache.org/jira/browse/CLOUDSTACK-6756 requires that there are some extra columns in the database to do book keeping when delete ips so you don’t actually delete db/table rows.
>
> The issue above is fixed in an upgrade path from 4.3.0 to 4.4.0:
> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blobdiff;f=setup/db/db/schema-430to440.sql;h=226260804523c79e3ce3cfa3c407b5ac698d749c;hp=3b525c41a1befd94c5ffc324c357b566606a97d0;hb=ce6a53e;hpb=d0f806b3a486c58b033083fc57f39dd686e31750
>
> But, we already have 4.4.0 release and db upgrade paths are always in the next release versions.
>
> So, there is no upgrade path from 4.3.1 to 4.4.0; as 4.3.1 version does not care about 4.4.0 schema changes. There is only an upgrade path from 4.3.0 to 4.3.1. So, the limitation is that people won’t be able to upgrade from 4.3.1 to 4.4.0, because 4.4.0 is already released.
>
> If we release 4.4.1 before 4.3.1, we’ll have the same issue. So, we can put the fix from the JIRA issue on 4.3 branch so the issue is fixed for 4.3.1. The fix will be in the 4.3.0 to 4.3.1 upgrade path. And, if we release 4.4.1 after 4.3.1, we can fix the upgrade path from 4.3.1 to 4.4.1 on 4.4 branch such that
>
> The abstract issue is — we’ll have such issue in future, how do we fix it. I suggested — we make a separate tool that does (rolling) upgrades.
>
So two things:
-How to fix now
-How to fix later (if we want to keep some type of long term release branches)
I am ready to release 4.3.1 so if we put an upgrade path from 4.3.1 to 4.4.1 , that's fine with me, especially if there is precedent of database changes in the 4.2.x series.
> Regards,
> Rohit Yadav
> Software Architect, ShapeBlue
> M. +41 779015219 | rohit.yadav@shapeblue.com
> Blog: bhaisaab.org | Twitter: @_bhaisaab
>
>
>
> Find out more about ShapeBlue and our range of CloudStack related services
>
> IaaS Cloud Design & Build<http://shapeblue.com/iaas-cloud-design-and-build//>
> CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/>
> CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/>
> CloudStack Infrastructure Support<http://shapeblue.com/cloudstack-infrastructure-support/>
> CloudStack Bootcamp Training Courses<http://shapeblue.com/cloudstack-training/>
>
> 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 are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. 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.
Re: Cherry-picking fix that may change 4.3.1 schema
Posted by Rohit Yadav <ro...@shapeblue.com>.
If you’re not going to read anything because the thread has gone too long already, read this:
4.4.0 is already out there, if we release 4.3.1 there is no way people can upgrade to 4.4.0 as the upgrade paths exist in the 4.4.0 release itself which does not know about 4.3.1
On 02-Sep-2014, at 5:48 pm, Will Stevens <ws...@cloudops.com> wrote:
> @Rohit
> I think we are playing with fire here a bit. DB changes should be made on
> major releases and we should try to avoid DB changes on minor releases
> because of this type of problem. We have to keep the upgrade paths as
> clean as possible because we don't want people running into issues when
> they upgrade their prod boxes.
>
> I think we are going to have a problem with this one because I think the
> 4.4.1 branch is going to be released before the 4.3.1 branch, so the
> upgrade path will be broken. My understanding is that the 4.4.1 branch is
> planned to be launched on Monday (Sept 8th), so I expect there will be a
> problem with the upgrade path if we implement this change in 4.3.1. Thats
> my two cents anyway…
Sorry to break you this, the issue I’m raising here has always existed before. Just that it was not widely shared and was silently fixed by developers.
This is also the first time that we’re planning to release a minor version from previous major release. That is we already released 4.4.0 and now we’re going to release 4.3.1.
Database upgrade paths from previous releases are only added in next releases. And, you may go look at the code to see that all minor upgrades do introduce some db changes and not just read emails. Sometime they don’t have to put an explicit schema-AtoB.sql and their cleanup files.
In any case, due to the way we release ACS. People won’t be able to upgrade from 4.3.1 to 4.4.0 anyway.
Regards,
Rohit Yadav
Software Architect, ShapeBlue
M. +41 779015219 | rohit.yadav@shapeblue.com
Blog: bhaisaab.org | Twitter: @_bhaisaab
Find out more about ShapeBlue and our range of CloudStack related services
IaaS Cloud Design & Build<http://shapeblue.com/iaas-cloud-design-and-build//>
CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/>
CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/>
CloudStack Infrastructure Support<http://shapeblue.com/cloudstack-infrastructure-support/>
CloudStack Bootcamp Training Courses<http://shapeblue.com/cloudstack-training/>
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 are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. 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.
Re: Cherry-picking fix that may change 4.3.1 schema
Posted by Rajani Karuturi <ra...@apache.org>.
On Tue, Sep 2, 2014 at 9:18 PM, Will Stevens <ws...@cloudops.com> wrote:
>
> @Rajani
> I am not entirely sure which technology is being used for the db upgrade
> paths, but I think it is probably something like liquibase already. I
> would have to check on the technology, but this is already in place. The
> issue is more about maintaining an upgradeable path for each version that
> is released. This is a bit complicated by the fact that we currently have
> 4.3, 4.4 and 4.5 version all having changes made to them at the same
> time...
>
>
we do not use any external library. It is home grown and has the
limitations like not handling commit to commit migration. it only does
version to version which is why we see lot of db issues on master as
well(current development branch)
~Rajani
>
> *Will STEVENS*
> Lead Developer
>
> *CloudOps* *| *Cloud Solutions Experts
> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
> w cloudops.com *|* tw @CloudOps_
>
>
> On Tue, Sep 2, 2014 at 11:28 AM, Rohit Yadav <ro...@shapeblue.com>
> wrote:
>
> >
> > On 02-Sep-2014, at 5:07 pm, Francois Gaudreault <
> fgaudreault@cloudops.com>
> > wrote:
> > > I see. Well, I think we were impacted by that too, and we made the
> > decision to move on 4.4.1-snap (even if it's technically less stable?)
> and
> > then upgrade to 4.4.1 GA (next week?)
> > >
> > > I personally don't think pulling back DB changes in lower releases is a
> > good idea :S
> > >
> > > But that's only my opinion :)
> >
> > I raised a concrete issue regarding 4.3.1/4.4.1 release and I would like
> > to stick to that only. I understand there are too many numbers, versions
> > and branches to follow, so please if you can try to understand the issue;
> >
> > This issue — https://issues.apache.org/jira/browse/CLOUDSTACK-6756
> > requires that there are some extra columns in the database to do book
> > keeping when delete ips so you don’t actually delete db/table rows.
> >
> > The issue above is fixed in an upgrade path from 4.3.0 to 4.4.0:
> >
> >
> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blobdiff;f=setup/db/db/schema-430to440.sql;h=226260804523c79e3ce3cfa3c407b5ac698d749c;hp=3b525c41a1befd94c5ffc324c357b566606a97d0;hb=ce6a53e;hpb=d0f806b3a486c58b033083fc57f39dd686e31750
> >
> > But, we already have 4.4.0 release and db upgrade paths are always in the
> > next release versions.
> >
> > So, there is no upgrade path from 4.3.1 to 4.4.0; as 4.3.1 version does
> > not care about 4.4.0 schema changes. There is only an upgrade path from
> > 4.3.0 to 4.3.1. So, the limitation is that people won’t be able to
> upgrade
> > from 4.3.1 to 4.4.0, because 4.4.0 is already released.
> >
> > If we release 4.4.1 before 4.3.1, we’ll have the same issue. So, we can
> > put the fix from the JIRA issue on 4.3 branch so the issue is fixed for
> > 4.3.1. The fix will be in the 4.3.0 to 4.3.1 upgrade path. And, if we
> > release 4.4.1 after 4.3.1, we can fix the upgrade path from 4.3.1 to
> 4.4.1
> > on 4.4 branch such that
> >
> > The abstract issue is — we’ll have such issue in future, how do we fix
> it.
> > I suggested — we make a separate tool that does (rolling) upgrades.
> >
> > Regards,
> > Rohit Yadav
> > Software Architect, ShapeBlue
> > M. +41 779015219 | rohit.yadav@shapeblue.com
> > Blog: bhaisaab.org | Twitter: @_bhaisaab
> >
> >
> >
> > Find out more about ShapeBlue and our range of CloudStack related
> services
> >
> > IaaS Cloud Design & Build<
> > http://shapeblue.com/iaas-cloud-design-and-build//>
> > CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/>
> > CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/>
> > CloudStack Infrastructure Support<
> > http://shapeblue.com/cloudstack-infrastructure-support/>
> > CloudStack Bootcamp Training Courses<
> > http://shapeblue.com/cloudstack-training/>
> >
> > 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 are not
> the
> > intended recipient of this email, you must neither take any action based
> > upon its contents, nor copy or show it to anyone. Please contact the
> sender
> > if you believe you have received this email in error. 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.
> >
>
Re: Cherry-picking fix that may change 4.3.1 schema
Posted by Will Stevens <ws...@cloudops.com>.
@Rohit
I think we are playing with fire here a bit. DB changes should be made on
major releases and we should try to avoid DB changes on minor releases
because of this type of problem. We have to keep the upgrade paths as
clean as possible because we don't want people running into issues when
they upgrade their prod boxes.
I think we are going to have a problem with this one because I think the
4.4.1 branch is going to be released before the 4.3.1 branch, so the
upgrade path will be broken. My understanding is that the 4.4.1 branch is
planned to be launched on Monday (Sept 8th), so I expect there will be a
problem with the upgrade path if we implement this change in 4.3.1. Thats
my two cents anyway...
@Rajani
I am not entirely sure which technology is being used for the db upgrade
paths, but I think it is probably something like liquibase already. I
would have to check on the technology, but this is already in place. The
issue is more about maintaining an upgradeable path for each version that
is released. This is a bit complicated by the fact that we currently have
4.3, 4.4 and 4.5 version all having changes made to them at the same time...
*Will STEVENS*
Lead Developer
*CloudOps* *| *Cloud Solutions Experts
420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
w cloudops.com *|* tw @CloudOps_
On Tue, Sep 2, 2014 at 11:28 AM, Rohit Yadav <ro...@shapeblue.com>
wrote:
>
> On 02-Sep-2014, at 5:07 pm, Francois Gaudreault <fg...@cloudops.com>
> wrote:
> > I see. Well, I think we were impacted by that too, and we made the
> decision to move on 4.4.1-snap (even if it's technically less stable?) and
> then upgrade to 4.4.1 GA (next week?)
> >
> > I personally don't think pulling back DB changes in lower releases is a
> good idea :S
> >
> > But that's only my opinion :)
>
> I raised a concrete issue regarding 4.3.1/4.4.1 release and I would like
> to stick to that only. I understand there are too many numbers, versions
> and branches to follow, so please if you can try to understand the issue;
>
> This issue — https://issues.apache.org/jira/browse/CLOUDSTACK-6756
> requires that there are some extra columns in the database to do book
> keeping when delete ips so you don’t actually delete db/table rows.
>
> The issue above is fixed in an upgrade path from 4.3.0 to 4.4.0:
>
> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blobdiff;f=setup/db/db/schema-430to440.sql;h=226260804523c79e3ce3cfa3c407b5ac698d749c;hp=3b525c41a1befd94c5ffc324c357b566606a97d0;hb=ce6a53e;hpb=d0f806b3a486c58b033083fc57f39dd686e31750
>
> But, we already have 4.4.0 release and db upgrade paths are always in the
> next release versions.
>
> So, there is no upgrade path from 4.3.1 to 4.4.0; as 4.3.1 version does
> not care about 4.4.0 schema changes. There is only an upgrade path from
> 4.3.0 to 4.3.1. So, the limitation is that people won’t be able to upgrade
> from 4.3.1 to 4.4.0, because 4.4.0 is already released.
>
> If we release 4.4.1 before 4.3.1, we’ll have the same issue. So, we can
> put the fix from the JIRA issue on 4.3 branch so the issue is fixed for
> 4.3.1. The fix will be in the 4.3.0 to 4.3.1 upgrade path. And, if we
> release 4.4.1 after 4.3.1, we can fix the upgrade path from 4.3.1 to 4.4.1
> on 4.4 branch such that
>
> The abstract issue is — we’ll have such issue in future, how do we fix it.
> I suggested — we make a separate tool that does (rolling) upgrades.
>
> Regards,
> Rohit Yadav
> Software Architect, ShapeBlue
> M. +41 779015219 | rohit.yadav@shapeblue.com
> Blog: bhaisaab.org | Twitter: @_bhaisaab
>
>
>
> Find out more about ShapeBlue and our range of CloudStack related services
>
> IaaS Cloud Design & Build<
> http://shapeblue.com/iaas-cloud-design-and-build//>
> CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/>
> CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/>
> CloudStack Infrastructure Support<
> http://shapeblue.com/cloudstack-infrastructure-support/>
> CloudStack Bootcamp Training Courses<
> http://shapeblue.com/cloudstack-training/>
>
> 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 are not the
> intended recipient of this email, you must neither take any action based
> upon its contents, nor copy or show it to anyone. Please contact the sender
> if you believe you have received this email in error. 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.
>
Re: Cherry-picking fix that may change 4.3.1 schema
Posted by Rohit Yadav <ro...@shapeblue.com>.
On 02-Sep-2014, at 5:07 pm, Francois Gaudreault <fg...@cloudops.com> wrote:
> I see. Well, I think we were impacted by that too, and we made the decision to move on 4.4.1-snap (even if it's technically less stable?) and then upgrade to 4.4.1 GA (next week?)
>
> I personally don't think pulling back DB changes in lower releases is a good idea :S
>
> But that's only my opinion :)
I raised a concrete issue regarding 4.3.1/4.4.1 release and I would like to stick to that only. I understand there are too many numbers, versions and branches to follow, so please if you can try to understand the issue;
This issue — https://issues.apache.org/jira/browse/CLOUDSTACK-6756 requires that there are some extra columns in the database to do book keeping when delete ips so you don’t actually delete db/table rows.
The issue above is fixed in an upgrade path from 4.3.0 to 4.4.0:
https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blobdiff;f=setup/db/db/schema-430to440.sql;h=226260804523c79e3ce3cfa3c407b5ac698d749c;hp=3b525c41a1befd94c5ffc324c357b566606a97d0;hb=ce6a53e;hpb=d0f806b3a486c58b033083fc57f39dd686e31750
But, we already have 4.4.0 release and db upgrade paths are always in the next release versions.
So, there is no upgrade path from 4.3.1 to 4.4.0; as 4.3.1 version does not care about 4.4.0 schema changes. There is only an upgrade path from 4.3.0 to 4.3.1. So, the limitation is that people won’t be able to upgrade from 4.3.1 to 4.4.0, because 4.4.0 is already released.
If we release 4.4.1 before 4.3.1, we’ll have the same issue. So, we can put the fix from the JIRA issue on 4.3 branch so the issue is fixed for 4.3.1. The fix will be in the 4.3.0 to 4.3.1 upgrade path. And, if we release 4.4.1 after 4.3.1, we can fix the upgrade path from 4.3.1 to 4.4.1 on 4.4 branch such that
The abstract issue is — we’ll have such issue in future, how do we fix it. I suggested — we make a separate tool that does (rolling) upgrades.
Regards,
Rohit Yadav
Software Architect, ShapeBlue
M. +41 779015219 | rohit.yadav@shapeblue.com
Blog: bhaisaab.org | Twitter: @_bhaisaab
Find out more about ShapeBlue and our range of CloudStack related services
IaaS Cloud Design & Build<http://shapeblue.com/iaas-cloud-design-and-build//>
CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/>
CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/>
CloudStack Infrastructure Support<http://shapeblue.com/cloudstack-infrastructure-support/>
CloudStack Bootcamp Training Courses<http://shapeblue.com/cloudstack-training/>
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 are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. 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.
Re: Cherry-picking fix that may change 4.3.1 schema
Posted by Francois Gaudreault <fg...@cloudops.com>.
On 2014-09-02, 11:00 AM, Rohit Yadav wrote:
> On 02-Sep-2014, at 4:54 pm, Francois Gaudreault <fg...@cloudops.com> wrote:
>> Do I read the ticket wrong or that fix is already in 4.4?
>>
>> FG
> Yes, this already is in 4.4 but the issue is — do we want it for 4.3 branch as it affects 4.3.0 release as well and it’s a major issue for people using ACS "usage".
I see. Well, I think we were impacted by that too, and we made the decision to move on 4.4.1-snap (even if it's technically less stable?) and then upgrade to 4.4.1 GA (next week?)
I personally don't think pulling back DB changes in lower releases is a good idea :S
But that's only my opinion :)
FG
>
> Regards,
> Rohit Yadav
> Software Architect, ShapeBlue
> M. +41 779015219 | rohit.yadav@shapeblue.com
> Blog: bhaisaab.org | Twitter: @_bhaisaab
>
>
>
> Find out more about ShapeBlue and our range of CloudStack related services
>
> IaaS Cloud Design & Build<http://shapeblue.com/iaas-cloud-design-and-build//>
> CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/>
> CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/>
> CloudStack Infrastructure Support<http://shapeblue.com/cloudstack-infrastructure-support/>
> CloudStack Bootcamp Training Courses<http://shapeblue.com/cloudstack-training/>
>
> 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 are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. 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.
>
>
--
Francois Gaudreault
Gestionnaire de Produit | Product Manager - Cloud Platform & Services
t:514-629-6775
CloudOps Votre partenaire infonuagique | Cloud Solutions Experts
420 rue Guy | Montreal | Quebec | H3J 1S6
w: cloudops.com | tw: @CloudOps_
Re: Cherry-picking fix that may change 4.3.1 schema
Posted by Rohit Yadav <ro...@shapeblue.com>.
On 02-Sep-2014, at 4:54 pm, Francois Gaudreault <fg...@cloudops.com> wrote:
> Do I read the ticket wrong or that fix is already in 4.4?
>
> FG
Yes, this already is in 4.4 but the issue is — do we want it for 4.3 branch as it affects 4.3.0 release as well and it’s a major issue for people using ACS "usage".
Regards,
Rohit Yadav
Software Architect, ShapeBlue
M. +41 779015219 | rohit.yadav@shapeblue.com
Blog: bhaisaab.org | Twitter: @_bhaisaab
Find out more about ShapeBlue and our range of CloudStack related services
IaaS Cloud Design & Build<http://shapeblue.com/iaas-cloud-design-and-build//>
CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/>
CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/>
CloudStack Infrastructure Support<http://shapeblue.com/cloudstack-infrastructure-support/>
CloudStack Bootcamp Training Courses<http://shapeblue.com/cloudstack-training/>
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 are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. 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.
Re: Cherry-picking fix that may change 4.3.1 schema
Posted by Francois Gaudreault <fg...@cloudops.com>.
Do I read the ticket wrong or that fix is already in 4.4?
FG
On 2014-09-02, 10:48 AM, Rohit Yadav wrote:
> On 02-Sep-2014, at 4:38 pm, David Nalley <da...@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.
>
> 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.
>
> 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.
>
> Regards,
> Rohit Yadav
> Software Architect, ShapeBlue
> M. +41 779015219 | rohit.yadav@shapeblue.com
> Blog: bhaisaab.org | Twitter: @_bhaisaab
>
>
>
> Find out more about ShapeBlue and our range of CloudStack related services
>
> IaaS Cloud Design & Build<http://shapeblue.com/iaas-cloud-design-and-build//>
> CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/>
> CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/>
> CloudStack Infrastructure Support<http://shapeblue.com/cloudstack-infrastructure-support/>
> CloudStack Bootcamp Training Courses<http://shapeblue.com/cloudstack-training/>
>
> 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 are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. 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.
>
>
--
Francois Gaudreault
Gestionnaire de Produit | Product Manager - Cloud Platform & Services
t:514-629-6775
CloudOps Votre partenaire infonuagique | Cloud Solutions Experts
420 rue Guy | Montreal | Quebec | H3J 1S6
w: cloudops.com | tw: @CloudOps_
Re: Cherry-picking fix that may change 4.3.1 schema
Posted by David Nalley <da...@gnsa.us>.
On Tue, Sep 2, 2014 at 10:48 AM, Rohit Yadav <ro...@shapeblue.com> wrote:
>
> On 02-Sep-2014, at 4:38 pm, David Nalley <da...@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.
Re: Cherry-picking fix that may change 4.3.1 schema
Posted by Rohit Yadav <ro...@shapeblue.com>.
On 02-Sep-2014, at 4:38 pm, David Nalley <da...@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.
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.
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.
Regards,
Rohit Yadav
Software Architect, ShapeBlue
M. +41 779015219 | rohit.yadav@shapeblue.com
Blog: bhaisaab.org | Twitter: @_bhaisaab
Find out more about ShapeBlue and our range of CloudStack related services
IaaS Cloud Design & Build<http://shapeblue.com/iaas-cloud-design-and-build//>
CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/>
CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/>
CloudStack Infrastructure Support<http://shapeblue.com/cloudstack-infrastructure-support/>
CloudStack Bootcamp Training Courses<http://shapeblue.com/cloudstack-training/>
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 are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. 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.
Re: Cherry-picking fix that may change 4.3.1 schema
Posted by David Nalley <da...@gnsa.us>.
On Tue, Sep 2, 2014 at 9:34 AM, Wido den Hollander <wi...@widodh.nl> wrote:
>
>
> On 09/02/2014 03:30 PM, sebgoa wrote:
>>
>>
>> On Sep 2, 2014, at 3:20 PM, Rohit Yadav <ro...@shapeblue.com> wrote:
>>
>>> Hi,
>>>
>>> I’m going through list of issues that affect 4.3.0 and 4.3.1 and
>>> cherry-picking those which are already fixed elsewhere. This is the issue
>>> which would involve some modifications to the schema:
>>> https://issues.apache.org/jira/browse/CLOUDSTACK-6756
>>>
>>> @Sebatien: can you please take a look at this bug and cherry-pick if we
>>> want it in 4.3.1?
>>>
>>
>> I have always been of the impression that we should not have any schema
>> changes in minor releases even if it fixes bugs ?
>>
>
> I thought so as well. Since how are people going to upgrade to 4.4.1 from
> 4.3.1?
>
> Wido
>
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.
--David
Re: Cherry-picking fix that may change 4.3.1 schema
Posted by Wido den Hollander <wi...@widodh.nl>.
On 09/02/2014 03:30 PM, sebgoa wrote:
>
> On Sep 2, 2014, at 3:20 PM, Rohit Yadav <ro...@shapeblue.com> wrote:
>
>> Hi,
>>
>> I’m going through list of issues that affect 4.3.0 and 4.3.1 and cherry-picking those which are already fixed elsewhere. This is the issue which would involve some modifications to the schema: https://issues.apache.org/jira/browse/CLOUDSTACK-6756
>>
>> @Sebatien: can you please take a look at this bug and cherry-pick if we want it in 4.3.1?
>>
>
> I have always been of the impression that we should not have any schema changes in minor releases even if it fixes bugs ?
>
I thought so as well. Since how are people going to upgrade to 4.4.1
from 4.3.1?
Wido
> But I am happy to commit this, if folks agree that we should do it.
>
>> It is doable either in the schema upgrade path 4.3.0 to 4.3.1 (sql file) or in the upgrade class.
>>
>> Since, we’re going to have 4.4.1 soon as well, it makes it tricky how to to deal with upgrade paths. So, at present if 4.4.1 is out already, people on 4.3.1 (in near future) won’t be able to upgrade to 4.4.1 etc. Should in such a case try to release 4.3.1 out first and then 4.4.1?
>>
>
> I soon as I see the smoke tests green on Travis , I will launch a vote for 4.3.1
>
>> What about if in future we have more such situations, we perhaps need to fix release management process and policies, one way is to refactor out the db upgrade logic as a separate tool that has a more quick release cycle like cloudmonkey?
>>
>> Regards,
>> Rohit Yadav
>> Software Architect, ShapeBlue
>> M. +41 779015219 | rohit.yadav@shapeblue.com
>> Blog: bhaisaab.org | Twitter: @_bhaisaab
>>
>>
>>
>> Find out more about ShapeBlue and our range of CloudStack related services
>>
>> IaaS Cloud Design & Build<http://shapeblue.com/iaas-cloud-design-and-build//>
>> CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/>
>> CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/>
>> CloudStack Infrastructure Support<http://shapeblue.com/cloudstack-infrastructure-support/>
>> CloudStack Bootcamp Training Courses<http://shapeblue.com/cloudstack-training/>
>>
>> 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 are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. 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.
>
Re: Cherry-picking fix that may change 4.3.1 schema
Posted by sebgoa <ru...@gmail.com>.
On Sep 2, 2014, at 3:20 PM, Rohit Yadav <ro...@shapeblue.com> wrote:
> Hi,
>
> I’m going through list of issues that affect 4.3.0 and 4.3.1 and cherry-picking those which are already fixed elsewhere. This is the issue which would involve some modifications to the schema: https://issues.apache.org/jira/browse/CLOUDSTACK-6756
>
> @Sebatien: can you please take a look at this bug and cherry-pick if we want it in 4.3.1?
>
I have always been of the impression that we should not have any schema changes in minor releases even if it fixes bugs ?
But I am happy to commit this, if folks agree that we should do it.
> It is doable either in the schema upgrade path 4.3.0 to 4.3.1 (sql file) or in the upgrade class.
>
> Since, we’re going to have 4.4.1 soon as well, it makes it tricky how to to deal with upgrade paths. So, at present if 4.4.1 is out already, people on 4.3.1 (in near future) won’t be able to upgrade to 4.4.1 etc. Should in such a case try to release 4.3.1 out first and then 4.4.1?
>
I soon as I see the smoke tests green on Travis , I will launch a vote for 4.3.1
> What about if in future we have more such situations, we perhaps need to fix release management process and policies, one way is to refactor out the db upgrade logic as a separate tool that has a more quick release cycle like cloudmonkey?
>
> Regards,
> Rohit Yadav
> Software Architect, ShapeBlue
> M. +41 779015219 | rohit.yadav@shapeblue.com
> Blog: bhaisaab.org | Twitter: @_bhaisaab
>
>
>
> Find out more about ShapeBlue and our range of CloudStack related services
>
> IaaS Cloud Design & Build<http://shapeblue.com/iaas-cloud-design-and-build//>
> CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/>
> CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/>
> CloudStack Infrastructure Support<http://shapeblue.com/cloudstack-infrastructure-support/>
> CloudStack Bootcamp Training Courses<http://shapeblue.com/cloudstack-training/>
>
> 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 are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. 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.