Configuration for KEB allow to provide a keys with null values and it doesnt work with Landscaper

[PK85]

Description

Landscaper uses strategic merge patch semantics when processing data objects. Null values are interpreted as "delete this key" rather than "set this key to null". This is what we saw in the kcp-kyma-environment-broker configmap too.

This config:

providersConfiguration:
    aws:
        regionsSupportingMachine:
            g4dn:
                us-gov-east-1:
                us-gov-west-1:
            g6:

becomes:

providersConfiguration:
    aws:
        regionsSupportingMachine:
            g4dn: { }

AC

1. check where in our configs we allow to leave keys with null values
2. for regionsSupportingMachine we should consider supporting empty [ ] or "" and treat them as null scenarios
3. This is an enhancement(backward compatible), release as a patch. Update docs

[PK85]

I tested a settings:
input:

    regionsSupportingMachine:
      g4dn:
        eu-central-1: []
        eu-west-2:
        us-east-1:
        ap-south-1:
        us-west-2: [ a, b, c ]

output CM (kcp-kyma-environment-broker):

      regionsSupportingMachine:
        g4dn:
          ap-south-1: null
          eu-central-1: []
          eu-west-2: null
          us-east-1: null
          us-west-2:
            - a
            - b
            - c

and all three zones has been used.

So eu-central-1: [] means "region is supported but use the default Kyma zones" — it's distinct from omitting the region entirely (null / absent key would also mean "use Kyma zones" via the
same fallback, but IsRegionSupported treats them differently: null key exists → supported, missing key → not supported).

[PK85]

⏺ When zonesDiscovery: true, regionsSupportingMachine is completely ignored for zone assignment. The zones come exclusively from the real AWS EC2 API (client.AvailableZones() calls
DescribeInstanceTypeOfferings).

So in your scenario:

• zonesDiscovery: true → the if p.providerSpec.ZonesDiscovery(...) branch is taken (workers/provider.go:44)
• workerZones = discoveredZones[additionalWorkerNodePool.MachineType] — populated by the AWS API call
• regionsSupportingMachine.g6.eu-central-1: ["a","b","c","d"] is never consulted
• regions.eu-central-1.zones: ["a","b"] is also never consulted for additional worker pools

regionsSupportingMachine with zonesDiscovery: true is only used for validation (IsRegionSupported) — not for zone selection.

[PK85]

⏺ Yes — the AWS client is region-scoped. The client is created with region as a parameter (line 49: New(ctx, accessKeyID, secretAccessKey, region string)), which sets the AWS SDK region for all
API calls. So DescribeInstanceTypeOfferings automatically returns only zones within that region.

The result is: discoveredZones["g6"] will contain only zones in eu-central-1 where the g6 machine type is actually available — directly from the AWS API, with no involvement of
regionsSupportingMachine or regions.eu-central-1.zones.

The map is scoped to a single operation, and the AWS client is initialized with that operation's region — so:

• Operation A (eu-central-1): {"g6.xlarge": ["eu-central-1a", "eu-central-1b"]}
• Operation B (us-east-1): {"g6.xlarge": ["us-east-1a", "us-east-1b", "us-east-1c"]}

Same machine type, different zones — because DescribeInstanceTypeOfferings runs against the region from that specific provisioning request.

[PK85]

Taking into account all above investigation below config:

providersConfiguration:
    aws:
        zonesDiscovery: true
        regionsSupportingMachine:
            g4dn:
                us-gov-east-1: [] 
                us-gov-west-1: [] 

allows to create g4dn in the us-gov-east-1 and us-gov-west-1 only, and zonesDiscovery for g4dn is calculated and stored for us-gov-east-1 and us-gov-west-1

[PK85]

and for:

providersConfiguration:
    aws:
        regionsSupportingMachine:
            g6: {} 

Empty map is a solution.

Then when asking for this machine user sees:

{"description":"In the region eu-central-1, the following machine types are not available: g6.xlarge (used in: gpu-pool), it is supported in the "}