Map explicit ComputeInstance fields to Kubernetes CR - #309
akshaynadkarni merged 4 commits into
Conversation
The fulfillment-controller now passes explicit ComputeInstance fields (cores, memoryGiB, image, bootDisk, additionalDisks, runStrategy, sshKey, userDataSecretRef) from the fulfillment API through to the Kubernetes CR spec. Without this, the CRD validation rejects CRs missing the required explicit fields. Adds tests for both presence and absence of explicit fields. https://issues.redhat.com/browse/MGMT-23103 Generated with [Claude Code](https://claude.com/claude-code)
Kubernetes unstructured.SetNestedField panics on int32 values. Cast cores, memoryGiB, and disk sizeGiB to int64 for compatibility. Also use []any for additionalDisks slice (not []map[string]any). https://issues.redhat.com/browse/MGMT-23103 Generated with [Claude Code](https://claude.com/claude-code)
| } | ||
| if ciSpec.HasUserDataSecretRef() { | ||
| spec["userDataSecretRef"] = map[string]any{ | ||
| "name": ciSpec.GetUserDataSecretRef(), |
There was a problem hiding this comment.
the secret must be created from the string, no? osac-project/enhancement-proposals#21 (comment)
There was a problem hiding this comment.
You're right. The fulfillment-service needs to create the Secret from the user data content, as discussed in the EP. I'll update this PR to create the Secret in the tenant namespace and pass the reference to the CR.
Instead of passing userDataSecretRef as a plain name reference to the CR, the fulfillment-service now creates a Secret in the hub namespace from the user data content provided via the API. - Add ensureUserDataSecret with create/update sub-functions - Add deleteUserDataSecret for cleanup on CI deletion - Add gvks.Secret constant and userDataSecretSuffix/userDataSecretKey constants - Separate Secret lifecycle from spec building (addExplicitFields stays pure) - Add userDataSecretName field to task struct Generated with [Claude Code](https://claude.com/claude-code)
dc780fd to
4a5a84d
Compare
Instead of passing userDataSecretRef as a plain name reference to the CR, the fulfillment-service creates a Secret in the hub namespace from the user data content provided via the API. - Add ensureUserDataSecret that creates Secret with owner reference - Owner reference enables automatic cleanup via K8s garbage collector - Secret is immutable: create once, skip if AlreadyExists - CR is created first, then Secret (standard K8s owner reference pattern) - Add gvks.Secret constant and userDataSecretSuffix/userDataSecretKey constants - Separate Secret lifecycle from spec building (addExplicitFields stays pure) Generated with [Claude Code](https://claude.com/claude-code)
4a5a84d to
b982dc8
Compare
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: akshaynadkarni, tzvatot The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
@tzvatot: The following test failed, say
Full PR test history. Your PR dashboard. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
4 participants
Summary
The fulfillment-controller's
buildSpec()was only mappingtemplateID,templateParameters, andrestartRequestedAtto the Kubernetes CR. The new CRD requires explicit spec fields (cores, memoryGiB, image, etc.) — without this change, CRD validation rejects the CR.Changes
addExplicitFields()to map all new spec fields from the fulfillment API to the K8s CR:cores, memoryGiB, image, bootDisk, additionalDisks, runStrategy, sshKey, userDataSecretRef
int32panic: Kubernetesunstructured.SetNestedFielddoesn't supportint32— cast toint64[]map[string]any→[]anyfor additionalDisks slice (required by unstructured)E2E Validated
Full stack test passed on vmaas-dev: CLI → fulfillment-service → operator → provisioning → Running state.
Related