Updating pom.xml version numbers for release 4.8.2.0-SNAPSHOT #1654

jburwell · 2016-08-23T05:04:54Z

Often, patch and security releases do not require schema migrations or
data migrations. However, if an empty upgrade class and associated
scripts are not defined, the upgrade process will break. With this
change, if a release does not have an upgrade, a noop DbUpgrade is added
to the upgrade path. This approach allows the upgrade to proceed and
for the database to properly reflect the installed version. This change
should make the release process simpler as RMs no longer need to
rememeber to create this boilerplate code when starting a new release.

Beginning with the 4.8.2.0 and 4.9.1.0 releases, the project will
formally adopt a four (4) position release number to properly accomodate
rekeases that contain only CVE fixes. The DatabaseUpgradeChecker and
Version classes made assumptions that they would always parse and
compare three (3) position version numbers. This change adds the
CloudStackVersion value object that supports both three (3) and four (4)
version numbers. It encapsulates version comparsion logic, as well as,
the rules to allow three (3) and four (4) to interoperate.

Modifies DatabaseUpgradeChecker to handle derive an upgrade path for
a version that was not explicitly specified. It determines the
releases the first release before it with database migrations and uses
that list as the basis for the list for version being calculated. A
noop upgrade is then added to the list which causes no schema changes
or data migrations, but will update the database to the version.
Adds unit tests for the upgrade path calculation logic in
DatabaseUpgradeChecker
Removes dummy upgrade logic for the 4.8.2.0 introduced in previous
versions of this patch
Introduces the CloudStackVersion value object which parses and
compares three (3) and four (4) position version numbers. This class
is intended to replace com.cloud.maint.Version.
Adds the junit-dataprovider dependency -- allowing test data to be
concisely generated separately from the execution of a test case.
Used extensively in the CloudStackVersionTest.

Signed-off-by: John Burwell [email protected]

/cc @rhtyd @karuturi

yadvr · 2016-08-23T06:42:32Z

LGTM
@blueorangutan package

blueorangutan · 2016-08-23T06:43:03Z

@rhtyd a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress.

yadvr · 2016-08-23T06:46:17Z

There seems to be build failure around db path or marvin, I can check this

blueorangutan · 2016-08-23T07:03:40Z

Packaging result: ✔centos6 ✔centos7 ✔debian repo: http://packages.shapeblue.com/cloudstack/pr/1654
Job ID-98

yadvr · 2016-08-23T17:40:41Z

I think a db upgrade path is missing causing Travis failures.

yadvr · 2016-08-25T08:48:12Z

@jburwell I've added an empty upgrade path. Tested the db upgrade locally. LGTM.
When you fwd-merge on 4.9 use: git merge -X ours 4.8 to avoid fixing merge conflicts in pom.xm files by hand. Merging 4.9 on master should not then cause any conflicts. We'll then also need to add/update db upgrade paths from 4.8.2 to 4.9.1/4.10.0 db versions (separately)?

jburwell · 2016-08-28T20:58:39Z

@rhtyd I have updated this PR to reflect version being 4.8.2**.0** rather than 4.8.2. I also added empty migration scripts to maintain consistency with previous releases (e.g. 4.8.1). Could you please test and verify?

@karuturi @abhinandanprateek @murali-reddy could you please provide a code review?

jburwell · 2016-08-29T01:53:30Z

@rhtyd The Travis build for this PR is failing with the following error:

========> Processing SQL file at /home/travis/build/apache/cloudstack/developer/target/db/templates.simulator.sql
Unable to execute /home/travis/build/apache/cloudstack/developer/target/db/templates.simulator.sql: Unknown column 'state' in 'field list'

A similar error is occurring on the builds for PR #1636.

yadvr · 2016-08-29T06:28:09Z

@jburwell changing code version (in pom.xml) to 4.8.2.0-SNAPSHOT is a valid change, but due to the way our db upgrade path works please revert the change on db upgrade path names and string values to 4.8.2 as explained for a similar change in #1665
The Travis failures were caused due to the change in db upgrade path names, they failed at the deploydb step.

jburwell · 2016-08-30T06:10:40Z

@rhtyd I have updated this patch to properly support four position version numbers, as well as, remove the requirement that all versions have a DbUpgrade class defined and/or an upgrade path. Please see the commit message for more information about the scope and reasoning for these changes.

