recipes: design grounded qualification for the OKE gpuStack profile

[yuanchen8911]

The problem

OKE is the only family whose gpuStack varies two dimensions independently:

	Advertiser	Driver
oci-default	OKE add-on	node image
operator-plugin	GPU Operator	node image
operator-managed	GPU Operator	GPU Operator

GKE's coupled modes can be separated by one grounded fact, and AKS's single varying axis by one provider projection. #2355 uses two ClusterPolicy readings — but both read back fields rendered by the selected value; neither observes external advertiser or driver ownership. So each value satisfies its own readiness constraints by construction, and a wrong external mode passes pre-flight.

Gating question

Can AICR derive a durable, externally grounded image-supplied vs operator-supplied driver classification for every supported OKE GPU pool, fail closed when pools disagree, and reproduce that classification at generation and again at validation?

OCI exposes NodePool.nodeSourceDetails.imageId, but OKE custom images can carry arbitrary modifications, so an OCID alone does not establish driver ownership. Resolving this likely needs an allowlist of known image OCIDs, an image tag or naming contract, provisioning metadata, or an explicit supported-image contract.

Second assumption, not yet resolved

The advertiser axis is not settled either. The oci.oraclecloud.com/disable-gpu-device-plugin=true label covers the node-label disablement route, but DGXC disables the plugin by removing the add-on, which leaves no node marker. Either NKX-9804 makes the label the canonical contract even under add-on removal, or AICR needs a normalized projection combining cluster add-on state with per-pool labels — an add-on-state projection alone does not cover per-pool label opt-outs while the add-on remains installed. The choice below is not decided by the driver signal alone.

Options

• A — Two grounded facts. Advertiser from the label (or an add-on projection); driver from an OCI pool projection, mirroring the AKS --aks-gpu-pools pattern. All three values qualify on ordinary durable profile constraints — evaluated at generation when a snapshot is supplied and re-evaluated at validation. No readinessConstraints, no new phase. Needs both assumptions resolved.
• B — Two-value profile. Ship oci-default and operator-plugin, both restricted to driver-bearing images and requiring GPU.hardware.driver-loaded=true; distinguish them by the advertiser fact. Defer operator-managed. Needs one distinguishing fact, but still needs that common driver-present invariant.
• C — ClusterPolicy readback (current feat(recipes): gpuStack profile for the OKE family #2355). Rejected: self-satisfying. The readings do distinguish the bundle-rendered values from each other — which is all ADR-015 currently requires — but they do not qualify the external pool mode. This is precisely the gap the proposed ADR amendment below would close.
• D — Generation-only constraints. Would make driver-loaded usable on fresh pools, but mis-selects when regenerating from an already-deployed cluster. Not viable as the primary mechanism.
• E — Defer the profile. ADR-015's own position when no value has a distinguisher.

What is needed to decide

Representative evidence for every intended class — not another PR revision:

• Oracle GPU image pool
• Driver-bearing custom image pool, if supported
• Driverless custom image pool
• Label-based plugin disablement
• Add-on removal
• Mixed-pool aggregation behavior

Completion criteria

This issue is done when it:

1. selects A, B, or E;
2. defines behavior for mixed and unavailable pool data (fail closed, and what the diagnostic says);
3. identifies how the data is acquired at both phases — generation and validation;
4. records the supported custom-image contract, i.e. what makes an image classifiable.

Candidate ADR-015 amendment

To land separately, in its own PR, once this resolves:

Each independently varying axis must be grounded in observed state external to the profile's rendered desired configuration, and the combined observations must uniquely identify every declared value. Reading back desired fields rendered by the selected value provides drift detection, not profile qualification.

Related

#2355, #2356, #2347, #2359, NKX-9804, and ADR-015 (docs/design/015-recipe-configuration-profiles.md)