The get_not_version method was put in, but never used, the
underlying upgrade check code just explicitly passes the
appropriate query arguments and doesn't use the helper.
Why now? Because it used model_query.
Change-Id: I697f13486c2e11cd04b4f381f3066eeb154ea2a3
... And tags, but nobody uses tags since it is not available
via the API.
Anyhow, the online upgrade code was written under the assumption
that *all* tables had an "id" column. This is not always true
in the ironic data model for tables which started as pure extensions
of the Nodes table, and fails in particular when:
1) A database row has data stored in an ealier version of the object
2) That same object gets a version upgrade.
In the case which discovered this, BIOSSetting was added at version
1.0, and later updated to include additional fields which incremented
the version to 1.1. When the upgrade went to evaluate and iterate
through the fields, the command failed because the table was designed
around "node_id" instead of "id".
Story: 2010632
Task: 47590
Change-Id: I7bec6cfacb9d1558bc514c07386583436759f4df
The database schema upgrade check had support for an
explicit list of known versions to handle the upgrade.
who knew!
Anyhow, we haven't used it in three years since the addition,
and it seems to make more sense to just be able to indicate
"we know initial field versions may not be able to be retrieved
and act accordingly". As such, when no table is found, the
pre-upgrade version check execution will continue onward fearlessly!
Call it a spiritual successor to Ibcf0728bc5d1b0cbdd78796526f9c93fc99e8c08
Change-Id: Icae5162c2501b0d1217ad0e6ee34ebef40e95204
The iSCSI deploy was very easy to start with, but it has since become
apparently that it suffers from scalability and maintenance issues.
It was deprecated in the Victoria cycle and can now be removed.
Hide the guide to upgrade to hardware types since it's very outdated.
I had to remove the iBMC diagram since my SVG-fu is not enough to fix it.
Change-Id: I2cd6bf7b27fe0be2c08104b0cc37654b506b2e62
We hit an issue in Kayobe CI where we have the following config:
enabled_deploy_interfaces: iscsi,direct
default_deploy_interface: iscsi
In practice, direct does not work out of the box in Kayobe currently.
The online migration added recently to move nodes from iscsi to direct
caused issues in our upgrade jobs, since it migrated nodes to direct,
without the config in place to make this work.
This change avoids migrating nodes when iscsi is the default deploy
interface.
Story: 2008114
Task: 40996
Change-Id: I5cf0684dc53a2d89fac12e578b28e73e7697a97e
This change marks the iscsi deploy interface as deprecated and
stops enabling it by default.
An online data migration is provided for iscsi->direct, provided that:
1) the direct deploy is enabled,
2) image_download_source!=swift.
The CI coverage for iscsi deploy is left only on standalone jobs.
Story: #2008114
Task: #40830
Change-Id: I4a66401b24c49c705861e0745867b7fc706a7509
Python3 have a standard library for mock in the unittest module,
let's drop the mock requirement and switch tests to unittest mock.
Change-Id: I4f1b3e25c8adbc24cdda51c73da3b66967f7ef23
Fixes W504 and E117, resulting in some indentation changes.
Also fixes code that exceeds the complexity requirement, that is bumped
to 20 (mostly to avoid refactoring the agent heartbeat call, resulting
in conflicts for the deploy steps work).
Change-Id: I8e49f2c039b0ddfca9138f8e148708b7e8b5df7e
The version check is run before tables are created, so it cannot
succeed for them.
Change-Id: Ibcf0728bc5d1b0cbdd78796526f9c93fc99e8c08
Story: #2004589
Task: #28467
This adds a migration step that will be executed as the last step
in the 'ironic-dbsync online_data_migration' command. It updates
all the objects that aren't in their latest version, to be in
their latest version.
Co-Authored-By: Dmitry Tantsur <dtantsur@redhat.com>
Change-Id: Ib39319a75205ce7692f0525f99200a5de3d60a88
Story: #2004174
Task: #27656
Adds the fields and bumps the objects versions. Excludes the field from
the node API for now.
Also adds the conductor_group config option, and populates the field in
the conductors table.
Also fixes a fundamentally broken test in ironic.tests.unit.db.test_api.
Change-Id: Ice2f90f7739b2927712ed45c969865136a216bd6
Story: 2001795
Task: 22640
Task: 22642
When performing a skip version upgrade from a release earlier than Pike,
Ironic will crash when check_versions cannot find the 'version' columns
in the database.
This change adds a safety check which detects old database
version missing the 'version' columns. Instead of crashing, it will
inform the user that skip version upgrades are not supported and
that database migrations need to be run for each skipped versions instead.
Story: 2002558
Task: 22122
Change-Id: Ifa100c6fd168fc59b56bba0c41836958b10f2d47
* removes any bits related to loading classic drivers from
the drivers factory code
* removes exceptions that only happen when classic drivers
can be loaded
* removes the BaseDriver, moves the useful functionality to
the BareDriver class
* /v1/drivers/?type=classic now always returns an empty list
* removes the migration updating classic drivers to hardware
types
The documentation will be updated separately.
Change-Id: I8ee58dfade87ae2a2544c5dcc27702c069f5089d
For API versions >= 1.28, Port & portgroup's .extra['vif_port_id'] was
deprecated in Ocata. Before we can remove support for this, we need to
copy that information to the object's internal_info['tenant_vif_port_id'].
This copy/migration is done at the API layer when the user specifies the
.extra[] value, as well as when the 'ironic db-sync online_data-migrations'
is run.
In order to know whether the ports and port groups have been migrated,
their IronicObject versions are incremented.
This also fixes it so that for API versions < 1.28, the deprecation
warning is not shown, since we still need to support extra['vif_port_id']
in this case.
When a port or portgroup's .extra['vif_port_id'] is removed via a
PATCH API request, that VIF is removed from that object's internal_info.
Change-Id: I69468c935e68dd9d37a474c318c3ceb9cdfc5868
Partial-Bug: 1722850
This change adds a new data migration: migrate_to_hardware_types.
It works by walking through known classic drivers, detecting matching
hardware types and interfaces and updates nodes accordingly.
Nodes that cannot be updated (e.g. matching hardware type is not
enabled) are skipped. A new migration option reset_unsupported_interfaces
can be set to True to allow resetting optional interfaces to their
no-op versions.
The example implementation are provided for the community supported
IPMI and SNMP drivers, as well as for fake drivers based on them.
Change-Id: I732b44f2ab1ef73f56b352415ffd9cdd8a0e232b
Partial-Bug: #1690185
Now that we have rolling upgrades and the version column was
added and populated in the Pike release, we can add checks to
make sure the versions of objects in the DB are compatible
with this ironic release, before ironic-dbsync's upgrade or
online_data_migrations does its work. These ironic-dbsync
calls are made as part of upgrading to this (Queens) release.
Change-Id: I68758f8a29d483f5c0a7439fa2ea2962b2eb4124
Partial-Bug: #1708243
This modifies the backfill_version_column method that was used in Pike,
to backfill the version column for the Conductor object, since we missed
setting the Conductor's version column in Pike. This method is invoked
when the operator runs ``ironic-dbsync online_data_migrations``.
Change-Id: I42fec0ac9c8b684219f14822648e627fce529d36
Partial-Bug: 1526283
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>