Often, patch and security releases do not require schema migrations or data migrations. However, if an empty upgrade class and associated scripts are not defined, the upgrade process will break. With this change, if a release does not have an upgrade, a noop DbUpgrade is added to the upgrade path. This approach allows the upgrade to proceed and for the database to properly reflect the installed version. This change should make the release process simpler as RMs no longer need to rememeber to create this boilerplate code when starting a new release. Beginning with the 4.8.2.0 and 4.9.1.0 releases, the project will formally adopt a four (4) position release number to properly accomodate rekeases that contain only CVE fixes. The DatabaseUpgradeChecker and Version classes made assumptions that they would always parse and compare three (3) position version numbers. This change adds the CloudStackVersion value object that supports both three (3) and four (4) version numbers. It encapsulates version comparsion logic, as well as, the rules to allow three (3) and four (4) to interoperate. * Modifies DatabaseUpgradeChecker to handle derive an upgrade path for a version that was not explicitly specified. It determines the releases the first release before it with database migrations and uses that list as the basis for the list for version being calculated. A noop upgrade is then added to the list which causes no schema changes or data migrations, but will update the database to the version. * Adds unit tests for the upgrade path calculation logic in DatabaseUpgradeChecker * Removes dummy upgrade logic for the 4.8.2.0 introduced in previous versions of this patch * Introduces the CloudStackVersion value object which parses and compares three (3) and four (4) position version numbers. This class is intended to replace com.cloud.maint.Version. * Adds the junit-dataprovider dependency -- allowing test data to be concisely generated separately from the execution of a test case. Used extensively in the CloudStackVersionTest. Signed-off-by: Rohit Yadav <[email protected]>

yadvr · 2016-08-30T08:03:59Z

@jburwell I've fixed the issue failing db upgrade, it was a minor comparison issue in the beginning of the upgrade process. On my local env the upgrade worked as expected. LGTM.

jburwell · 2016-08-31T20:32:44Z

@syed per our conversation on Slack, the following is the test procedure to verify this PR:

Create a fresh install 4.8.1. Since we are verifying the database upgrade, the install only needs to start the Management Server.
Build this PR and deploy it against the 4.8.1 database
Restart the Management Server will trigger a database upgrade

Following database upgrade operation, the database version in the database should be 4.8.2.0.

/cc @rhtyd @karuturi

yadvr · 2016-09-01T03:54:02Z

Lgtm.

abhinandanprateek · 2016-09-01T09:51:11Z

Looks good on code review
here is my LGTM

yadvr · 2016-09-01T10:55:32Z

Given Travis has passed with 2 LGTMs and test LGTM, I'll go ahead and merge this after testing this across 4.8->4.9, 4.9->master.

yadvr · 2016-09-01T10:57:59Z

Tests on 4.8 branch, all pass:

- Clean db setup works, last upgraded version to 4.8.2.0.
   | 18 | 4.8.2.0 | 2016-09-01 09:56:21 | Complete |
- Upgrade tests from 4.8.0.

borisstoyanov · 2016-09-01T11:23:31Z

LGTM, I've stated management and the DB got updated to 4.8.2

yadvr · 2016-09-01T11:29:57Z

Tests on 4.9 branch (after fwd-merge), all pass:

- Upgrade from 4.8.2.0 to 4.9.1.0
- Clean fresh db deployment

yadvr · 2016-09-01T11:51:10Z

Tests on master branch (after fwd-merge), all pass:

- Upgrade from 4.8.2.0, upgrade from 4.9.1.0
- Clean db deployment

yadvr · 2016-09-01T11:52:08Z

Based on the tests and review. I'll proceed with merging this and fwd-merge this across 4.9, master branches.

@karuturi

