This change adds a new activate script to cleaning old information
from capabilities column from i_host table.
To allow the usage of Kubernetes Power Manager StarlingX app, the
information of minimum and maximum allowed frequency, and cstates
available were stored in capabilities column for each node (i_host
table).
Due to a new approach, information is stored in specific columns
for each parameter. To avoid residual information in the capabilities
column, during the information migration process, the script removes
such parameters from the column.
Test Plan:
PASS: capabilities column cleaned (target information was removed)
PASS: script successfully skipped in other action steps
Story: 2011069
Task: 49822
Change-Id: Ifc955ecdb0c2a5b47c0dadbda083811fd2456b05
Signed-off-by: Eduardo Juliano Alberti <eduardo.alberti@windriver.com>
Previous release contains attribute ’encrypted-fs’ in the
’platform config’ service parameter, which is used to enable
and disable the luks file system. Upgrade activity need to
delete this unused attribute from the database.
This change adds a new migration script to delete 'encrypted-fs'
attribute. The script will run only when from release is 22.12
and during upgrade-activate.
Test Plan:
PASS: build-pkgs -c controllerconfig
PASS: build-image
PASS: AIO-SX upgrade to 24.xx from previous release with luks
file system disabled. After upgrade activate encrypted-fs
attribute should be deleted from DB.
PASS: AIO-SX upgrade to 24.xx from previous release with luks
file system enabled. After upgrade activate encrypted-fs
attribute should be deleted from DB.
PASS: AIO-DX upgrade to 24.xx from previous release with luks
file system disabled. After upgrading controller-1(upgraded/
active controller), script execution should delete
encrypted-fs attribute from the DB.
Story: 2010873
Task: 49663
Change-Id: I96ed9bf572f20e64419763eb285f4997c37ddf9b
Signed-off-by: Jagatguru Prasad Mishra <jagatguruprasad.mishra@windriver.com>
This change implements the upgrade data migration to:
1) fill the network_addresspools table with the information from
the networks and address_pools tables
2) fill the correct value of primary_pool_family for each networks
table entry
Test Plan
[PASS] Upgrade controller-1 and verify that the tables networks and
network_addresspools have the correct values after data
migration
Story: 2011027
Task: 49774
Change-Id: I91a2471c6ecce47c46945034c9c461ad42ae16d7
Signed-off-by: Andre Kantek <andrefernandozanella.kantek@windriver.com>
As part of USM major release upgrade, this commit creates a
script to update the first upgraded controller attributes during
deploy start, so that sysinv integration does not fail and allow
deploy host to run successfully.
Test Plan
PASS: run simulated deploy host for AIO-SX successfully
PASS: run simulated deploy host for AIO-DX successfully
Story: 2010676
Task: 49744
Change-Id: Ic179e63dc9088df9ced8aff01ebf320ab8fa6374
Signed-off-by: Heitor Matsui <heitorvieira.matsui@windriver.com>
With commit [1], a new upgrade script was included, but since
it is not expecting the new port parameter it broke the new USM
feature "software deploy start".
This commit fixes the issue.
[1] https://review.opendev.org/c/starlingx/config/+/909866
Test Plan
PASS: run software deploy start successfully
Story: 2010676
Task: 49699
Change-Id: I79101b53e6c335ed9fe5b412ca029d1c17df3cea
Signed-off-by: Heitor Matsui <heitorvieira.matsui@windriver.com>
The release stx.9 with FQDN support for MGMT network
uses the hieradata with the new pattern:
<hostname>.yaml
But the release stx.8 is still using the old name:
<mgmt_ip>.yaml
During an upgrade controller-0 want to update
the <mgmt_ip>.yaml and controller-1 wants to use
the <hostname>.yaml, so it is necessary to change
the code to use/update the right hieradata.
Additionally, during an upgrade the active
controller running the old release can't resolve
the FQDN (i.e: controller.internal ), for this
reason during the controller-1 upgrade, the FQDN
can not be used.
Test Plan:
IPv6 AIO-SX fresh install
IPv6 AIO-DX fresh install
IPv4 AIO-SX upgrade from previous release
without story 2010722 to new release
that has the story 2010722 (not master)
IPv4 AIO-DX upgrade from previous release
without story 2010722 to new release
that has the story 2010722 (not master)
IPv4 STANDARD upgrade from previous release
without story 2010722 to new release
that has the story 2010722 (not master)
IPv6 AIO-DX upgrade from previous release
without story 2010722 to new release
that has the story 2010722 (not master)
IPv6 DC lab upgrade from previous release
without story 2010722 to new release
that has the story 2010722 (not master)
Story: 2010722
Task: 48609
Signed-off-by: Fabiano Correa Mercer <fabiano.correamercer@windriver.com>
Change-Id: I555185bea7fadb772a4023b6ecb4379e01e0f16c
Fetching the deploy plug-in helm-chart by using
the command "grep "deployment-manager.tgz" in the
directory /usr/local/share/applications/helm/ for
the purpose of deploying an upgrade to deploy plug-in.
Due to recent developments in the deploy plug-in
system-application, a new helm-chart is generated with
the naming convention deployment-manager_*tgz. The
current retrieval process is obtaining both
deploy plug-in and system application helm-charts.
To address this, a hyphen ("-") has been added to the
grep command ("-deployment-manager") to specifically
check for deploy plug-in and exclude the system-application.
Test-Plan:
PASS: Verify the deploy plug-in helm-chart is retrieved.
PASS: Verify the deploy plug-in is refreshed when it
is installed
Closes-Bug: 2055699
Change-Id: I9d8ae5d491f6a9cacca1e68574c4cb4431264342
Signed-off-by: sharang bhardwaj <sharang.bhardwaj@windriver.com>
As we are using secure luks file system which is replicated
as well between controllers. We don't need to copy it from
drbd config location in controllerconfig service.
This change avoids copy of encryption-provider.yaml from
'/opt/platform/config/<version>/kubernetes' to
'/etc/kubernetes'. This fixes the issue observed during
platform upgrade.
Test Plan:
PASS: build-pkgs -c -p controllerconfig
PASS: build-image
PASS: SX upgrade: system should be upgraded to the latest version
without any issues.
Story: 2010873
Task: 49376
Change-Id: Id0656df6878eed0bd7df2c1e9d5739cf2d536aa2
Signed-off-by: Jagatguru Prasad Mishra <jagatguruprasad.mishra@windriver.com>
For subcloud phase deploy story (2010756), the previous deploy_status
for the subcloud configuration step were replaced. If a subcloud in
a failed deploy state remained after an upgrade, it was not possible
to re-run the deploy config step. This commit changes the deploy
status of subclouds from 'deploy-prep-failed' to 'pre-config-failed'
and from 'deploy-failed' to 'config-failed', allowing the user to run
'dcmanager subcloud deploy config'.
Test plan:
- PASS: Upgrade a system controller from STX-8 to master and verify
the data-migration step runs successfully on controller-1
and the subclouds deploy_status were updated from
'deploy-prep-failed' to 'pre-config-failed' and
'deploy-failed' to 'config-failed'. Verify that other
subclouds with different deploy_status remain untouched.
Notes about the tests:
- There was a mismatch on dcmanager db migrate scripts between the
developers ISOs used for the test. The STX-8 had a migrate_version
of 15, but the last script on master was 16, and said script was
already applied on STX-8. For testing, the migrate_version on
dcmanager db was updated with:
psql -x -d dcmanager -c "update migrate_version set version=16"
- The hieradata file (/opt/platform/puppet/23.09/hieradata/)
from hosts was updated to use the hostname instead of management
ip. To be able to unlock controller-1, it was necessary to rename
said file from "controller-1.yaml" to "<mgmt_ip>.yaml".
- Post unlock, controller-1 transitioned to unlock-disabled-failed
and software.log showed an rsync error because of
"Unknown module: 'software'". As the migrate script was already
executed successfully, the test ended here. The error was:
command: rsync -acv --delete rsync://controller/software/
/opt/software/
sync error: error starting client-server protocol (code 5)
at main.c(1817) [Receiver=3.2.3]
Story: 2010756
Task: 49402
Change-Id: Id9b43a6d087f1fba4132f24340ad368f01daac5d
Signed-off-by: Victor Romano <victor.gluzromano@windriver.com>
Parse the metadata of all application bundles under the helm application
folder and save to the kube_app_bundle table. This is done during sysinv
startup and when a new ostree commit is deployed.
The auto update logic was changed to enable retrieving metadata from
the database for all available bundles of a given app and compute which
bundle should be used to carry out the upgrade.
The bundle choice is done based on the minimum and maximum Kubernetes
versions supported by the application. If multiple bundles fit that
criteria then the application with the highest version number is chosen.
The 65-k8s-app-upgrade.sh script also takes into account multiple
bundles during the platform upgrade activation step, prioritizing
lowest versions available to ensure compatibility with the Kubernetes
version carried over from the N release. A follow-up change will improve
this mechanism to discover specific app versions.
When platform patches are applied and the ostree is changed then the
content of the helm application folder is reevaluated and the database
updated accordingly if there are new or removed bundles.
Test plan:
PASS: build-pkgs -a & build-image
PASS: Fresh AIO-SX install.
PASS: Fresh AIO-DX install.
PASS: Manually place multiple tarballs of one application with
different versions under /usr/local/share/applications/helm/
and check if the app is updated correctly.
PASS: Build a reboot required patch that removes the istio
bundle and adds a new metrics-server version.
Apply the reboot required patch.
Check if istio was removed from the kube_app_bundle table.
Check if the metrics-server previous version was removed from the
kube_app_bundle table.
Check if the metrics-server new version was added to the
kube_app_bundle table.
Check if metrics-server was updated to the new version added
to the database.
PASS: Build a no reboot required patch that does not restart
sysinv, removes the istio bundle and adds a new metrics-server
version.
Apply the no reboot required patch.
Check if istio was removed from the kube_app_bundle table.
Check if the metrics-server previous version was removed from the
kube_app_bundle table.
Check if the metrics-server new version was added to the
kube_app_bundle table.
Check if metrics-server was updated to the new version added
to the database.
PASS: Build a no reboot required patch that restarts sysinv,
removes the istio bundle and adds a new metrics-server version.
Apply the no reboot required patch.
Check if istio was removed from the kube_app_bundle table.
Check if the metrics-server previous version was removed from the
kube_app_bundle table.
Check if the metrics-server new version was added to the
kube_app_bundle table and was updated.
Check if metrics-server was updated to the new version added
to the database.
PASS: Install power-metrics on stx-8.
Run platform upgrade from stx-8 placing two different versions of
metrics-server under /usr/local/share/applications/helm/.
Check if default apps and metrics-server were properly updated
during upgrade-activate step.
Check if power-metrics was auto updated after upgrade-complete
step.
Story: 2010929
Task: 49097
Change-Id: I46f7cb6ebc59ad49157e9044a4937a406313671e
Signed-off-by: Igor Soares <Igor.PiresSoares@windriver.com>
This change fixes the removal of Armada images from registry.
Initially it was thought that it would only have the
airshipt/armada image, but there is also starlingx/armada-image.
To resolve this, the starlingx/armada-image key was added to
the images to be deleted.
Test Plan:
PASS Build pkgs and build image
PASS Upgrade SX stx-8 -> master
PASS When the 76-remove-armada-if-unused.py script is run
no error appears and at the end of activation no Armada
image is found.
Closes-Bug: 2048400
Change-Id: I91ed6a2f8bd0478d845a68716ea6e19b978c47f9
Signed-off-by: David Bastos <david.barbosabastos@windriver.com>
A new mandatory argument was added to the registry_image.list
method in the cgts sysinv client breaking the contract on
76-remove-armada-if-unused.py thus resulting in a TypeError
exception.
This commit adds the missing parameter and fixes the error.
Test Plan:
PASS Build pkgs and build image
PASS Upgrade SX stx-8 -> master
PASS Armada removed when there are no Armada apps
Closes-Bug: 2047643
Change-Id: I16a8cc4ed6c12751fc3f90c7c12499914cf6aa52
Signed-off-by: David Bastos <david.barbosabastos@windriver.com>
During ansible bootstrap, encryption-provider.yaml was copied to
'/opt/platform/config/<version>/kubernetes' directory from
'/etc/kubernetes'. After supporting luks volume, this file is moved
to the luks volume and symlink is created at '/etc/kubernetes'
and '/opt/platform/config/<version>/kubernetes' pointing to
encryption-provider.yaml file in the luks volume.
After ansible bootstrap completes, controllerconfig service tries to
copy the files from '/opt/platform/config/<version>/kubernetes' to
'/etc/kubernetes'. So it tries to copy encryption-provider.yaml as
well which is a symlink of a file in luks volume.
This change adds an argument '-P' to to the 'cp'
command which avoid copying the source content from the symlink
pointing to the luks volume. This change is required as the
luks volume may not be accessible while it is getting copied.
The directory for which this '-P' option is applied contains
only one symlink which is 'encryption-provider.yaml', so there
is no negative impact.
Test Plan:
PASS: build-pkgs -c -p controllerconfig
PASS: AIO-SX bootstrap should pass and host should come to
unlocked/enabled/available state
PASS: Verify if a symlink encryption-provider.yaml is copied at
'/etc/kubernetes/' location after host-unlock.
PASS: Verify if the below file is accessible
/var/luks/stx/luks_fs/controller/etc/kubernetes/
encryption-provider.yaml from symlink in
/etc/kubernetes/
PASS: Standard setup- Verify if a symlink encryption-provider.yaml
is copied at '/etc/kubernetes/' on both controllers.
PASS: Standard setup- Verify if a symlink encryption-provider.yaml
is present at '/opt/platform/config/<version>/kubernetes/'
on conroller-1 after 'system host-swact 1'
PASS: Standard setup- lock/unlock controller-1. Check if puppet
mainfest is executed succesfully on controller-1 after reboot.
Controller should come to unlocked/enabled/available state.
PASS: Standard setup- lock/unlock controller-0. Check if puppet
mainfest is executed succesfully on controller-0 after reboot.
Controller should come to unlocked/enabled/available state.
Depends-on: https://review.opendev.org/c/starlingx/ansible-playbooks/+/904342
Story: 2010873
Task: 49323
Change-Id: I8e064fc0e7a6fc8a0b571673fe8f6e66e4e43aee
Signed-off-by: Jagatguru Prasad Mishra <jagatguruprasad.mishra@windriver.com>
Minor tweaks were required to enable this upgrade.
The removed steps are covered by the upgrade playbook already.
TEST PLAN
PASS: Optimized B&R on AIO-SX
PASS: Optimized upgrade on AIO-SX, stx8 to stx9
PASS: Optimized upgrade on AIO-SX, stx6 to stx8 to stx9
PASS: Optimized B&R on AIO-SX after upgrade
* stx8 to stx9
* stx6 to stx8 to stx9
PASS: Optimized upgrade on AIO-SX subcloud, stx6 to stx8 to stx9
* With and without prestaging
Story: 2010798
Task: 49009
Joshua Kraitberg <joshua.kraitberg@windriver.com>
Change-Id: I7880aa63fdbf920b778a01646151be85973b7c7a
Commit [1] added support to the new port parameter used by
Unified Software Management framework. Script 81 needs to be
changed as well since it is returning an "Invalid option"
error during "software deploy start" for upgrade.
This commit enables script 81 to ignore the optional port
parameter so that it won't fail during the deploy start
operation.
Test Plan
PASS: "software deploy start" command executed successfully
for the upgrade scenario
PASS: legacy upgrade activate stx8 -> stx9 executed successfully
[1] https://review.opendev.org/c/starlingx/config/+/896959
Story: 2010676
Task: 49231
Change-Id: I22f1ef727bae3773904285c6a50fa49956840b17
Signed-off-by: Heitor Matsui <heitorvieira.matsui@windriver.com>
With the release of stx8 some scripts were deprecated and will
not be needed on future upgrades, for example, those who were
needed only for CentOS (stx6 or stx7) -> Debian (stx8) upgrade.
This commit removes the deprecated scripts.
Note: The USM "software deploy activate" command will be tested in
the scope of another commit, since it is not yet implemented.
Test Plan:
PASS: legacy upgrade stx8 -> stx9 "migrate" and "activate" steps
executed successfully
PASS: USM "software deploy start" command executed successfully
Story: 2010676
Task: 49196
Change-Id: Iee96afa1eca5d9d9751168a53635e5995c47aff4
Signed-off-by: Heitor Matsui <heitorvieira.matsui@windriver.com>
This commit makes the proper changes for upgrade script 65 to
run during activate step in upgrade from stx8 -> master/stx9, and
this commit also enables cert-manager and oidc-auth-apps to be
handled by this script, now that CentOS is deprecated and there
is no need to have a separate script to handle these applications
anymore.
Note: the USM upgrade activate, i.e. "software deploy activate"
will be tested in the scope of another commit, since this command
is still under development.
Test Plan
PASS: legacy upgrade stx8 -> master/stx9 upgrade activate step
executed successfully
Story: 2010676
Task: 49226
Change-Id: I85bf36cae2a190a0e6f49b9fa5b1a8b13d28d043
Signed-off-by: Heitor Matsui <heitorvieira.matsui@windriver.com>
Updates the no_proxy list in the
service-parameter-list during the management
network reconfiguration.
In the first reboot after the management network
reconfiguration, The system will use the new
management IPs and some files will be updated,
like the /etc/hosts.
It is necessary to update the following paths,
with the new values:
/opt/platform/sysinv
/opt/platform/config
Additionally, during the first reboot the
system is still using the old mgmt IPs until the
apply_network_config.sh and puppet code updates
the system.
The sw-patch services starts before or at same
time of these operations and can use the old
MGMT IPs and failed to answer audit requests.
For this reason it is necessary to restart
these services.
Tests:
IPv6 mgmt network reconfig in subcloud AIO-SX
IPv4 mgmt network reconfig in standalone AIO-SX
AIO-DX Fresh install
AIO-SX Fresh install
AIO-SX IPv4 apply patch after mgmt reconfig
Story: 2010722
Task: 49203
Change-Id: I8a17f50c229a53965e13c889f0ea6ff8efd687c3
Signed-off-by: Fabiano Correa Mercer <fabiano.correamercer@windriver.com>
Enabled upgrade script to verify the existence and issue if necessary
the now (after this Story) required platform certificates (REST API &
Web Server, Docker Registry and local OpenLDAP), using the
'system-local-ca' ClusterIssuer for DX systems.
The proper system upgrades tests weren't executed due to instability
in upgrades to stx 9.0. Manual tests were executed instead, and should
cover the upgrade scenario correctly.
Test plan:
PASS: Execute the upgrade script manually and verify that the required
platform certificates are not altered.
PASS: Delete the required platform certificates. Execute the upgrade
script manually and verify that the required platform
certificates are issued.
Story: 2009811
Task: 49160
Depends-on: https://review.opendev.org/c/starlingx/ansible-playbooks/+/902088
Change-Id: I50c98bfa289b3a37e1a53a79315594e5ac3bd344
Signed-off-by: Marcelo Loebens <Marcelo.DeCastroLoebens@windriver.com>
During a management network reconfiguration on AIO-SX with Ceph
storage backend, this flag will indicate the need to update the
ceph-monitor to the new network.
The flag is used in the mandatory controller-0 unlock during the
mgmt reconfiguration by the "platform::ceph::monitor" puppet class,
which will proceed with the ip update.
Test Plan:
PASS: Reconfigure mgmt network on AIO-SX ipv4 with Ceph backend
PASS: Reconfigure mgmt network on AIO-SX ipv6 with Ceph backend
PASS: After controller-0 is unlocked, check if Ceph is healthy with
'ceph -s'
PASS: Reconfigure mgmt network on AIO-SX ipv4 without Ceph backend
Story: 2010722
Task: 48973
Depends on: https://review.opendev.org/c/starlingx/config/+/889724
Change-Id: Id3e4cee3b4cf51fa48c160d4ddbed0a3b55cb97a
Signed-off-by: Gabriel de Araújo Cabral <gabriel.cabral@windriver.com>
This change allows the reconfiguration of the management
address_pool for an AIO-SX installation.
The reconfiguration can be done even when the system was
already configured and unlocked, but it needs to lock the
controller in order to reconfigure the management network.
Since there are ansible rules using the name: "management"
as the address_pool, it is necessary to enforce the use of
the address_pool named "management" in order to create the
mgmt network.
During a management network reconfiguration the DNSMASQ
changes must not be applied in runtime, to all changes
take effect the host lock/unlock is mandatory.
Test plan
PASS: AIO-SX IPv4 delete and create another management
address-pool and create the management network with it
PASS: AIO-SX IPv6 delete and create another management
address-pool and create the management network with it
PASS: AIO-SX IPv4 fresh install
PASS: AIO-SX IPv6 fresh install
PASS: AIO-DX IPv4 fresh install
PASS: AIO-DX IPv6 fresh install
PASS: STANDARD IPv4 fresh install
PASS: DC with AIO-SX IPv4 fresh install
Story: 2010722
Task: 48469
Change-Id: I2de156162dc83d2c16437d2d8068054de19a3b20
Signed-off-by: Fabiano Correa Mercer <fabiano.correamercer@windriver.com>
Signed-off-by: Teresa Ho <teresa.ho@windriver.com>
The migration code was deleting /opt/platform/<FROM_RELEASE>/sysinv,
before it was migrated to /opt/platform/<TO_RELEASE>/sysinv.
This caused the files inside like `sysinv.conf.default` to be lost
during simplex upgrade.
Originally, in legacy restore, `sysinv.conf.default` was
individually restored after migration so the deletion
had no impact.
`sysinv.conf.default` is required on non-SX systems.
This is used so that other hosts sysinv-agent can mount and
have an initial sysinv.conf suitable for RPC to the controller.
The loss of the file is not problematic on a SX system, but would
prevent a later SX-to-DX migration.
TEST PLAN
PASS: Optimized upgrade AIO-SX, stx6 to stx8
PASS: Optimized upgrade AIO-SX, stx7 to stx8
Closes-bug: 2042971
Signed-off-by: Joshua Kraitberg <joshua.kraitberg@windriver.com>
Change-Id: I7a22e050f74785b99ea6b7758cf23d3419add1de
During upgrade, in 64-upgrade-cert-manager.sh script
we backup the existing cert-manager resources to
cert-manager-backup.yaml file which contains the
resourceVersion and convert the apiVersion and copy to
new file cert-manager-v1.yaml and once the cert-manager
app is upgraded, we apply the cert-manager-v1.yaml so in
the last-configuration-applied which contains the
resourceVersion is causing issue during legacy restore
operation. This Fix addresses this issue by removing the
"resourceVersion" from all the cm resources in the
cert-manager-backup.yaml file.
Test Cases:
PASS: Perform upgrade on the system, after upgrade verify
that cert-manager resources like issuer,clusterissuer,
certificates,certificaterequests doesn't contain the
resourceVersion in the last-applied-configuration under
annotations
PASS: On an upgraded system, try to update the clusterissuer
with the clusterissuer definition file and verify it is
successfully updated
PASS: On an upgraded system, perform backup and restore and
verify it is successful
Closes-bug: 2042971
Change-Id: I31c77b75182d953d5a7050f9ea08b3f66bef1e47
Signed-off-by: amantri <ayyappa.mantri@windriver.com>
This commit includes additional information for the orchestrator during
the subcloud upgrade failure stage, specifically at the steps that run
migration scripts.
Test plan:
- PASS: Execute the 'upgrade_controller_simplex' command, forcing a
failure in different migration scripts. Verify that the output message
contains sufficient execution information.
Closes-Bug: 2038950
Signed-off-by: fperez <fabrizio.perez@windriver.com>
Change-Id: I9971f08e763856938517e1ef2e7a76443432f734
This commit to remove the usage of the mgmt_ip in the host table in
favor of either controller FQDN for AIO-SX or the management address
configured in the address table.
Test Plan:
PASS: AIO-SX and AIO-DX virtualbox installation IPv4/IPv6
PASS: Standard virtualbox installation IPv6
PASS: DC virtualbox installation IPv4 ( AIO-SX/DX subclouds )
PASS: AIO-SX and AIO-DX installation IPv4/IPv6
PASS: AIO-DX plus installation IPv6
PASS: DC IPv6 and subcloud AIO-SX
PASS: AIO-DX host-swact
PASS: DC IPv4 virtualbox with subcloud AIO-DX and AIO-DX
PASS: AIO-SX to AIO-DX migration
PASS: netstat -tupl ( no services are using the MGMT IP address )
PASS: Ran sanity/regression tests
PASS: Backup and Restore for AIO-SX/AIO-DX / DC subcloud AIO-SX
PASS: Add and unlock worker node on a deployed standard system
Story: 2010722
Task: 48567
Depends-on: https://review.opendev.org/c/starlingx/config/+/886208
Signed-off-by: Teresa Ho <teresa.ho@windriver.com>
Change-Id: Id2a79ee291b4f706611ebd8eeceaed31e6ca5aa5
Migration scripts with "migrate" action needs to be run under
environment that from-release PostgreSQL using default port
and to-release running with a different port in USM upgrade.
This commit is to add the 4th parameter to indicate the port
to postgres connection.
Test Plan:
PASS: Run legacy data-migration
PASS: Run new data-migration
Story: 2010676
Task: 48886
Change-Id: Ib7b5818b9355c1196fb8b6fc3d916ede7f7907fa
Signed-off-by: Luis Eduardo Bonatti <LuizEduardo.Bonatti@windriver.com>
Included upgrade script to verify the existence and issue if necessary
the now (after this Story) required platform certificates (REST API &
Web Server, Docker Registry and local OpenLDAP), using the
'system-local-ca' ClusterIssuer for DX systems.
These changes are dormant. The upgrade script will not be triggered
unless a specific file used as feature flag is present in the system.
This will prevent interfering with current behavior until the whole
feature is completed.
The proper system upgrades tests will be done together when the
support for DC systems is concluded in a future task for this Story.
Test plan:
PASS: Deploy AIO-SX and AIO-DX, providing the CA cert in
'system-local-ca' overrides and the flag. Verified that:
- HTTPS is enabled correctly after unlocking the controller.
- The certificate under '/etc/ssl/private/' is correct.
- HTTP is disabled correctly after deleting the certificate and
using the 'system modify' API to disable it.
PASS: Execute the upgrade script manually and verify that the required
platform certificates are not altered.
PASS: Delete the required platform certificates. Execute the upgrade
script manually and verify that the required platform
certificates are issued.
Story: 2009811
Task: 48891
Depends-on: https://review.opendev.org/c/starlingx/ansible-playbooks/+/897364
Change-Id: Ie628f24ce11fe7ad5aafb1e526320a4e943be547
Signed-off-by: Marcelo Loebens <Marcelo.DeCastroLoebens@windriver.com>
This change adds a new migration script to update static
hieradata for new release deployment.
The new static hieradata values will be generated by command
sysinv-puppet create-static-config
and selected key/value pairs will update to static hieradata
files from current running system.
In particular this change includes new USM static hieradata
migration to 23.09.
TCs:
passed migrating new USM key pairs from 22.12 -> 23.09
Story: 2010676
Task: 48909
Change-Id: I3560233876e6f0592933656b11a45c20ba1408e8
Signed-off-by: Bin Qian <bin.qian@windriver.com>
This change removes the helmv2 database migration from the upgrade
process. It aims to equalize the upgrade behavior across simplex and
multinode loads.
The helmv2 database migration was removed from simplex upgrades on this
commit: a6d51ad9bb
In addition to that, the references to the helmv2 database need to be
removed from controllerconfig and sysinv in order to fully remove its
support and prevent it from being migrated on multinode scenarios.
This will only have effect for upgrades from stx-9 onwards as
the code changed is executed during the upgrade-start phase.
Test Plan:
PASS: build-pkgs && build-image
PASS: Check if AIO-SX fresh install was not affected
PASS: Check if AIO-DX fresh install was not affected
Story: 48480
Task: 2010560
Change-Id: I45568ddc05d6f8f1450bac752b9cb79e0fab5f79
Signed-off-by: Igor Soares <Igor.PiresSoares@windriver.com>
This change adds a function to the Armada removal script that runs
during platform upgrades giving it the ability to remove the helmv2
database if no Armada apps are present.
Helm v2 is not supported anymore so its database should be dropped
alongside the removal of Armada as no other platform components will
make use of it.
Test Plan:
PASS: build-pkgs && build-image
PASS: SX upgrade from stx-8 to master
Check if helmv2 database was removed
Story: 48480
Task: 2010560
Change-Id: I3c6489643bcf608893b8715f4d3c4a45c72e03ec
Signed-off-by: Igor Soares <Igor.PiresSoares@windriver.com>
Add a script that removes Armada if there are no Armada
apps running. It runs during the upgrade-activate step
checking if there are remaining Armada apps or helmv2
releases.
Test Plan:
PASS Build pkgs and build image
PASS Upgrade SX stx-8 -> master
PASS Armada removed when there are no Armada apps
Story: 2010560
Task: 48563
Co-Authored-By: Igor Pires Soares <igor.piressoares@windriver.com>
Change-Id: Id336f02757573995028cb183458777b1d1b5991e
Signed-off-by: David Barbosa Bastos <david.barbosabastos@windriver.com>
Zuul