Skip to content

CM-830: Add E2E tests for trust-manager integration - #499

Open
openshift-app-platform-shift[bot] wants to merge 3 commits into
cert-manager-1.18from
feature/e2e-tests-1914-1789643366
Open

openshift-app-platform-shift[bot] wants to merge 3 commits into
cert-manager-1.18from
feature/e2e-tests-1914-1789643366

Conversation

@openshift-app-platform-shift

@openshift-app-platform-shift openshift-app-platform-shift Bot commented Sep 17, 2026 •

Copy link
Copy Markdown

Summary

  • Adds comprehensive E2E tests for the TrustManager controller (EP #1914: CM-830)
  • Tests cover the full deployment lifecycle: TrustManager CR creation → trust-manager deployment available → dependent resources verified
  • Tests validate dynamic RBAC management for secretTargets policy (Custom creates ClusterRole/Binding, Disabled removes them)
  • Tests verify defaultCAPackage feature including CA bundle injector ConfigMap and volume mounts
  • Tests confirm filterExpiredCertificates flag propagation to trust-manager container args
  • Tests verify all RBAC resources (ClusterRole, ClusterRoleBinding, Role, RoleBinding, leases Role/Binding)
  • Tests verify network policy creation for trust-manager
  • Tests verify ValidatingWebhookConfiguration creation and TLS certificate readiness
  • Tests verify drift reconciliation (deployment is recreated after manual deletion)

Depends on:

Test plan

  • E2E tests compile cleanly with go build -tags e2e ./test/e2e/...
  • Main build passes with make build
  • Run E2E test suite: go test -tags e2e -v ./test/e2e/ -run TestAll/TrustManager on a cluster with TrustManager feature gate enabled
  • Verify tests pass for basic deployment lifecycle
  • Verify tests pass for secretTargets policy transitions
  • Verify tests pass for defaultCAPackage configuration
  • Verify tests pass for RBAC, network policies, and webhook configuration

🤖 Generated with Claude Code

Adds the TrustManager CRD (trustmanagers.operator.openshift.io/v1alpha1)
to support deploying and managing the trust-manager operand. This
implements the API types defined in enhancement proposal #1914 (CM-830).

Key additions:
- TrustManager type with singleton validation (name must be 'cluster')
- TrustManagerConfig: logLevel, logFormat, trustNamespace (immutable),
  secretTargets, filterExpiredCertificates, defaultCAPackage, scheduling
- SecretTargetsConfig with CEL cross-field validation rules
- DefaultCAPackageConfig for OpenShift trusted CA bundle injection
- TrustManager FeatureGate (TechPreview, default disabled)
- Generated deepcopy, clientset, informers, listers, and CRD manifest
- Integration test suite for validation rules

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Implements the trust-manager controller for EP #1914 (CM-830), which
manages the trust-manager operand deployment. The controller follows
the same patterns established by the istiocsr controller:

- Reconciler with ctrlClient interface wrapping client.Client
- Bindata-based static manifest deployment for all dependent resources
- ReconcileError types (Irrecoverable, RetryRequired) for error handling
- Label-filtered cache via NewCacheBuilder for managed resources
- Feature gate gating via FeatureTrustManager (Beta, default: false)
- ConditionalStatus for condition management (Ready/Degraded)

Managed resources: ServiceAccount, ClusterRole/Binding, Role/Binding,
Deployment, Services (webhook + metrics), Certificate, Issuer,
ValidatingWebhookConfiguration, NetworkPolicies.

Additional features:
- Dynamic RBAC for secretTargets (creates/deletes ClusterRole/Binding
  based on SecretTargetsPolicy)
- DefaultCAPackage support via OpenShift trusted CA bundle injection
  (CNO annotation-based ConfigMap injection + PEM-to-JSON conversion)
- Configurable trust namespace, logging, resource requirements,
  affinity, tolerations, and node selectors

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Add comprehensive end-to-end tests for the TrustManager controller,
covering the deployment lifecycle, RBAC resource management,
secretTargets policy transitions, defaultCAPackage configuration,
filterExpiredCertificates flag propagation, network policies,
webhook configuration, and deployment drift reconciliation.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
@openshift-ci-robot openshift-ci-robot added the jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. label Sep 17, 2026
@openshift-ci-robot

openshift-ci-robot commented Sep 17, 2026 •

Copy link
Copy Markdown

@openshift-app-platform-shift[bot]: This pull request references CM-830 which is a valid jira issue.

Details

In response to this:

Summary

  • Adds comprehensive E2E tests for the TrustManager controller (EP #1914: CM-830)
  • Tests cover the full deployment lifecycle: TrustManager CR creation → trust-manager deployment available → dependent resources verified
  • Tests validate dynamic RBAC management for secretTargets policy (Custom creates ClusterRole/Binding, Disabled removes them)
  • Tests verify defaultCAPackage feature including CA bundle injector ConfigMap and volume mounts
  • Tests confirm filterExpiredCertificates flag propagation to trust-manager container args
  • Tests verify all RBAC resources (ClusterRole, ClusterRoleBinding, Role, RoleBinding, leases Role/Binding)
  • Tests verify network policy creation for trust-manager
  • Tests verify ValidatingWebhookConfiguration creation and TLS certificate readiness
  • Tests verify drift reconciliation (deployment is recreated after manual deletion)

Depends on:

Test plan

  • E2E tests compile cleanly with go build -tags e2e ./test/e2e/...
  • Main build passes with make build
  • Run E2E test suite: go test -tags e2e -v ./test/e2e/ -run TestAll/TrustManager on a cluster with TrustManager feature gate enabled
  • Verify tests pass for basic deployment lifecycle
  • Verify tests pass for secretTargets policy transitions
  • Verify tests pass for defaultCAPackage configuration
  • Verify tests pass for RBAC, network policies, and webhook configuration

🤖 Generated with Claude Code

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.

@coderabbitai

coderabbitai Bot commented Sep 17, 2026

Copy link
Copy Markdown

Important

Review skipped

Bot user detected.

To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository: openshift/coderabbit/.coderabbit.yaml

Review profile: CHILL

Plan: Advanced

Run ID: efae87fc-0aa2-4029-ae3d-77c3f4c52cc9

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

  • 🔍 Trigger review

Comment @coderabbitai help to get the list of available commands.

@openshift-ci

openshift-ci Bot commented Sep 17, 2026

Copy link
Copy Markdown
Contributor

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: openshift-app-platform-shift[bot]
Once this PR has been reviewed and has the lgtm label, please assign trilokgeer for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@openshift-ci openshift-ci Bot added the needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. label Sep 17, 2026
@openshift-ci

openshift-ci Bot commented Sep 17, 2026

Copy link
Copy Markdown
Contributor

Hi @openshift-app-platform-shift[bot]. Thanks for your PR.

I'm waiting for a openshift member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work.

Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

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 kubernetes-sigs/prow repository.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant