install service ca crd from api

[lance5890]

User description

I will propose a PR for service-ca-operator later

rather then add the crd in https://github.com/openshift/service-ca-operator/blob/503e4f5f4c74fd095a8dca385541125f3c9ee28b/Dockerfile.rhel7#L13

After this change , no need to Bump api, and update CRD path anymore such as :
openshift/service-ca-operator@66d26cc

---

PR Type

Enhancement

---

Description

• Add ServiceCA CRD manifest to payload

• Include service-ca operator CRD in build artifacts

• Register CRD glob pattern in update script

---

Diagram Walkthrough

flowchart LR
  A["Update Script"] -- "adds glob pattern" --> B["CRD Discovery"]
  B -- "includes" --> C["ServiceCA CRD Manifest"]
  C -- "defines" --> D["ServiceCA Resource"]

Loading

File Walkthrough

	Relevant files
Configuration changes	update-payload-crds.sh Register ServiceCA CRD glob pattern                                            hack/update-payload-crds.sh Added glob pattern for ServiceCA CRD discovery Pattern matches operator/v1/zz_generated.crd-manifests/0000_50_service-ca_02_servicecas*.crd.yaml Enables automatic inclusion of service-ca operator CRD in payload +1/-0
Enhancement	0000_50_service-ca_02_servicecas.crd.yaml Create ServiceCA CRD manifest definition                                  payload-manifests/crds/0000_50_service-ca_02_servicecas.crd.yaml New ServiceCA CustomResourceDefinition manifest file Defines ServiceCA resource for operator.openshift.io group Includes spec properties for logLevel, managementState, observedConfig, operatorLogLevel, and unsupportedConfigOverrides Includes status properties for conditions, generations, latestAvailableRevision, observedGeneration, readyReplicas, and version +211/-0

---

[openshift-ci-robot]

Pipeline controller notification
This repo is configured to use the pipeline controller. Second-stage tests will be triggered either automatically or after lgtm label is added, depending on the repository configuration. The pipeline controller will automatically detect which contexts are required and will utilize /test Prow commands to trigger the second stage.

For optional jobs, comment /test ? to see a list of all defined jobs. To trigger manually all jobs from second stage use /pipeline required command.

This repository is configured in: LGTM mode

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign everettraven 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:

• OWNERS

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

[qodo-code-review]

PR Compliance Guide 🔍

Below is a summary of compliance checks for this PR:

Security Compliance
🟢	No security concerns identified No security vulnerabilities detected by AI analysis. Human verification advised for critical code.
Ticket Compliance
⚪	🎫 No ticket provided Create ticket/issue
Codebase Duplication Compliance
⚪	Codebase context is not defined Follow the guide to enable codebase context checks.
Custom Compliance
🟢	Generic: Comprehensive Audit Trails Objective: To create a detailed and reliable record of critical system actions for security analysis and compliance. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Meaningful Naming and Self-Documenting Code Objective: Ensure all identifiers clearly express their purpose and intent, making code self-documenting Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Robust Error Handling and Edge Case Management Objective: Ensure comprehensive error handling that provides meaningful context and graceful degradation Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Secure Error Handling Objective: To prevent the leakage of sensitive system information through error messages while providing sufficient detail for internal debugging. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Secure Logging Practices Objective: To ensure logs are useful for debugging and auditing without exposing sensitive information like PII, PHI, or cardholder data. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Security-First Input Validation and Data Handling Objective: Ensure all data inputs are validated, sanitized, and handled securely to prevent vulnerabilities Status: Passed Learn more about managing compliance generic rules or creating your own custom rules

Compliance status legend

🟢 - Fully Compliant
🟡 - Partial Compliant
🔴 - Not Compliant
⚪ - Requires Further Human Verification
🏷️ - Compliance label

[coderabbitai]

📝 Walkthrough

Walkthrough

This change introduces a new CustomResourceDefinition (CRD) for the ServiceCA resource within the OpenShift operator group. The CRD manifest file defines a cluster-scoped resource with comprehensive OpenAPI v3 schema validation, including specification fields for log levels and management state, along with status fields for conditions and generational tracking. The update script is simultaneously modified to include the new CRD pattern in its collection process, ensuring the manifest is incorporated into the payload CRDs.

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title 'install service ca crd from api' is related to the changeset, which adds a ServiceCA CRD manifest and registers it in the build script.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Description check	✅ Passed	The pull request description clearly relates to the changeset by explaining the addition of ServiceCA CRD manifest to payload and the update to the CRD discovery script.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[openshift-ci]

Hello @lance5890! Some important instructions when contributing to openshift/api:
API design plays an important part in the user experience of OpenShift and as such API PRs are subject to a high level of scrutiny to ensure they follow our best practices. If you haven't already done so, please review the OpenShift API Conventions and ensure that your proposed changes are compliant. Following these conventions will help expedite the api review process for your PR.

[openshift-ci]

Hi @lance5890. 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.

[lance5890]

/hold

[qodo-code-review]

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Impact
General	Provide default managementState value Add a default value for the managementState field in the CRD to provide a sensible fallback. payload-manifests/crds/0000_50_service-ca_02_servicecas.crd.yaml [62-66] managementState: description: managementState indicates whether and how the operator should manage the component + type: string pattern: ^(Managed|Unmanaged|Force|Removed)$ - type: string + default: Managed Apply / Chat Suggestion importance[1-10]: 6 __ Why: Adding a default value for managementState is a good practice that improves the CRD's usability and predictability, ensuring a defined state even when the field is not explicitly set.	Low
	Remove blank enum entry Remove the empty string from the enum for logLevel and operatorLogLevel to enforce valid, non-blank values. payload-manifests/crds/0000_50_service-ca_02_servicecas.crd.yaml [55-60] enum: -- "" - Normal - Debug - Trace - TraceAll Apply / Chat Suggestion importance[1-10]: 6 __ Why: The suggestion correctly identifies that allowing an empty string in the enum contradicts the description and can lead to ambiguity; removing it makes the schema stricter and more robust.	Low
	Skip non-matching glob patterns Enable nullglob in the shell script to prevent errors when a glob pattern does not match any files. hack/update-payload-crds.sh [40-42] +shopt -s nullglob for f in ${crd_globs}; do cp "$f" "${SCRIPT_ROOT}/payload-manifests/crds/" done [To ensure code accuracy, apply this suggestion manually] Suggestion importance[1-10]: 5 __ Why: The suggestion correctly points out that if a glob pattern in crd_globs doesn't match any files, the script will error. Using nullglob makes the script more robust.	Low
More

[lance5890]

/unhold

[JoelSpeed]

@lance5890 is there a specific reason you've raised this PR? Can you provide a bit more context on your motivation?

I've spoken with the team who owns the service CA operator and they aren't aware of any need or motivation to move the CRDs for this operator at present