Conversation
| EnableCapabilities bool | ||
| } | ||
|
|
||
| func capabilitiesEqual(a, b gardencorev1beta1.Capabilities) bool { |
There was a problem hiding this comment.
We have already this func in ossync/os_image_updater.go:134 file. Shall we reuse it?
| }) | ||
| } | ||
| flavor := &entry.CapabilityFlavors[flavorIdx] | ||
| regionIdx := slices.IndexFunc(flavor.Regions, func(m openstackv1alpha1.RegionIDMapping) bool { |
There was a problem hiding this comment.
Looks like it will re-sort the regions of every flavor on every src iteration. Only the flavor at flavorIdx was touched.
Sort only the modified flavor's regions, not all. I'm assuming something like:
slices.SortFunc(entry.CapabilityFlavors[flavorIdx].Regions, ...)
There was a problem hiding this comment.
But each src has it's own copy of regions. So we need to sort all regions for each src
| Version: version, | ||
| CleanVersion: version, | ||
| Architectures: []string{"amd64"}, | ||
| Capabilities: gardenerv1beta1.Capabilities{ossync.ArchitectureCapability: []string{"amd64"}}, |
There was a problem hiding this comment.
Acceptable for now since OpenStack is amd64-only, but worth a // TODO: derive from namePrefix when arm64 is added comment so it's not silently wrong later
There was a problem hiding this comment.
There is no test exercising two source images with different capability sets producing two CapabilityFlavors entries on the same version. That scenario is impossible with the current Glance source (all images hardcode amd64), but the provider code supports it and it's the hardest path through the merge logic. Should be added to prevent regressions if multi-arch is introduced
There was a problem hiding this comment.
Added TestConfigureCapabilitiesMultipleFlavorsOnSameVersion. Also added several other tests: TestUpsertRegion (table-driven, 7 cases), sort stability tests for both legacy regions and flavor regions, and TestConfigureCapabilitiesMultipleVersionsWithFlavors
| regionDE = "eu-de-1" | ||
| regionNL = "eu-nl-1" |
There was a problem hiding this comment.
Let's have just
region1 = "region1"
region2 = "region2"
| }) | ||
| } | ||
| flavor := &entry.CapabilityFlavors[flavorIdx] | ||
| regionIdx := slices.IndexFunc(flavor.Regions, func(m openstackv1alpha1.RegionIDMapping) bool { |
There was a problem hiding this comment.
But each src has it's own copy of regions. So we need to sort all regions for each src
| }) | ||
| } else { | ||
| flavor.Regions[regionIdx].ID = r.ID | ||
| } |
There was a problem hiding this comment.
There is exactly same logic is a little bit earlier. Let's introduce helper function
There was a problem hiding this comment.
Extracted as upsertRegion. Both call sites (legacy entry.Regions and capability flavor.Regions) now use it. Unit tests for the helper live in TestUpsertRegion in provider_test.go.
Signed-off-by: Palina Tember <palina.tember@sap.com>
Signed-off-by: Palina Tember <palina.tember@sap.com>
c7926ae to
bb41319
Compare
3 participants
Summary
Adds GEP-33 capability flavors support for OpenStack CloudProfiles in cloud-profile-sync. The goal is structural parity with IronCore — not because capability-based image selection is functionally relevant for OpenStack today, but to eliminate a maintenance gap between the two providers.
CleanVersionandCapabilitieson GlanceSourceImageso the capability path inImageUpdaterandOpenStackProviderhas data to work withEnableCapabilitiesfield andcapabilityFlavorsdual-write toOpenStackProvider, mirroring the IronCore pattern with per-region UUIDs instead of a single OCI image referenceEnableCapabilitiesthrough the controller toOpenStackProvider