Bumping sriov packages (edge-1637) #301

Merged
steven.hardy merged 9 commits from antaloala/Factory:edge-1637 into main 2025-11-12 14:45:58 +01:00
Owner

Bumping all sriov packages to latest upstream version.
1 different commit per upgraded package.
Related OBS (sub)project: https://build.opensuse.org/project/monitor/home:antaloala:sriov-bump

Bumping all sriov packages to latest upstream version. 1 different commit per upgraded package. Related OBS (sub)project: https://build.opensuse.org/project/monitor/home:antaloala:sriov-bump
antaloala added 7 commits 2025-11-03 23:27:00 +01:00
antaloala requested review from amorgante 2025-11-03 23:27:00 +01:00
antaloala requested review from nbelouin 2025-11-03 23:27:00 +01:00
antaloala requested review from steven.hardy 2025-11-03 23:27:00 +01:00
antaloala added 1 commit 2025-11-03 23:52:50 +01:00
Updates release_images.yaml and release_manifest.yaml files with new SRIOV images and charts versions
All checks were successful
Check Release Manifest Local Charts Versions / Check Release Manifest Local Charts Versions (pull_request) Successful in 9s
Build PR in OBS / Build PR in OBS (pull_request_target) Successful in -26s
f9bdebe175
Owner

@antaloala this looks good to me - can we remove draft and mark as ready for review now?

@antaloala this looks good to me - can we remove draft and mark as ready for review now?
antaloala changed title from WIP: Bumping sriov packages (edge-1637) to Bumping sriov packages (edge-1637) 2025-11-11 19:43:40 +01:00
nbelouin approved these changes 2025-11-12 13:36:19 +01:00
nbelouin left a comment
Owner

LGTM, just a quick question though, would it be easier/better to handle the crd chart as a subchart of the network-operator chart?

LGTM, just a quick question though, would it be easier/better to handle the crd chart as a subchart of the network-operator chart?
Owner

LGTM, just a quick question though, would it be easier/better to handle the crd chart as a subchart of the network-operator chart?

It would be good to discuss this more generally, as our handling of CRDs is inconsistent, and in some cases causes problems on upgrade (e.g the crds subdir in the metal3 chart).

Is it better to have a separate chart so it can be applied prior to any chart upgrade by the upgrade controller in standalone scenarios? Also the rancher/charts pattern appears to be to use separate charts in the majority of cases AFAICS

> LGTM, just a quick question though, would it be easier/better to handle the crd chart as a subchart of the network-operator chart? It would be good to discuss this more generally, as our handling of CRDs is inconsistent, and in some cases causes problems on upgrade (e.g the crds subdir in the metal3 chart). Is it better to have a separate chart so it can be applied prior to any chart upgrade by the upgrade controller in standalone scenarios? Also the [rancher/charts](https://github.com/rancher/charts) pattern appears to be to use separate charts in the majority of cases AFAICS
steven.hardy approved these changes 2025-11-12 13:51:56 +01:00
steven.hardy merged commit f9bdebe175 into main 2025-11-12 14:45:58 +01:00
Owner

We discussed and agreed to follow up on the CRDs question, as it's part of a broader conversation around handling CRDs and consistency between charts

We discussed and agreed to follow up on the CRDs question, as it's part of a broader conversation around handling CRDs and consistency between charts
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#301