Updating pom.xml version numbers for release 4.8.2.0-SNAPSHOTOften, patch and security releases do not require schema migrations or data migrations. However, if an empty upgrade class and associated scripts are not defined, the upgrade process will break. With this change, if a release does not have an upgrade, a noop DbUpgrade is added to the upgrade path. This approach allows the upgrade to proceed and for the database to properly reflect the installed version. This change should make the release process simpler as RMs no longer need to rememeber to create this boilerplate code when starting a new release. Beginning with the 4.8.2.0 and 4.9.1.0 releases, the project will formally adopt a four (4) position release number to properly accomodate rekeases that contain only CVE fixes. The DatabaseUpgradeChecker and Version classes made assumptions that they would always parse and compare three (3) position version numbers. This change adds the CloudStackVersion value object that supports both three (3) and four (4) version numbers. It encapsulates version comparsion logic, as well as, the rules to allow three (3) and four (4) to interoperate. * Modifies DatabaseUpgradeChecker to handle derive an upgrade path for a version that was not explicitly specified. It determines the releases the first release before it with database migrations and uses that list as the basis for the list for version being calculated. A noop upgrade is then added to the list which causes no schema changes or data migrations, but will update the database to the version. * Adds unit tests for the upgrade path calculation logic in DatabaseUpgradeChecker * Removes dummy upgrade logic for the 4.8.2.0 introduced in previous versions of this patch * Introduces the CloudStackVersion value object which parses and compares three (3) and four (4) position version numbers. This class is intended to replace com.cloud.maint.Version. * Adds the junit-dataprovider dependency -- allowing test data to be concisely generated separately from the execution of a test case. Used extensively in the CloudStackVersionTest. Signed-off-by: John Burwell <[email protected]> /cc @rhtyd @karuturi * pr/1654: Adds support for four position versions and optional db upgrades Signed-off-by: Rohit Yadav <[email protected]>

syed · 2016-09-01T15:36:35Z

@jburwell looks like @rhtyd already tested this. Do you need another testing? I am currently setting up my env

jburwell · 2016-09-01T15:39:21Z

@syed we received the LGTMs necessary overnight. Thank you for helping out.

…8.0.0-scclouds' Corrige _restart_ com _clean-up_ em VPCs não aplicando as regras de _load balancer_ de todas as redes Closes apache#1654 See merge request scclouds/scclouds!756

jburwell force-pushed the jsb/4.8.2.0-version branch from c053f29 to cfa1dcc Compare August 28, 2016 20:56

This was referenced Aug 29, 2016

Fix a quote issue with Spanish L10N (from transifex translation) #1636

Merged

Fixes regarding VOLUME_DELETE events resulting from account deletion #1624

Merged

jburwell force-pushed the jsb/4.8.2.0-version branch from f6d9667 to 7f5510f Compare August 30, 2016 05:58

yadvr force-pushed the jsb/4.8.2.0-version branch from 7f5510f to 8b316e1 Compare August 30, 2016 08:00

yadvr force-pushed the jsb/4.8.2.0-version branch from 8b316e1 to 8d11511 Compare August 30, 2016 08:02

yadvr mentioned this pull request Aug 30, 2016

Changes database upgrade script names to be consistent for the 4.9.1.0 release #1665

Merged

asfgit merged commit 8d11511 into apache:4.8 Sep 1, 2016

Updating pom.xml version numbers for release 4.8.2.0-SNAPSHOT #1654

Updating pom.xml version numbers for release 4.8.2.0-SNAPSHOT #1654

Uh oh!

Conversation

jburwell commented Aug 23, 2016 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

yadvr commented Aug 23, 2016

Uh oh!

blueorangutan commented Aug 23, 2016

Uh oh!

yadvr commented Aug 23, 2016

Uh oh!

blueorangutan commented Aug 23, 2016

Uh oh!

yadvr commented Aug 23, 2016

Uh oh!

yadvr commented Aug 25, 2016

Uh oh!

jburwell commented Aug 28, 2016

Uh oh!

jburwell commented Aug 29, 2016 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

yadvr commented Aug 29, 2016

Uh oh!

jburwell commented Aug 30, 2016

Uh oh!

yadvr commented Aug 30, 2016

Uh oh!

jburwell commented Aug 31, 2016 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

yadvr commented Sep 1, 2016

Uh oh!

abhinandanprateek commented Sep 1, 2016

Uh oh!

yadvr commented Sep 1, 2016

Uh oh!

yadvr commented Sep 1, 2016 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

borisstoyanov commented Sep 1, 2016

Uh oh!

yadvr commented Sep 1, 2016

Uh oh!

yadvr commented Sep 1, 2016

Uh oh!

yadvr commented Sep 1, 2016

Uh oh!

syed commented Sep 1, 2016

Uh oh!

jburwell commented Sep 1, 2016

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

jburwell commented Aug 23, 2016 •

edited

Loading

jburwell commented Aug 29, 2016 •

edited

Loading

jburwell commented Aug 31, 2016 •

edited

Loading

yadvr commented Sep 1, 2016 •

edited

Loading