Update the metal3-chart to fix the IPA ramdisk with multiple config-2 drives #145

Merged
nbelouin merged 2 commits from mchiappero/Factory:metal3_0.11.1 into main 2025-05-09 15:58:43 +02:00
Owner

Correct a bug in the IPA ramdisk, which resulted in the wrong config-2 volume being picked up by NetworkManager when multiple such disks are present on the system (e.g. from previous installation and redfish).

Correct a bug in the IPA ramdisk, which resulted in the wrong config-2 volume being picked up by NetworkManager when multiple such disks are present on the system (e.g. from previous installation and redfish).
mchiappero added 2 commits 2025-05-08 11:53:52 +02:00
Signed-off-by: Marco Chiappero <marco.chiappero@suse.com>
Update metal3-chart to leverage IPA downloader 3.0.4
Some checks failed
Build PR in OBS / Build PR in OBS (pull_request_target) Failing after -2s
aee375dbb1
Signed-off-by: Marco Chiappero <marco.chiappero@suse.com>
mchiappero requested review from amorgante 2025-05-08 11:54:13 +02:00
mchiappero requested review from nbelouin 2025-05-08 11:54:13 +02:00
mchiappero requested review from steven.hardy 2025-05-08 11:54:13 +02:00
mchiappero force-pushed metal3_0.11.1 from aee375dbb1 to 043aaedb4d 2025-05-08 12:38:40 +02:00 Compare
steven.hardy reviewed 2025-05-08 18:05:28 +02:00
@@ -23,4 +23,2 @@
nodeSelector: {}
enable_tls: false
Owner

Note for other reviewers - I think this reverts a mistake introduced via 1048591769 - @nbelouin I guess that was from some debugging?

Note for other reviewers - I think this reverts a mistake introduced via https://src.opensuse.org/suse-edge/Factory/commit/104859176984ee1268395e036ffe2a6b299fd6174d9e46286b4e90fff6f164cf - @nbelouin I guess that was from some debugging?
Owner

Was to solve some issues related to linting, no longer necessary and didn't remove those, so no problem in removing them.

Was to solve some issues related to linting, no longer necessary and didn't remove those, so no problem in removing them.
Author
Owner

Do we prefer to have a separate PR?

Do we prefer to have a separate PR?
steven.hardy approved these changes 2025-05-08 18:05:58 +02:00
nbelouin requested changes 2025-05-09 09:10:20 +02:00
Dismissed
nbelouin left a comment
Owner

Overall Looks good to me, just need to bump the chart version

Overall Looks good to me, just need to bump the chart version
@@ -26,3 +26,3 @@
name: metal3
type: application
version: "%%CHART_MAJOR%%.0.2+up0.11.0"
version: "%%CHART_MAJOR%%.0.2+up0.11.1"
Owner

Please also bump the chart version itself (the +up suffix isn't used for version ordering)

Please also bump the chart version itself (the `+up` suffix isn't used for version ordering)
nbelouin marked this conversation as resolved
mchiappero force-pushed metal3_0.11.1 from 043aaedb4d to 1f11000be9 2025-05-09 11:01:39 +02:00 Compare
Author
Owner

I'm not able to understand why the checks are failing, is it a problem with OBS? Do you have any idea?

I'm not able to understand why the checks are failing, is it a problem with OBS? Do you have any idea?
mchiappero force-pushed metal3_0.11.1 from 1f11000be9 to c2fdf53c4b 2025-05-09 11:13:31 +02:00 Compare
Owner

Well a merged PR broke sriov chart build, so it makes the checks to fail

Well a merged PR broke sriov chart build, so it makes the checks to fail
mchiappero force-pushed metal3_0.11.1 from c2fdf53c4b to fbb61edd06 2025-05-09 11:40:30 +02:00 Compare
steven.hardy reviewed 2025-05-09 11:42:23 +02:00
@@ -1,7 +1,7 @@
#!BuildTag: %%CHART_PREFIX%%metal3:%%CHART_MAJOR%%.0.2_up0.11.0
#!BuildTag: %%CHART_PREFIX%%metal3:%%CHART_MAJOR%%.0.2_up0.11.0-%RELEASE%
#!BuildTag: %%CHART_PREFIX%%metal3:%%CHART_MAJOR%%.0.3_up0.11.1
#!BuildTag: %%CHART_PREFIX%%metal3:%%CHART_MAJOR%%.0.3_up0.11.1-%RELEASE%
Owner

@nbelouin since this will be the first chart release for 3.3 do we expec this to be %%CHART_MAJOR%%.0.0 until the release happens?

@nbelouin since this will be the first chart release for 3.3 do we expec this to be `%%CHART_MAJOR%%.0.0` until the release happens?
Owner

no, we should always bump the last elements here (and not reset them), put simply if we consider Factory (with chart major 999) as a rolling upgrade like it should work as upgrades when we do changes to charts.

no, we should always bump the last elements here (and not reset them), put simply if we consider Factory (with chart major `999`) as a rolling upgrade like it should work as upgrades when we do changes to charts.
Owner

Ok thanks for clarifying - it may be worth discussing this with the team to ensure everyone is aware, as this is a different strategy to rancher/charts which resets the version for each rancher release

Ok thanks for clarifying - it may be worth discussing this with the team to ensure everyone is aware, as this is a different strategy to rancher/charts which resets the version for each rancher release
nbelouin approved these changes 2025-05-09 11:49:41 +02:00
Dismissed
mchiappero force-pushed metal3_0.11.1 from fbb61edd06 to 03e37421d7 2025-05-09 12:10:02 +02:00 Compare
Author
Owner

Well a merged PR broke sriov chart build, so it makes the checks to fail

It passes now, after the last rebase. Thank you 👍

> Well a merged PR broke sriov chart build, so it makes the checks to fail It passes now, after the last rebase. Thank you 👍
mchiappero force-pushed metal3_0.11.1 from 03e37421d7 to c6b78eb569 2025-05-09 14:18:50 +02:00 Compare
nbelouin approved these changes 2025-05-09 14:45:11 +02:00
nbelouin merged commit b28f7a5817 into main 2025-05-09 15:58:43 +02:00
Sign in to join this conversation.
No Label
3 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: suse-edge/Factory#145
No description provided.