<platform_release>_packages_list.txt
The prestaging operation on the system controller requires the list
of packages and their checksums in a file named
"<platform_release>_packages_list.txt", where <software_version> is
the version of the system controller (i.e. the new version which the
subclouds are being upgraded to).
The list of packages and their checksums is obtained from different
sources as a file named "package_checksums". This file should be
copied to /usr/local/share/pkg-list as
<platform_release>_packages_list.txt. It is currently copied as
package_checksums.
This fix copies the file "package_checksums" to
/usr/local/share/pkg-list as <platform_release>_packages_list.txt.
Test Plan:
PASS: Verify that package_checksums is copied to
/usr/local/share/pkg-list as <platform_release>_packages_list.txt
when upgrading the system controller to a higher version.
PASS: Verify that package_checksums is copied to
/usr/local/share/pkg-list as <platform_release>_packages_list.txt
when installing a controller over pxeboot
PASS: Verify that package_checksums is copied to
/usr/local/share/pkg-list as <platform_release>_packages_list.txt
when adding a subcloud from the system controller (using dcmanager
add)
PASS: Verify that package_checksums is copied to
/usr/local/share/pkg-list as <platform_release>_packages_list.txt
when installing a system controller in virtualbox from
bootimage.iso.
Closes-Bug: 1978420
Signed-off-by: Shrikumar Sharma <shrikumar.sharma@windriver.com>
Change-Id: I6270a7c9169718b2096a83135eeadb634d37b76b
In order to prepare shared software packages on the system
controller for subcloud prestaging, the file
"package-checksums" containing a list of packages and
their checksums, must be copied to /usr/local/share/pkg-list
and renamed as packages_list.
The prestaging process needs the package-and-checksum list
for the version of the load on the controller and the version
of the load on the subcloud.
This file needs to be copied over to /var/www/pages/feed/rel-<id>
on the controller so that the subclouds can download it.
This file can be obtained by downloading from the system
controller. If the system is being installed directly from
a boot iso, the appropriate kickstart is called to install
the file from the mounted bootimage.iso.
There are a few cases which determine how to get the file.
Cases:
1. Install load directly from bootimage.iso (both controller and
subcloud) - copy from mounted iso to location. The iso
may be present on a peripheral device like a CD/DVD.
2. Install load over lan - download the file from server and copy
to locations (all controllers)
3. Version upgrade by importing a new load - copy the file
to the appropriate location on the system controller.
The subcloud will download the package_checksums belonging
to the imported load as part of the upgrade process.
Test Plan:
PASS: Verify that the file is copied over to /usr/local/share/
pkg-list and /var/www/feed/rel-<rel-id>/ when installing
System Controller or subcloud from bootimage.iso
PASS: Verify that the file is copied to the locations when
installing controller-1 via pxeboot
PASS: Verify that the file is copied to the locations when upgrading
the System Controller (using load-import)
PASS: Verify that the file is copied when adding a subcloud with
dcmanager subcloud add
Depends On: https://review.opendev.org/c/starlingx/distcloud/+/841828
Story: 2009799
Task: 45376
Change-Id: If14b197999f2ae03e15fdc08ec27511ca1d41767
Signed-off-by: Shrikumar Sharma <shrikumar.sharma@windriver.com>
During upgrade, installer RPMs from release N need to be installed
to host (release N+1).
During downgrade, installer RPMs from release N+1 don't need to be
installed to host (release N)
Currently installer from "the other release" is installed to host
regardless an upgrade is in progress or no by kickstarts. This
requires the kickstarts on release N to understand the structure of
installer RPM of future release. The installer from "the other
release" only useful is when an upgrade is in progress (to provide
installer when downgrade is required).
This change removes the step to install RPMs from other release to
host when upgrade is not in progress.
TCs:
Upgrade from 21.05 -> 21.12 abort after controller-1
upgrade completed
Upgrade from 21.05 -> 21.12
Upgrade from 21.12 -> 22.02 abort after controller-1
upgrade completed
Upgrade from 21.12 -> 22.02
load delete after 21.05 -> 21.12 upgrade abort
load delete after 21.05 -> 21.12 upgrade complete
load delete after 21.12 -> 22.02 upgrade abort
load delete after 21.12 -> 22.02 upgrade complete
Depends-on: https://review.opendev.org/c/starlingx/config/+/829943
Closes-bug: 1961424
Change-Id: I86edbe09410d3df9b9440d89208af90f0eb1fd09
Signed-off-by: Bin Qian <bin.qian@windriver.com>
Update pxeboot-update script to accept parameter for
installer base URL
Add a common function to parse the port number from
inst.repo
Update pxeboot and kickstart URLs to support a configurable
HTTP port
Story: 2004642
Task: 28593
Depends-On: https://review.openstack.org/#/c/634237/
Change-Id: Ibd66e89e49794ca57b938eb43d227860eda6674a
Signed-off-by: Tao Liu <tao.liu@windriver.com>
The prepatching feature changed how kickstarts are delivered. Where
before, they were generated as part of build-iso and copied during
installation, they are now delivered in packages. However, when the
controller kickstart mirrors the feed directory from the active
controller after installation, it may overwrite these installed files.
This update changes the wget command options to protect against this.
In addition, testing with an RT kernel patch showed Anaconda was also
installing the mlnx-ofa_kernel-rt-modules package from the patching
repo on a standard note, as it attempts to resolve a packaging
requirement. This update also adds explicit exclusions to the package
lists in the standard and lowlatency kickstarts to avoid installing
rt modules on the standard nodes, and vice versa.
Change-Id: I56b22fb0846db05a96004184c1060c05566d5363
Signed-off-by: Don Penney <don.penney@windriver.com>
lbonatti