Install both ramdisks in the ipa downloader #84
Reference in New Issue
Block a user
No description provided.
Delete Branch "nbelouin/Factory:multi-arch-ipa"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Signed-off-by: Nicolas Belouin nicolas.belouin@suse.com
@@ -12,0 +24,4 @@
else
if [ "${CERT_CHANGED:-0}" = "1" ]; then
# Image has changed we need to refresh certs anyway
CERT_CHANGED=0
IMO it would be easier to understand if we had two variables e.g
CERT_CHANGED
andIMAGE_CHANGED
then rebuild if either one is non-zero below?@@ -64,2 +64,4 @@
databaseServiceName: metal3-mariadb
# Architecture for IPA (either x86_64 or arm64)
ipaArchitecture: x86_64
I think there are some arch specific things also in ironic-image:
https://build.opensuse.org/projects/isv:SUSE:Edge:Metal3:Ironic:2024.2/packages/ironic-image/files/prepare-efi.sh?expand=1
So we may need to give this a different name perhaps - I guess the most intuitive behavior would be by default we deploy downstream clusters with the same arch as the management cluster, with the ability to override it with some
architectureOverride
variable or similar?Note that in future we expect to wire this is via the BaremetalHost resource which does contain an Architecture field, but that will need some adjustments upstream e.g see here - we'd have to enable some additional variables e.g
DEPLOY_RAMDISK_URL_AARCH64
etc, and adjust so when available these are used depending on the BMHspec.architecture
Well I missed the
prepare-efi
stuff, and I got bad news here, with our current (provided by SLES)shim
, we cannot have an ESP file that works for both x86 and arm (as it blindly loadsgrub.efi
that is not an arch specific name), I think I may be able to come with a workaround for this iteration, but for the future it will be near impossible without a change here (the other way would be a change in Ironic itself to introduce abootloader_by_arch
parameter).About the name, I'll go for
deployArchitecture
, since there is more than just the IPA things.Regarding the explicit arch rather than arch override, well the chart has no knowledge of what is the current arch, hence I went for this, we can go for an override if we get some additional symlinks/files without a suffix for "current architecture", but it feels a bit wrong to me.
For the future, I guess the Architecture field gets forwarded to Ironic by the BMO, thus we should just change it from using the
deploy_ramdisk
parameter to thedeploy_ramdisk_by_arch
one.This looks like a great start, thanks for working on it! :)
730aaf84ec
to780d38b356
780d38b356
to19ca659670
19ca659670
toe6067ffda3
e6067ffda3
to087a1773ca
087a1773ca
toa5d297f8d0
a5d297f8d0
to3179a9ddd2
3179a9ddd2
to6b35d42d97
6b35d42d97
toe50206725e
e50206725e
to4c97292e62
4c97292e62
to8543583e4d
Tested in VM with the following scenario:
@@ -63,6 +63,9 @@ global:
# Name for the MariaDB service
databaseServiceName: metal3-mariadb
# Architecture for deployed nodes (either x86_64 or arm64)
I'd say to rename arm64 to aarch64 to be more specific
8543583e4d
to4974b00e4f
LGTM we can merge it. It has been tested in Lab with VMs and Baremetal (both using mgt-cluster x86_64 and deploying arm64 downstream clusters)
4974b00e4f
todfcba60da1
dfcba60da1
to80779f6f6c
80779f6f6c
to329cfd4999
WIP: Install both ramdisks in the ipa downloaderto Install both ramdisks in the ipa downloaderLGTM
329cfd4999
to98fa8835f7