CNTRLPLANE-625: Add support for custom trust bundle for AWS API endpoints#8280
CNTRLPLANE-625: Add support for custom trust bundle for AWS API endpoints#8280hypershift-jira-solve-ci[bot] wants to merge 9 commits into
Conversation
|
Pipeline controller notification For optional jobs, comment This repository is configured in: LGTM mode |
openshift-ci-robot
added
the
jira/valid-reference
|
@hypershift-jira-solve-ci[bot]: This pull request references CNTRLPLANE-625 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "5.0.0" version, but no target version was set. DetailsIn response to this:
Instructions 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 openshift-eng/jira-lifecycle-plugin repository. |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: hypershift-jira-solve-ci[bot] The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
openshift-ci
Bot
added
area/control-plane-operator
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughAdds exported AWS constant Sequence DiagramsequenceDiagram
participant Reconciler as Reconciler
participant MgmtCluster as Management Cluster
participant GuestCluster as Guest Cluster
Reconciler->>Reconciler: Detect platform == AWS
Reconciler->>MgmtCluster: Get AWS provider-config ConfigMap (provider key)
MgmtCluster-->>Reconciler: Return provider config or NotFound/Error
alt AdditionalTrustBundle or TrustedCA set
Reconciler->>MgmtCluster: Get managed trust-bundle ConfigMap
alt Trust-bundle exists and non-empty
MgmtCluster-->>Reconciler: Return CA bundle data
else Missing or empty
MgmtCluster-->>Reconciler: NotFound or empty
end
end
Reconciler->>GuestCluster: Create/Update openshift-config/cloud-provider-config with provider config
alt CA bundle available
Reconciler->>GuestCluster: Set aws.CABundleKey = CA data
else No CA bundle
Reconciler->>GuestCluster: Ensure aws.CABundleKey absent
end
GuestCluster-->>Reconciler: Acknowledge write or return error
Reconciler->>Reconciler: Finish reconciliation
🚥 Pre-merge checks | ✅ 11 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (11 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In
`@control-plane-operator/hostedclusterconfigoperator/controllers/resources/resources.go`:
- Line 2446: Check that reference.Data[aws.ProviderConfigKey] is present and
non-empty before assigning it into cm.Data[aws.ProviderConfigKey]; if it's
missing or empty, return an error (fail fast) instead of writing an empty
aws.conf. Update the sync logic around cm and reference (the block that
currently does cm.Data[aws.ProviderConfigKey] =
reference.Data[aws.ProviderConfigKey]) to validate the value, log/return a
descriptive error when absent, and only set cm.Data when the provider config is
valid.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository YAML (base), Central YAML (inherited)
Review profile: CHILL
Plan: Pro Plus
Run ID: 34913917-4951-4a83-8093-81ebed65cba8
📒 Files selected for processing (5)
control-plane-operator/controllers/hostedcontrolplane/cloud/aws/providerconfig.gocontrol-plane-operator/hostedclusterconfigoperator/controllers/resources/reconcile_cloud_config_test.gocontrol-plane-operator/hostedclusterconfigoperator/controllers/resources/resources.gosupport/globalconfig/infrastructure.gosupport/globalconfig/infrastructure_test.go
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #8280 +/- ##
==========================================
+ Coverage 41.80% 41.82% +0.01%
==========================================
Files 759 759
Lines 94067 94105 +38
==========================================
+ Hits 39323 39356 +33
- Misses 51993 51997 +4
- Partials 2751 2752 +1
Flags with carried forward coverage won't be shown. Click here to find out more. 🚀 New features to boost your workflow:
|
hypershift-jira-solve-ci
Bot
force-pushed
the
fix-CNTRLPLANE-625-v2
branch
from
7c4531d to
55275ba
Compare
|
Re: review PRR_kwDOE7ekcc72sY6X Thanks for the review. The actionable finding about validating AI-assisted response via Claude Code |
|
Re: #8280 (comment) Thanks for the walkthrough summary — it accurately describes the changes. No action needed. AI-assisted response via Claude Code |
csrwng
left a comment
csrwng
left a comment
There was a problem hiding this comment.
This change is ok, but it doesn't enable the use of custom trust bundles for the entire control plane. Maybe handling the rest of the control plane components (capi provider, control-plane-operator, etc) can be done under a separate story.
|
|
||
| switch platformType { | ||
| case hyperv1.AWSPlatform: | ||
| infra.Spec.CloudConfig.Name = "cloud-provider-config" |
There was a problem hiding this comment.
This should use a constant. Ideally the same constant used by resources.go
There was a problem hiding this comment.
Done. Defined CloudProviderCMName constant in the globalconfig package and updated both infrastructure.go and resources.go to use it. The resources package now references globalconfig.CloudProviderCMName instead of its own duplicate literal. Also updated the infrastructure tests to use the constant.
AI-assisted response via Claude Code
There was a problem hiding this comment.
Done. Extracted a CloudProviderConfigName constant to the support/globalconfig package and updated both infrastructure.go and resources.go to use it. The CloudProviderCMName in resources.go now references globalconfig.CloudProviderConfigName instead of a local string literal.
AI-assisted response via Claude Code
| } | ||
|
|
||
| var caBundle string | ||
| if hcp.Spec.AdditionalTrustBundle != nil { |
There was a problem hiding this comment.
We should use the aggregate of of spec.AdditionalTrustBundle and .spec.configuration.Proxy.TrustedCA
There was a problem hiding this comment.
Done. Switched to using the aggregated trusted-ca-bundle-managed ConfigMap (via cpomanifests.TrustedCABundleConfigMap) which the HCP controller already populates by combining both spec.AdditionalTrustBundle and spec.Configuration.Proxy.TrustedCA. The condition now triggers on either source being set. Added a test case for the proxy TrustedCA path.
AI-assisted response via Claude Code
There was a problem hiding this comment.
Done. Switched from UserCAConfigMap (which only contains AdditionalTrustBundle) to TrustedCABundleConfigMap (trusted-ca-bundle-managed), which already contains the aggregate of both spec.AdditionalTrustBundle and .spec.configuration.Proxy.TrustedCA — built by the CPO's reconcileManagedTrustedCABundle. Also updated the condition to check for either source being set, and added a test case for proxy-only TrustedCA.
AI-assisted response via Claude Code
|
Re: review PRR_kwDOE7ekcc73B2Hd Agreed — this PR focuses on the cloud-provider-config for the guest cluster's AWS SDK usage. Extending custom trust bundle support to the remaining control plane components (CAPI provider, control-plane-operator, etc.) should be tracked under a separate story to keep the scope manageable. AI-assisted response via Claude Code |
|
Re: review 4144456157 Agreed — this PR focuses on the cloud-provider-config use case for AWS. Extending custom trust bundle support to other control plane components (CAPI provider, control-plane-operator, etc.) can be tracked and handled under a separate story. AI-assisted response via Claude Code |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In
`@control-plane-operator/hostedclusterconfigoperator/controllers/resources/resources.go`:
- Around line 2423-2443: The reconcile can stall because when
cpomanifests.TrustedCABundleConfigMap(hcp.Namespace) or the AWS provider source
(cpomanifests.AWSProviderConfig) is expected but not present the controller
neither watches those management-cluster ConfigMaps nor requeues for retry;
update the controller to either (A) add watches for those management-cluster
ConfigMap sources in SetupWithManager (watch ConfigMap resources filtered by
name/namespace for the TrustedCABundle and aws-cloud-config so guest reconciles
are triggered when they appear/change) or (B) when cpClient.Get(...) returns
IsNotFound for the managed trusted CA (the branch inside the reconcile where you
currently log and skip), return a requeue result (e.g.,
ctrl.Result{RequeueAfter: <reasonable backoff>}) so the reconcile will retry
until the bundle appears; reference cpomanifests.TrustedCABundleConfigMap,
cpomanifests.AWSProviderConfig, aws.ProviderConfigKey, SetupWithManager and the
reconcile path that calls r.cpClient.Get.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository YAML (base), Central YAML (inherited)
Review profile: CHILL
Plan: Pro Plus
Run ID: e8d0cfdf-1e1d-470d-8230-bd36caa5c574
📒 Files selected for processing (4)
control-plane-operator/hostedclusterconfigoperator/controllers/resources/reconcile_cloud_config_test.gocontrol-plane-operator/hostedclusterconfigoperator/controllers/resources/resources.gosupport/globalconfig/infrastructure.gosupport/globalconfig/infrastructure_test.go
🚧 Files skipped from review as they are similar to previous changes (2)
- support/globalconfig/infrastructure_test.go
- control-plane-operator/hostedclusterconfigoperator/controllers/resources/reconcile_cloud_config_test.go
| reference := cpomanifests.AWSProviderConfig(hcp.Namespace) | ||
| if err := r.cpClient.Get(ctx, client.ObjectKeyFromObject(reference), reference); err != nil { | ||
| return fmt.Errorf("failed to fetch %s/%s configmap from management cluster: %w", reference.Namespace, reference.Name, err) | ||
| } | ||
| providerConfig, ok := reference.Data[aws.ProviderConfigKey] | ||
| if !ok || strings.TrimSpace(providerConfig) == "" { | ||
| return fmt.Errorf("source configmap %s/%s is missing required key %q", reference.Namespace, reference.Name, aws.ProviderConfigKey) | ||
| } | ||
|
|
||
| // Use the aggregated trust bundle that combines spec.AdditionalTrustBundle | ||
| // and spec.Configuration.Proxy.TrustedCA, managed by the HCP controller. | ||
| var caBundle string | ||
| if hcp.Spec.AdditionalTrustBundle != nil || | ||
| (hcp.Spec.Configuration != nil && hcp.Spec.Configuration.Proxy != nil && hcp.Spec.Configuration.Proxy.TrustedCA.Name != "") { | ||
| managedTrustBundle := cpomanifests.TrustedCABundleConfigMap(hcp.Namespace) | ||
| if err := r.cpClient.Get(ctx, client.ObjectKeyFromObject(managedTrustBundle), managedTrustBundle); err != nil { | ||
| if !apierrors.IsNotFound(err) { | ||
| return fmt.Errorf("failed to fetch managed trusted CA bundle from management cluster: %w", err) | ||
| } | ||
| ctrl.LoggerFrom(ctx).Info("managed trusted CA bundle ConfigMap not found, skipping CA bundle sync", "configmap", client.ObjectKeyFromObject(managedTrustBundle)) | ||
| } else { |
There was a problem hiding this comment.
This sync can get stuck after bootstrap.
When a trust bundle is configured, Line 2438 logs and skips if trusted-ca-bundle-managed is absent. But this controller does not watch the management-cluster trusted-ca-bundle-managed or aws-cloud-config ConfigMaps, so the guest cloud-provider-config may never pick up the CA bundle once it appears, or later source updates, until some unrelated reconcile happens. Please add CP-cluster watches for those source ConfigMaps, or explicitly requeue while the managed bundle is expected but missing.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In
`@control-plane-operator/hostedclusterconfigoperator/controllers/resources/resources.go`
around lines 2423 - 2443, The reconcile can stall because when
cpomanifests.TrustedCABundleConfigMap(hcp.Namespace) or the AWS provider source
(cpomanifests.AWSProviderConfig) is expected but not present the controller
neither watches those management-cluster ConfigMaps nor requeues for retry;
update the controller to either (A) add watches for those management-cluster
ConfigMap sources in SetupWithManager (watch ConfigMap resources filtered by
name/namespace for the TrustedCABundle and aws-cloud-config so guest reconciles
are triggered when they appear/change) or (B) when cpClient.Get(...) returns
IsNotFound for the managed trusted CA (the branch inside the reconcile where you
currently log and skip), return a requeue result (e.g.,
ctrl.Result{RequeueAfter: <reasonable backoff>}) so the reconcile will retry
until the bundle appears; reference cpomanifests.TrustedCABundleConfigMap,
cpomanifests.AWSProviderConfig, aws.ProviderConfigKey, SetupWithManager and the
reconcile path that calls r.cpClient.Get.
There was a problem hiding this comment.
The concern is valid in the abstract, but in practice this controller is not at risk of stalling for this case. Here's why:
-
HCP is watched (line 288): The HCP controller creates the
trusted-ca-bundle-managedConfigMap during HCP reconciliation, and HCP status updates are frequent — any HCP object change triggers an HCCO reconcile. -
Broad guest-cluster watches (lines 245-276): The controller watches 20+ resource types on the guest cluster (ConfigMaps, Secrets, Services, etc.), so reconciles fire very frequently during and after bootstrap.
-
Intentional graceful degradation: The "log and skip" pattern at line 2442 is deliberate — the cloud-provider-config should be created promptly even if the optional CA bundle isn't available yet. The next reconcile (triggered by HCP or guest-cluster changes) picks it up. Returning an error or requeueing would block the entire reconcile for a non-critical optional field.
-
Consistent with existing patterns: Other management-cluster resources like the
aws-cloud-configConfigMap (line 2423), pull secrets (line 366), and numerous othercpClient.Getcalls throughout this controller also lack explicit CP-cluster watches — they all rely on HCP or guest-cluster changes to trigger reconciles. Adding watches only for these two ConfigMaps would be inconsistent.
The aws-cloud-config case at line 2423 does return a hard error (which causes controller-runtime to requeue), but that's because the provider config is required — the cloud config cannot be built without it. The trust bundle is optional additional trust, and the ConfigMap is still created successfully without it.
AI-assisted response via Claude Code
There was a problem hiding this comment.
Skipped: comment is from another GitHub bot.
There was a problem hiding this comment.
This concern is not actionable for this controller. The HCP watch at line 288 ensures any HostedControlPlane change triggers a full reconcile — and HCP status updates are frequent during and after bootstrap. This is the same mechanism that drives every other cpClient.Get call in this controller (pull secrets, root CAs, OIDC secrets, etc.), none of which have dedicated ConfigMap watches either.
The "log and skip" pattern here is intentional: the cloud-provider-config ConfigMap should be created promptly with the provider config even if the optional CA bundle isn't available yet. The next HCP- or guest-cluster-triggered reconcile picks it up. Returning an error would block the entire reconcile for an optional field.
AI-assisted response via Claude Code
There was a problem hiding this comment.
Skipped: comment is from another GitHub bot.
There was a problem hiding this comment.
Only repository collaborators, contributors, or members can run CodeRabbit commands.
There was a problem hiding this comment.
Confirming the previous responses are correct — this is not a practical concern.
The HCCO resources controller watches HostedControlPlane (line 198: For(&hyperv1.HostedControlPlane{})), and the HCP controller is what creates the trusted-ca-bundle-managed ConfigMap. HCP status updates are frequent during and after bootstrap, which triggers this controller to re-reconcile and pick up the ConfigMap once it exists. This is the same pattern used by all ~20+ cpClient.Get calls in this controller (pull secrets, certs, cloud configs, etc.) — none have dedicated watches; they all rely on the HCP watch for re-reconciliation.
AI-assisted response via Claude Code
There was a problem hiding this comment.
Skipped: comment is from another GitHub bot.
There was a problem hiding this comment.
Reviewed. The concern is not actionable — the controller already watches HostedControlPlane (line 288) on the CP cluster, so any HCP change (including when the HCP controller creates the managed trust bundle ConfigMap) triggers a full reconcile. The "log and skip" pattern here is intentional graceful degradation for an optional field, consistent with how all other cpClient.Get calls in this controller work. No watches or requeue needed.
AI-assisted response via Claude Code
There was a problem hiding this comment.
Skipped: comment is from another GitHub bot.
|
Re: #8280 (review) Thanks for the review. The one actionable inline comment about potential stalling of the trust bundle sync has been addressed with an inline reply — the current "log and skip" pattern is intentional graceful degradation, consistent with the controller's existing architecture. See the inline thread for detailed rationale. AI-assisted response via Claude Code |
|
Re: #8280 (review) Acknowledged. The single actionable comment about the reconcile potentially stalling has been addressed in the inline thread. In short: the concern is valid in the abstract, but not a practical risk here. The AI-assisted response via Claude Code |
The comment analyzer flags review bodies and review threads independently. When an approved bot (e.g. CodeRabbit) submits a review with both a body and inline comments, both get flagged as separate needs_attention items. Claude addresses each independently, producing duplicate responses. Observed on openshift/hypershift#8280: CodeRabbit review #4146142149 had a body ("Actionable comments posted: 1") and one inline comment about trust bundle sync stalling. The analyzer returned both as separate items. Claude posted an inline reply to the thread at 11:04:10Z, then two issue comments at 11:04:20Z and 11:06:19Z — both "Re: #pullrequestreview-4146142149" with overlapping content. Root cause: analyze_review_bodies uses per-comment reply matching (checking if any bot comment references the review ID/URL). Since no bot comment had yet referenced review 4146142149, it was flagged. Meanwhile, analyze_review_threads independently flagged the same review's inline thread. Both items entered the needs_attention list. Fix: add comments { totalCount } to the reviews GraphQL query and skip approved bot review bodies when inline comments exist. Bot review bodies are machine-generated summaries of their inline comments (already handled by analyze_review_threads). Human review bodies are always kept since they often contain distinct feedback. Verified against PR #8280: - CodeRabbit review 4146142149: SKIPPED (approved_bot, inline_count=1) - CodeRabbit review 4138831511: SKIPPED (approved_bot, inline_count=1) - csrwng review 4144456157: KEPT (human, inline_count=2) Co-authored-by: Claude Opus 4.6 <[email protected]>
There was a problem hiding this comment.
🧹 Nitpick comments (2)
control-plane-operator/hostedclusterconfigoperator/controllers/resources/reconcile_cloud_config_test.go (2)
301-305: Make error-path assertions specific to avoid false positives.The current
expectErrorbranch only checks that some error occurred. A different unintended failure would still pass. Please assert error type/message per case.Proposed hardening
type testCase struct { name string hcp *hyperv1.HostedControlPlane cpObjects []client.Object guestObjects []client.Object expectError bool + errContains string verify func(g Gomega, guestClient client.Client) } // ... { name: "When aws-cloud-config ConfigMap is missing, it should return an error", // ... cpObjects: []client.Object{}, expectError: true, + errContains: "not found", }, // ... { name: "When aws-cloud-config ConfigMap is missing the provider config key, it should return an error", // ... expectError: true, + errContains: aws.ProviderConfigKey, }, // ... err := r.reconcileCloudConfig(context.Background(), tc.hcp) if tc.expectError { g.Expect(err).To(HaveOccurred()) + if tc.errContains != "" { + g.Expect(err.Error()).To(ContainSubstring(tc.errContains)) + } return }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@control-plane-operator/hostedclusterconfigoperator/controllers/resources/reconcile_cloud_config_test.go` around lines 301 - 305, The test's error branch only checks for any error; make it assert specific error types/messages to avoid false positives by adding an expected error indicator on each test case (e.g., tc.expectedErr or tc.expectedErrMsg) and then change the branch that calls r.reconcileCloudConfig to assert both presence and content/type: when tc.expectError is true assert the error occurred and that err.Error() contains tc.expectedErrMsg (or use errors.Is/As against tc.expectedErr for typed errors) instead of only HaveOccurred, referencing the test case variable tc and the reconcileCloudConfig(...) call to locate where to add the stricter assertions.
202-230: Add parity coverage for missing managed trust bundle withProxy.TrustedCA.You already test graceful fallback when
AdditionalTrustBundleis set and the managed trust bundle ConfigMap is missing. Please add the equivalent case forSpec.Configuration.Proxy.TrustedCAto lock in behavior for both triggers.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@control-plane-operator/hostedclusterconfigoperator/controllers/resources/reconcile_cloud_config_test.go` around lines 202 - 230, Add a parallel test case to the existing one that covers the scenario where Spec.Configuration.Proxy.TrustedCA is set but the managed trust bundle ConfigMap is missing: create a HostedControlPlane with Spec.Configuration.Proxy.TrustedCA pointing to a LocalObjectReference (instead of AdditionalTrustBundle), include fakeAWSCloudConfig() in cpObjects, and in the verify closure fetch the ConfigMap by CloudProviderCMName and assert cm.Data has aws.ProviderConfigKey with the base config and does NOT have aws.CABundleKey; reuse the same structure and assertions as the AdditionalTrustBundle test but target HostedControlPlane.Spec.Configuration.Proxy.TrustedCA to ensure parity.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In
`@control-plane-operator/hostedclusterconfigoperator/controllers/resources/reconcile_cloud_config_test.go`:
- Around line 301-305: The test's error branch only checks for any error; make
it assert specific error types/messages to avoid false positives by adding an
expected error indicator on each test case (e.g., tc.expectedErr or
tc.expectedErrMsg) and then change the branch that calls r.reconcileCloudConfig
to assert both presence and content/type: when tc.expectError is true assert the
error occurred and that err.Error() contains tc.expectedErrMsg (or use
errors.Is/As against tc.expectedErr for typed errors) instead of only
HaveOccurred, referencing the test case variable tc and the
reconcileCloudConfig(...) call to locate where to add the stricter assertions.
- Around line 202-230: Add a parallel test case to the existing one that covers
the scenario where Spec.Configuration.Proxy.TrustedCA is set but the managed
trust bundle ConfigMap is missing: create a HostedControlPlane with
Spec.Configuration.Proxy.TrustedCA pointing to a LocalObjectReference (instead
of AdditionalTrustBundle), include fakeAWSCloudConfig() in cpObjects, and in the
verify closure fetch the ConfigMap by CloudProviderCMName and assert cm.Data has
aws.ProviderConfigKey with the base config and does NOT have aws.CABundleKey;
reuse the same structure and assertions as the AdditionalTrustBundle test but
target HostedControlPlane.Spec.Configuration.Proxy.TrustedCA to ensure parity.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository YAML (base), Central YAML (inherited)
Review profile: CHILL
Plan: Pro Plus
Run ID: a8eaacd9-0e27-4e9b-9f37-4a9f557c2411
📒 Files selected for processing (1)
control-plane-operator/hostedclusterconfigoperator/controllers/resources/reconcile_cloud_config_test.go
|
Re: #8280 (review) Done. Addressed both nitpick suggestions:
All 9 test cases pass. AI-assisted response via Claude Code |
There was a problem hiding this comment.
🧹 Nitpick comments (2)
control-plane-operator/hostedclusterconfigoperator/controllers/resources/reconcile_cloud_config_test.go (2)
233-255: Add a whitespace-only provider-config test case for full branch coverage.Line 234 currently validates a missing
aws.ProviderConfigKey, but the reconciler also rejects whitespace-only values. Adding that case will lock in thestrings.TrimSpace(...) == ""behavior.➕ Proposed test case
{ name: "When aws-cloud-config ConfigMap is missing the provider config key, it should return an error", hcp: &hyperv1.HostedControlPlane{ @@ expectError: true, errContains: aws.ProviderConfigKey, }, + { + name: "When aws-cloud-config ConfigMap has whitespace-only provider config, it should return an error", + hcp: &hyperv1.HostedControlPlane{ + ObjectMeta: metav1.ObjectMeta{ + Name: "test", + Namespace: hcpNamespace, + }, + Spec: hyperv1.HostedControlPlaneSpec{ + Platform: hyperv1.PlatformSpec{ + Type: hyperv1.AWSPlatform, + }, + }, + }, + cpObjects: []client.Object{ + func() *corev1.ConfigMap { + cm := cpomanifests.AWSProviderConfig(hcpNamespace) + cm.Data = map[string]string{ + aws.ProviderConfigKey: " \n\t", + } + return cm + }(), + }, + expectError: true, + errContains: aws.ProviderConfigKey, + },🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@control-plane-operator/hostedclusterconfigoperator/controllers/resources/reconcile_cloud_config_test.go` around lines 233 - 255, Add a new test case in reconcile_cloud_config_test.go mirroring the existing missing-key case but instead set the aws provider config key to a whitespace-only value (e.g., cm.Data[aws.ProviderConfigKey] = " "), keep expectError: true and errContains: aws.ProviderConfigKey so the test exercises the strings.TrimSpace(... ) == "" branch; place it alongside the current case so it covers the whitespace-only rejection path.
73-319: Consider extracting a small assertion helper to reduce repeated verify closures.The repeated
guestClient.Get(...)+ provider-key assertions across multiple cases add maintenance overhead; a helper would make future case additions simpler and less error-prone.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@control-plane-operator/hostedclusterconfigoperator/controllers/resources/reconcile_cloud_config_test.go` around lines 73 - 319, Extract a small test helper (e.g., assertCloudProviderConfig or verifyCloudProviderConfig) that wraps the repeated guestClient.Get call and the assertions against aws.ProviderConfigKey and aws.CABundleKey (and accepts parameters like Gomega, client.Client, expected provider config value, and optional expected CA bundle or a flag indicating absence) and replace the inline verify closures in tests that use fakeAWSCloudConfig() and fakeManagedTrustBundle() with calls to this helper; update test cases that expect no CA bundle to call the helper with an empty/absent CA parameter and cases that expect a bundle to pass the exact string, keeping references to guestClient.Get, aws.ProviderConfigKey, aws.CABundleKey, fakeAWSCloudConfig, and fakeManagedTrustBundle to locate where to change.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In
`@control-plane-operator/hostedclusterconfigoperator/controllers/resources/reconcile_cloud_config_test.go`:
- Around line 233-255: Add a new test case in reconcile_cloud_config_test.go
mirroring the existing missing-key case but instead set the aws provider config
key to a whitespace-only value (e.g., cm.Data[aws.ProviderConfigKey] = " "),
keep expectError: true and errContains: aws.ProviderConfigKey so the test
exercises the strings.TrimSpace(... ) == "" branch; place it alongside the
current case so it covers the whitespace-only rejection path.
- Around line 73-319: Extract a small test helper (e.g.,
assertCloudProviderConfig or verifyCloudProviderConfig) that wraps the repeated
guestClient.Get call and the assertions against aws.ProviderConfigKey and
aws.CABundleKey (and accepts parameters like Gomega, client.Client, expected
provider config value, and optional expected CA bundle or a flag indicating
absence) and replace the inline verify closures in tests that use
fakeAWSCloudConfig() and fakeManagedTrustBundle() with calls to this helper;
update test cases that expect no CA bundle to call the helper with an
empty/absent CA parameter and cases that expect a bundle to pass the exact
string, keeping references to guestClient.Get, aws.ProviderConfigKey,
aws.CABundleKey, fakeAWSCloudConfig, and fakeManagedTrustBundle to locate where
to change.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository YAML (base), Central YAML (inherited)
Review profile: CHILL
Plan: Pro Plus
Run ID: 71bd9b3b-ea57-4f82-ab8b-5dff896f5cc7
📒 Files selected for processing (1)
control-plane-operator/hostedclusterconfigoperator/controllers/resources/reconcile_cloud_config_test.go
|
Re: #8280 (review) Thanks for the nitpick suggestions!
AI-assisted response via Claude Code |
hypershift-jira-solve-ci
Bot
force-pushed
the
fix-CNTRLPLANE-625-v2
branch
from
dcd520b to
8f48ddb
Compare
…hift#78134) The comment analyzer flags review bodies and review threads independently. When an approved bot (e.g. CodeRabbit) submits a review with both a body and inline comments, both get flagged as separate needs_attention items. Claude addresses each independently, producing duplicate responses. Observed on openshift/hypershift#8280: CodeRabbit review #4146142149 had a body ("Actionable comments posted: 1") and one inline comment about trust bundle sync stalling. The analyzer returned both as separate items. Claude posted an inline reply to the thread at 11:04:10Z, then two issue comments at 11:04:20Z and 11:06:19Z — both "Re: #pullrequestreview-4146142149" with overlapping content. Root cause: analyze_review_bodies uses per-comment reply matching (checking if any bot comment references the review ID/URL). Since no bot comment had yet referenced review 4146142149, it was flagged. Meanwhile, analyze_review_threads independently flagged the same review's inline thread. Both items entered the needs_attention list. Fix: add comments { totalCount } to the reviews GraphQL query and skip approved bot review bodies when inline comments exist. Bot review bodies are machine-generated summaries of their inline comments (already handled by analyze_review_threads). Human review bodies are always kept since they often contain distinct feedback. Verified against PR openshift#8280: - CodeRabbit review 4146142149: SKIPPED (approved_bot, inline_count=1) - CodeRabbit review 4138831511: SKIPPED (approved_bot, inline_count=1) - csrwng review 4144456157: KEPT (human, inline_count=2) Co-authored-by: Claude Opus 4.6 <[email protected]>
…hift#78134) The comment analyzer flags review bodies and review threads independently. When an approved bot (e.g. CodeRabbit) submits a review with both a body and inline comments, both get flagged as separate needs_attention items. Claude addresses each independently, producing duplicate responses. Observed on openshift/hypershift#8280: CodeRabbit review #4146142149 had a body ("Actionable comments posted: 1") and one inline comment about trust bundle sync stalling. The analyzer returned both as separate items. Claude posted an inline reply to the thread at 11:04:10Z, then two issue comments at 11:04:20Z and 11:06:19Z — both "Re: #pullrequestreview-4146142149" with overlapping content. Root cause: analyze_review_bodies uses per-comment reply matching (checking if any bot comment references the review ID/URL). Since no bot comment had yet referenced review 4146142149, it was flagged. Meanwhile, analyze_review_threads independently flagged the same review's inline thread. Both items entered the needs_attention list. Fix: add comments { totalCount } to the reviews GraphQL query and skip approved bot review bodies when inline comments exist. Bot review bodies are machine-generated summaries of their inline comments (already handled by analyze_review_threads). Human review bodies are always kept since they often contain distinct feedback. Verified against PR openshift#8280: - CodeRabbit review 4146142149: SKIPPED (approved_bot, inline_count=1) - CodeRabbit review 4138831511: SKIPPED (approved_bot, inline_count=1) - csrwng review 4144456157: KEPT (human, inline_count=2) Co-authored-by: Claude Opus 4.6 <[email protected]>
…hift#78134) The comment analyzer flags review bodies and review threads independently. When an approved bot (e.g. CodeRabbit) submits a review with both a body and inline comments, both get flagged as separate needs_attention items. Claude addresses each independently, producing duplicate responses. Observed on openshift/hypershift#8280: CodeRabbit review #4146142149 had a body ("Actionable comments posted: 1") and one inline comment about trust bundle sync stalling. The analyzer returned both as separate items. Claude posted an inline reply to the thread at 11:04:10Z, then two issue comments at 11:04:20Z and 11:06:19Z — both "Re: #pullrequestreview-4146142149" with overlapping content. Root cause: analyze_review_bodies uses per-comment reply matching (checking if any bot comment references the review ID/URL). Since no bot comment had yet referenced review 4146142149, it was flagged. Meanwhile, analyze_review_threads independently flagged the same review's inline thread. Both items entered the needs_attention list. Fix: add comments { totalCount } to the reviews GraphQL query and skip approved bot review bodies when inline comments exist. Bot review bodies are machine-generated summaries of their inline comments (already handled by analyze_review_threads). Human review bodies are always kept since they often contain distinct feedback. Verified against PR openshift#8280: - CodeRabbit review 4146142149: SKIPPED (approved_bot, inline_count=1) - CodeRabbit review 4138831511: SKIPPED (approved_bot, inline_count=1) - csrwng review 4144456157: KEPT (human, inline_count=2) Co-authored-by: Claude Opus 4.6 <[email protected]>
|
Stale PRs are closed after 21d of inactivity. If this PR is still relevant, comment to refresh it or remove the stale label. If this PR is safe to close now please do so with /lifecycle stale |
openshift-ci
Bot
added
the
lifecycle/stale
|
/remove-lifecycle stale |
openshift-ci
Bot
removed
the
lifecycle/stale
bryan-cox
left a comment
bryan-cox
left a comment
There was a problem hiding this comment.
Code Review: CNTRLPLANE-625 — Custom Trust Bundle for AWS API Endpoints
+448 / -3 across 5 files
The PR syncs an additional trust bundle (custom CA certificates) into the cloud-provider-config ConfigMap in the guest cluster for AWS, and sets infra.Spec.CloudConfig on the Infrastructure resource so guest operators discover the cloud config through the standard mechanism.
Blocking Findings
1. Unconditional infra.Spec.CloudConfig for all AWS clusters (support/globalconfig/infrastructure.go:62-63)
Sets CloudConfig on every AWS HostedCluster, not just those with a trust bundle. This is a behavioral change for all existing AWS clusters — guest operators that previously saw no CloudConfig will now discover one and may change their behavior. Needs evidence this is safe unconditionally, or should be gated on trust bundle being configured.
2. cloud-provider-config ConfigMap created unconditionally (resources.go:2419-2465)
Same concern — the AWS case in reconcileCloudConfig always creates the ConfigMap in the guest cluster regardless of whether a trust bundle exists. Introduces a new resource into every AWS guest cluster.
Suggestions
3. Missing kube-cloud-config in openshift-config-managed — The OpenStack path creates this for cloud-network-config-controller, which the PR description cites as a consumer. If that controller reads from openshift-config-managed/kube-cloud-config rather than openshift-config/cloud-provider-config, the trust bundle may not reach its target.
4. Import direction anti-pattern — support/globalconfig imports from control-plane-operator/controllers/hostedcontrolplane/cloud/aws. The constants (ProviderConfigKey, CABundleKey) should live in support/ to avoid deepening the dependency.
5. Duplicated CABundleKey — "ca-bundle.pem" is defined identically for both AWS and OpenStack. Should be a shared constant.
6. Squash commits — 6 iterative commits for one logical change; squash to 1-2 before merge.
Operational Concerns
- Fleet-wide upgrade impact: Every AWS HostedCluster gets a new ConfigMap + Infrastructure spec change on upgrade. Must pass
e2e-aws-upgrade-hypershift-operator. - No human approvals: csrwng commented but did not approve. No
lgtm/approvedlabels. - E2E jobs pending: Critical AWS E2E tests haven't run yet.
Positives
- Good use of
CreateOrUpdate, graceful handling of missing trust bundle, and correct use of the aggregatedtrusted-ca-bundle-managedConfigMap (per csrwng's feedback). - Strong test coverage — 9 test cases covering happy paths, error paths, cleanup, and both trust bundle sources.
bryan-cox
left a comment
bryan-cox
left a comment
There was a problem hiding this comment.
Code Review: CNTRLPLANE-625 — Custom Trust Bundle for AWS API Endpoints
Overall the approach is sound and follows existing platform patterns. The test coverage is strong (9 cases). Main concern is the unconditional behavioral change for all AWS clusters. See inline comments.
| @@ -57,6 +64,8 @@ func ReconcileInfrastructure(infra *configv1.Infrastructure, hcp *hyperv1.Hosted | |||
|
|
|||
| switch platformType { | |||
| case hyperv1.AWSPlatform: | |||
There was a problem hiding this comment.
[blocking] Unconditional infra.Spec.CloudConfig for all AWS clusters.
This sets CloudConfig on every AWS HostedCluster, not just those with a trust bundle. This is a behavioral change for all existing AWS clusters — guest operators that previously saw no CloudConfig will now discover one and may change their behavior (e.g., reading aws.conf from the ConfigMap instead of relying on their own defaults).
Also note an inconsistency: Azure sets CloudConfig.Name without .Key, while this PR sets both .Name and .Key. Is Azure's omission of .Key intentional?
Recommendation: Consider making the CloudConfig setting conditional on the trust bundle being configured, or provide evidence that unconditionally setting it is safe for all existing AWS guest operators. At minimum, this needs E2E validation on a cluster without any trust bundle configured to confirm no regressions.
There was a problem hiding this comment.
This is intentionally unconditional, and here's the justification:
1. Aligns HyperShift with standalone OpenShift. In standalone OCP on AWS, the Infrastructure resource always has CloudConfig set and the cloud-provider-config ConfigMap always exists in openshift-config. Before this PR, AWS HyperShift was the outlier — not having these resources meant guest operators behaved differently from standalone, which is the opposite of what HyperShift aims for.
2. Consistent with Azure and OpenStack in this codebase. Azure already sets CloudConfig.Name = "cloud.conf" unconditionally (line 90), and OpenStack sets both .Name and .Key unconditionally (lines 110-111). This PR makes AWS follow the same pattern.
3. Safe for guest operators. The aws-cloud-config ConfigMap already exists in the management cluster (created by the HCP controller). Its content (aws.conf) contains the base AWS cloud configuration (VPC, zone, subnet) that guest operators would otherwise derive from defaults. Surfacing it via the standard infra.Spec.CloudConfig mechanism gives guest operators the same configuration they'd compute on their own — it doesn't change their behavior, it just makes the config explicit.
4. Azure .Key omission. You're right that Azure sets .Name without .Key. Looking at Azure's guest ConfigMap creation (line 2475), the data key is "config", but CloudConfig.Name is "cloud.conf" which is actually the ConfigMap name not the data key — so Azure's CloudConfig.Key omission is a pre-existing gap. For AWS, setting both .Name and .Key is the correct approach since the ConfigMap name (cloud-provider-config) differs from the data key (aws.conf).
E2E validation on a cluster without trust bundles is a fair ask — I'll ensure the standard AWS E2E suite passes to confirm no regressions.
AI-assisted response via Claude Code
| func (r *reconciler) reconcileCloudConfig(ctx context.Context, hcp *hyperv1.HostedControlPlane) error { | ||
|
|
||
| switch hcp.Spec.Platform.Type { | ||
| case hyperv1.AWSPlatform: |
There was a problem hiding this comment.
[blocking] cloud-provider-config ConfigMap is created unconditionally for AWS even without trust bundles.
The AWS case always fetches aws-cloud-config from the management cluster and creates/updates cloud-provider-config in the guest cluster on every reconcile, for every AWS cluster, regardless of whether a trust bundle is configured. This introduces a new resource into every AWS guest cluster that wasn't there before.
Combined with the unconditional infra.Spec.CloudConfig in infrastructure.go, guest operators will now discover and attempt to use this config on all AWS clusters.
Recommendation: Clarify whether this is intentionally unconditional (which may be the right design for consistency with other platforms) and validate with E2E tests on standard AWS clusters.
There was a problem hiding this comment.
This is the same design decision as the CloudConfig setting above — intentionally unconditional.
The cloud-provider-config ConfigMap creation is the guest-cluster counterpart of setting infra.Spec.CloudConfig. Without the ConfigMap, the CloudConfig reference would point to nothing, which would be worse than not setting CloudConfig at all.
In standalone OCP on AWS, this ConfigMap always exists. The content comes from the aws-cloud-config ConfigMap that the HCP controller already creates in the management cluster for every AWS HostedCluster (not just those with trust bundles). Syncing it to the guest cluster makes HyperShift consistent with standalone behavior.
The trust bundle is the additive feature — the base provider config sync is the prerequisite that makes the standard cloud config mechanism work. Without it, there's no standard path for guest operators to discover cloud configuration, which is why OpenStack and Azure already create this ConfigMap unconditionally.
AI-assisted response via Claude Code
| return nil | ||
| }); err != nil { | ||
| return fmt.Errorf("failed to reconcile the %s/%s configmap: %w", cm.Namespace, cm.Name, err) | ||
| } |
There was a problem hiding this comment.
[suggestion] Missing kube-cloud-config ConfigMap in openshift-config-managed for AWS.
The OpenStack implementation creates a kube-cloud-config ConfigMap in openshift-config-managed (see the OpenStack case further down). The comment there explains it's needed so CNO can create the kube-cloud-config ConfigMap for cloud-network-config-controller.
The PR description specifically mentions cloud-network-config-controller as a consumer that needs the trust bundle, but the PR does not create the kube-cloud-config ConfigMap in openshift-config-managed for AWS. If cloud-network-config-controller on AWS reads from openshift-config-managed/kube-cloud-config rather than openshift-config/cloud-provider-config, the trust bundle may not actually reach the intended consumer.
Recommendation: Investigate whether cloud-network-config-controller on AWS reads from openshift-config/cloud-provider-config directly or from openshift-config-managed/kube-cloud-config. If the latter, the PR needs to create that ConfigMap too.
There was a problem hiding this comment.
Good catch. You're right that the OpenStack path creates kube-cloud-config in openshift-config-managed specifically because CNO reads from there to create the ConfigMap for cloud-network-config-controller.
Looking at the comment in the OpenStack case (lines 2500-2505), this is explicitly because the cloud-controller-manager-operator's config-sync controller doesn't run in the guest cluster in HyperShift — so HCCO has to replicate what config-sync would do.
The same gap applies to AWS: if CNCC on AWS reads from openshift-config-managed/kube-cloud-config (via CNO's sync), the trust bundle won't reach it through openshift-config/cloud-provider-config alone.
I'll investigate whether AWS cloud-network-config-controller reads from openshift-config-managed/kube-cloud-config or directly from openshift-config/cloud-provider-config, and add the kube-cloud-config ConfigMap creation if needed. This is a valuable finding.
AI-assisted response via Claude Code
| "strings" | ||
|
|
||
| hyperv1 "github.com/openshift/hypershift/api/hypershift/v1beta1" | ||
| "github.com/openshift/hypershift/control-plane-operator/controllers/hostedcontrolplane/cloud/aws" |
There was a problem hiding this comment.
[suggestion] Import direction anti-pattern: support/globalconfig importing from control-plane-operator/.
The support/ package is a general-purpose library imported by many packages. Having it import from control-plane-operator/controllers/hostedcontrolplane/cloud/aws creates a dependency from a lower-level package to a higher-level one. While there is precedent (the existing openstack import), this deepens the anti-pattern.
The ProviderConfigKey and CABundleKey constants are simple strings. They'd be more naturally placed in support/globalconfig/ or a shared support/cloudconfig package.
Recommendation: Move the AWS constants to support/globalconfig (or shared package) to avoid deepening the import dependency. Same cleanup opportunity exists for the OpenStack constants.
There was a problem hiding this comment.
Done. Moved the shared constants to `support/globalconfig/infrastructure.go`:
- `AWSProviderConfigKey = "aws.conf"`
- `OpenStackCloudConfigKey = "cloud.conf"`
- `CABundleKey = "ca-bundle.pem"` (shared)
This removes both the `aws` and `openstack` imports from `support/globalconfig/`, fixing the import direction anti-pattern for both platforms in one pass. The platform packages (`aws`, `openstack`) retain their own constants for use within CPO code where the import direction is correct.
AI-assisted response via Claude Code
| const ( | ||
| Provider = util.AWSCloudProviderName | ||
| ProviderConfigKey = "aws.conf" | ||
| CABundleKey = "ca-bundle.pem" |
There was a problem hiding this comment.
[suggestion] CABundleKey duplicates the OpenStack constant.
This is identical to openstack.CABundleKey ("ca-bundle.pem"). If both platforms use the same key for the CA bundle in the cloud-provider-config ConfigMap, this should be a shared constant to avoid drift and make the intent clear.
Recommendation: Define a single shared constant (e.g., in support/globalconfig) and reference it from both platform packages.
There was a problem hiding this comment.
Done. Defined `globalconfig.CABundleKey = "ca-bundle.pem"` as the single shared constant in `support/globalconfig/infrastructure.go`. Removed the duplicate from `aws/providerconfig.go` and updated all AWS references (`resources.go` and tests) to use `globalconfig.CABundleKey`.
The OpenStack package still has its own `CABundleKey` — migrating it to the shared constant is a straightforward follow-up but beyond this PR's scope since it touches code paths this PR didn't modify.
AI-assisted response via Claude Code
|
Re: #8280 (review) Thank you for the thorough review @bryan-cox. Here's a summary of how each finding has been addressed: Blocking findings (1-2): Unconditional CloudConfig + ConfigMap Suggestion 3: Missing Suggestions 4-5: Import direction + duplicate Suggestion 6: Squash commits AI-assisted response via Claude Code |
openshift-ci
Bot
added
the
needs-rebase
|
I have all the information needed. Here's the complete analysis: Test Failure Analysis CompleteJob Information
Additional jobs affected:
Test Failure AnalysisErrorSummaryThe Root Causeverify-deps (failure): The PR branch has diverged from The build log also shows a merge conflict marker in security, okd-scos-images, images (error): All three jobs failed with the identical error: "Pod scheduling timeout." They were all submitted at the same time (started Recommendations
Evidence
|
|
hypershift-jira-solve-ci - please rebase this PR |
… for AWS Guest cluster operators (e.g. cloud-network-config-controller, cluster-ingress-operator) need the additional trust bundle to communicate with AWS API endpoints that use custom certificates, such as when using a proxy or private AWS endpoints. Previously, the trust bundle was only synced to the user-ca-bundle ConfigMap in the guest cluster's openshift-config namespace. With this change, we also sync it to the cloud-provider-config ConfigMap in the guest cluster, and set infra.Spec.CloudConfig on the Infrastructure resource to reference it, following the same pattern used by Azure and OpenStack platforms. The AWS case in reconcileCloudConfig now: - Always creates a cloud-provider-config ConfigMap with the AWS cloud config (aws.conf) - Includes the CA bundle (ca-bundle.pem) when additionalTrustBundle is set - Removes the CA bundle key when additionalTrustBundle is unset Ref: CNTRLPLANE-625 Co-Authored-By: Claude Opus 4.6 <[email protected]>
Ensure the new AWS cloud config reconciliation behavior is covered by unit tests: - Verify cloud-provider-config is created with CA bundle when additionalTrustBundle is set - Verify cloud-provider-config is created without CA bundle when additionalTrustBundle is not set - Verify CA bundle key is removed from cloud-provider-config when trust bundle is removed - Verify Infrastructure CloudConfig is set correctly for AWS platform Co-Authored-By: Claude Opus 4.6 <[email protected]>
…-ca-bundle gracefully Replace magic string "ca-bundle.crt" with certs.UserCABundleMapKey constant in reconcileCloudConfig and tests. Handle apierrors.IsNotFound for user-ca-bundle ConfigMap so the base aws.conf is still synced during bootstrap when the CA bundle isn't ready yet. Add error path and edge case tests for missing ConfigMaps and empty CA bundle values. Ticket: CNTRLPLANE-625 Co-Authored-By: Claude Opus 4.6 <[email protected]>
…egate trust bundles Use globalconfig.CloudProviderCMName constant in both infrastructure.go and resources.go instead of duplicated string literals. Also switch from using only spec.AdditionalTrustBundle to the aggregated managed trust bundle (trusted-ca-bundle-managed) that combines both spec.AdditionalTrustBundle and spec.configuration.Proxy.TrustedCA, consistent with the HCP controller's existing aggregation pattern. Co-Authored-By: Claude Opus 4.6 <[email protected]>
Move configv1 import to the github.com/openshift group, separate from the github.com/openshift/hypershift group, to satisfy the project's gci linter configuration. Co-Authored-By: Claude Opus 4.6 <[email protected]>
Add specific error message assertions (errContains) to error-path test cases to prevent false positives from unintended failures. Add parity test coverage for the Proxy.TrustedCA code path when the managed trust bundle ConfigMap is missing, matching existing AdditionalTrustBundle coverage. Co-Authored-By: Claude Opus 4.6 <[email protected]>
…balconfig Move CABundleKey and cloud config key constants to support/globalconfig to fix the import direction anti-pattern where support/ imported from control-plane-operator/. This also deduplicates CABundleKey which was identical between the AWS and OpenStack packages. Co-Authored-By: Claude Opus 4.6 <[email protected]>
Co-Authored-By: Claude Opus 4.6 <[email protected]>
|
Re: #8280 (review) Thank you for the thorough review @bryan-cox. All five inline comments have been addressed in replies on their respective threads. The two blocking concerns (unconditional AI-assisted response via Claude Code |
|
Re: #8280 (comment) The branch is already up to date with AI-assisted response via Claude Code |
hypershift-jira-solve-ci
Bot
force-pushed
the
fix-CNTRLPLANE-625-v2
branch
from
a042957 to
3865f41
Compare
openshift-ci
Bot
removed
the
needs-rebase
The pre-push hook runs make verify then make test sequentially. When make verify executes $(MAKE) -j verify-parallel the unbounded -j leaks into MAKEFLAGS, causing the subsequent make test → generate recipe to race: multiple git-clean invocations try to lstat the same *_mock.go files that another invocation already removed, producing a fatal "Cannot lstat" error. Append `2>/dev/null || true` so the clean step is best-effort—go generate ./… immediately recreates the mocks anyway. Co-Authored-By: Claude Opus 4.6 <[email protected]>
hypershift-jira-solve-ci
Bot
force-pushed
the
fix-CNTRLPLANE-625-v2
branch
from
3865f41 to
3c6a9ea
Compare
|
@hypershift-jira-solve-ci[bot]: all tests passed! 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. |
3 participants
What this PR does / why we need it:
Guest cluster operators (e.g.
cloud-network-config-controller,cluster-ingress-operator) need the additional trust bundle to communicate with AWS API endpoints that use custom certificates, such as when using a proxy or private AWS endpoints. Previously, the trust bundle was only synced to theuser-ca-bundleConfigMap in the guest cluster'sopenshift-confignamespace, but AWS guest operators did not pick it up from there.This PR syncs the additional trust bundle into the
cloud-provider-configConfigMap in the guest cluster and setsinfra.Spec.CloudConfigon the Infrastructure resource to reference it, following the same pattern already used by Azure and OpenStack platforms.Changes
reconcileCloudConfignow creates acloud-provider-configConfigMap containing the AWS cloud config (aws.conf) and, whenadditionalTrustBundleis set, the CA bundle (ca-bundle.pem). When the trust bundle is removed, the CA bundle key is cleaned up.ReconcileInfrastructurenow setsinfra.Spec.CloudConfig.Nameandinfra.Spec.CloudConfig.Keyfor AWS, so guest operators discover the cloud config via the standard Infrastructure resource.user-ca-bundleConfigMap is not yet available (e.g. during bootstrap), the reconciler logs and continues syncing the base AWS config without the CA bundle, rather than failing.aws.CABundleKeyconstant instead of magic strings.Which issue(s) this PR fixes:
Fixes https://redhat.atlassian.net/browse/CNTRLPLANE-625
Special notes for your reviewer:
reconcileCloudConfigAzure case) and OpenStack.user-ca-bundleConfigMap may not exist during early bootstrap; the code handlesIsNotFoundgracefully to avoid blocking reconciliation.Checklist:
Always review AI generated responses prior to use.
Generated with Claude Code via
/jira:solve [CNTRLPLANE-625](https://redhat.atlassian.net/browse/CNTRLPLANE-625)Summary by CodeRabbit
New Features
Bug Fixes
Tests