Grzegorz Grasza 54efd31239 Add new dbsync command with first online data migration

This adds the new command 'ironic-dbsync online_data_migrations'.
To limit downtime during upgrades, data migrations will be done online
with migration scripts that could be run during normal operation of an
ironic cluster, after the upgrade but before the next one.

Each migration script should ensure that all related DB records are
migrated to the new format. Scripts can detect the format based on
the object version which is stored in the version column.

The online data migration has one script; a function that backfills
the new version column, using versions of objects from the release
prior to this.

This includes code to check the object versions for compatibility with
an ironic release. However, the check is turned off (and will be turned on
in Queens), since we need to boot-strap the new version column before
we can turn the check on. To do this check, we need to keep a list of all
supported versions for every object; release_mapping.RELEASE_MAPPING was
modified so that the object versions is now a list instead of one value.

Change-Id: I1a9fa829951ecf98cae6896d82ba20cf89062394
Closes-Bug: #1585141
Partial-bug: #1526283
Co-Authored-By: Ruby Loo <ruby.loo@intel.com>

2017-08-02 13:33:37 -04:00

5.0 KiB

Raw Blame History

Releasing Ironic Projects

Since the responsibility for releases will move between people, we document that process here.

A full list of projects that ironic manages is available in the governance site.

Who is responsible for releases?

The current PTL is ultimately responsible for making sure code gets released. They may choose to delegate this responsibility to a liaison, which is documented in the cross-project liaison wiki.

Anyone may submit a release request per the process below, but the PTL or liaison must +1 the request for it to be processed.

Release process

Releases are managed by the OpenStack release team. The release process is documented in the Project Team Guide.

Things to do before releasing

Review the unreleased release notes, if the project uses them. Make sure they follow our standards, are coherent, and have proper grammar. Combine release notes if necessary (for example, a release note for a feature and another release note to add to that feature may be combined).
For ironic releases only, not ironic-inspector releases: if any new API microversions have been added since the last release, update the REST API version history (doc/source/contributor/webapi-version-history.rst) to indicate that they were part of the new release.
To support rolling upgrades, add this new release version (and release name if it is a named release) into ironic/common/release_mappings.py:
- in RELEASE_MAPPING, make a copy of the 'master' entry, and rename the first 'master' entry to the new semver release version.
- If this is a named release, add a RELEASE_MAPPING entry for the named release. Its value should be the same as that of the latest semver one (that you just added above).
- Regenerate the sample config file, so that the choices for the [DEFAULT]/pin_release_version configuration are accurate.

Things to do after releasing

When a release is done that results in a stable branch

When a release is done that results in a stable branch for the project, the release automation will push a number of changes that need to be approved.

In the new stable branch, this will include:

a change to point .gitreview at the branch

a change to update the upper constraints file used by tox

In the master branch, this will include:

updating the release notes RST to include the new branch

Additionally, changes need to be made to the stable branch to:

update the ironic devstack plugin to point at the branched tarball for IPA. An example of this patch is here.

update links in developer documentation to point to the branched version of the install guide.

update links in the install guide to point to the branched version of the developer documentation.

set appropriate defaults for TEMPEST_BAREMETAL_MIN_MICROVERSION and TEMPEST_BAREMETAL_MAX_MICROVERSION in devstack/lib/ironic to make sure that unsupported API tempest tests are skipped on stable branches.

Additionally, changes need to be made on master to:

create an empty commit with a Sem-Ver tag to bump the generated minor version. See example and pbr documentation for details.

to support rolling upgrades, since the release was a named release:

In ironic/common/release_mappings.py, delete any entries from RELEASE_MAPPING associated with the oldest named release. Since we support upgrades between adjacent named releases, the master branch will only support upgrades from the most recent named release to master.

regenerate the sample config file, so that the choices for the [DEFAULT]/pin_release_version configuration are accurate.

remove any DB migration scripts from ironic.cmd.dbsync.ONLINE_MIGRATIONS and remove the corresponding code from ironic. (These migration scripts are used to migrate from an old release to this latest release; they shouldn't be needed after that.)

For all releases

For all releases, whether or not it results in a stable branch:

update the specs repo to mark any specs completed in the release as implemented.

remove any -2s on patches that were blocked until after the release.

5.0 KiB Raw Blame History