This fix has been lost during the process of
migration of cluster data manipulation functionality
from the octane to this extension.
Change-Id: Ife92cbd0e8d8f8376ffcb1f333d1fac9e911ff3e
Closes-bug: 1573100
This patch adds new data pipline for seed cluster that add to cluster
deployment info attributes about upgrade
Change-Id: I0630e75508552927b67065ff85cb6bac1bb88f61
Checks that network roles mapping from original release is a subset of
network roles mapping of new cluster's release.
Change-Id: I521e70bf3df289abf3e71c5c1558faf7126db964
Partial-Bug: #1619162
for creating of network groups in the seed cluster
such as in the original cluster
Change-Id: I17f95756fa26ef0f7df0e969f9f1ba4331047c8d
Closes-Bug: #1616817
* netgroups mapping was changed (additional argument
for the mapping was added - name of node group)
* copying of node group during cluster cloning was added
Depends-On: I2638279371e91f15090c782fc5fdbb434a2e85f8
Partial-bug: #1612297
Change-Id: Ib1689d7b6d673c0d78434dd047a7ebc520c232e7
Co-Authored-By: Ryan Moe <rmoe@mirantis.com>
Co-Authored-By: Andrew Woodward <awoodward@mirantis.com>
Co-Authored-By: Ilya Kharin <akscram@gmail.com>
due to changes functions get_assigned_vips and
assign_given_vips_for_net_groups in nailgun.network.manager
in the next commit (I2638279371e91f15090c782fc5fdbb434a2e85f8)
Change-Id: I93e43be60dacc9ba5546cb50ba04a98bd35d276c
(cherry picked from commit 2d12209aaa)
This patch adds an ability to re-assign a set of the given nodes at
once. This feature was technically available but not exposed to the
client. A groupped re-assigning allows to effectively re-provision nodes
by creating an atomic task in Astute.
Change-Id: I4a7c7e35d844683ef73ad7f8459d1892e80e0a64
Related-Bug: #1616925
Required for create new release just for upgrade, that have overwrited
params. This params are valid for orig cluster release.
Change-Id: Ib2387b9c2b74902c7289ee8f69a5f5d323ec82ca
octane have some dirty hacks to change volumes attributes using nailgun
as a library, such modifications should be done in a extension
Change-Id: I422bb368916f3a319e286edcc6103a2834097a87
Implement transformations that are applied to cluster attributes during
environment cloning.
Conversion from text to text_list type has been limited to dns_list and
ntp_list keys only to keep predictable behavior.
Change-Id: I1ff596f850bd42243697cad1c1c35f0cf1386376
This change introduces new transformation mechanism:
- all available transformations are listed in setuptools entry points
under namespace like this (for cluster transformations):
nailgun.cluster_upgrade.transformations.cluster.9.0 =
dns_list = ...
ntp_list = ...
nailgun.cluster_upgrade.transformations.cluster.8.0 =
...
<etc>
- config file will include section that specifies enabled
transformations like this:
CLUSTER_UPGRADE_TRANSFORMATIONS:
cluster:
9.0: dns_list ntp_list ...
8.0: ...
7.0: ...
(only default values are implemented here, actual config support will
follow)
- when transformations are applied to clone cluster from version X to
version Y, first transformations for version X+1 are applied, then
X+2, and so on ending with transformations for version Y.
Since Nailgun doesn't provide any special extension initialization
callback, a Lazy wrapper is implemented to facilitate transformations
manager usage in extension.
Change-Id: I8ee75b54180106ad46c1df67f8d5937d6bd810a1
Changing of an operating system for clouds nodes is not supported and is
not tested at all. That's why this additional validation was added.
Change-Id: Ibf6db17f783879eff88e2366dfdb0a2871e2aa0a
Change Ia3da3bd809bcca923d53666eca54def78c995f65 broke our handlers as
it incorporated destructive changes to all handlers.
Change-Id: I688e833b1fb8b658f01b7f858a140c315fa513a2
* change_env_settings function was moved to cluster upgrade extention
* merge generated attributes code was written
Change-Id: I6d1e27b8b0c01f3251067bc88931cd2354feb5ce
Partial-Bug: #1602587
(cherry picked from commit dc2e3f9309)
* change_env_settings function was moved to cluster upgrade extention
* merge generated attributes code was written
Change-Id: I6d1e27b8b0c01f3251067bc88931cd2354feb5ce
Partial-Bug: #1602587
Without the versions/__init__.py file versions was not identified as
a package and was not included in a distribution.
Change-Id: I67f152ebb9234df880c61d79d154b1aabc8828c6
Closes-Bug: #1611793
Without the versions/__init__.py file versions was not identified as
a package and was not included in a distribution.
Change-Id: I67f152ebb9234df880c61d79d154b1aabc8828c6
Closes-Bug: #1611793
* added removing of space in text_list
* added test for merge_attributes
Change-Id: I5582878fc7c524551593abf21dfd4ea45cd430c9
Closes-bug: 1602607
(cherry picked from commit fdd2a62264)
Don't need to assign nics and bonds to netgroups
if network template has been applied to new cluster.
Change-Id: Ibd06de87964bf7a2038899d32e3d8a0189b9cbbd
Partial-bug: 1584044
Settings in release change. Cloned cluster should have values valid for
its release.
dns_list and net_list were text values but in version mitaka-9.0 it
changed to text_list
Change-Id: Iac0aa42b7c36333e6d9c40b8a27a19df9efe36f5
Closes-Bug: 1572179
(cherry picked from commit 5ae4c7ebdcdbf1621ce617de4ec019ae2b5670c4)
Nodes roles should be checked in CheckBeforeDeploymentTask,
because it's possible to deploy node with conflicting roles
or with incompatible role. Roles release metadata will be
used for roles checks, this metadata contains restrictions.
Since `depends` is not used anymore, it's changed to
`restrictions` in assignment validator.
Change-Id: Ibba7951968cbafd59fff0d516e74f9dd9e454edc
Closes-Bug: #1573006
(cherry picked from commit 3482a5d7a9417c268a526cf511e114be94c884be)
Now if common nodegroup has not been found for given nodes None as a
result is returned instead of default node group.
This directly affects procedure of VIP allocation as (e.g.) VIPs will
not be allocated when cluster does not have assigned nodes.
Tests updated accordingly
Change-Id: Iaa94453f3f98cc9238f9810aab7311ffabbfa8b7
Closes-Bug: #1549254
New handler triggers copying of VIPs from given original cluster to new
one. The reason for separation of this action from copying of network
configuration is that accordion to [1] copying of existing VIPs/allocation
of new ones will not take effect for new cluster unless it has assigned
nodes. Thus in context of cluster upgrade procedure VIP transfer must be
done after node reassignment, and as long as nodes are being operated on
one by one it would be not efficient to call VIP copying method after
each such reassignment.
Tests updated accordingly.
[1]: https://review.openstack.org/#/c/284841/
Change-Id: I33670e8f2561be6fe18cec75bfc7ecc056ae2f6b
Closes-Bug: #1552744
Andreas Jaeger