CNTRLPLANE-1752: Add PKI API to config.openshift.io/v1alpha1

[sanchezl]

• Add PKI API to config.openshift.io/v1alpha1
• make update

[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

[coderabbitai]

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

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

---

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

[openshift-ci]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[openshift-ci]

Hello @sanchezl! 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.

[sanchezl]

/test required

[openshift-ci]

@sanchezl: The specified target(s) for /test were not found.
The following commands are available to trigger required jobs:

/test build

/test e2e-aws-ovn

/test e2e-aws-ovn-hypershift

/test e2e-aws-ovn-hypershift-conformance

/test e2e-aws-ovn-techpreview

/test e2e-aws-serial-1of2

/test e2e-aws-serial-2of2

/test e2e-aws-serial-techpreview-1of2

/test e2e-aws-serial-techpreview-2of2

/test e2e-azure

/test e2e-gcp

/test e2e-upgrade

/test e2e-upgrade-out-of-change

/test images

/test integration

/test lint

/test minor-e2e-upgrade-minor

/test minor-images

/test okd-scos-images

/test unit

/test verify

/test verify-client-go

/test verify-crd-schema

/test verify-crdify

/test verify-deps

/test verify-feature-promotion

The following commands are available to trigger optional jobs:

/test okd-scos-e2e-aws-ovn

Use /test all to run the following jobs that were automatically triggered:

pull-ci-openshift-api-master-build

pull-ci-openshift-api-master-images

pull-ci-openshift-api-master-integration

pull-ci-openshift-api-master-lint

pull-ci-openshift-api-master-minor-images

pull-ci-openshift-api-master-okd-scos-images

pull-ci-openshift-api-master-unit

pull-ci-openshift-api-master-verify

pull-ci-openshift-api-master-verify-client-go

pull-ci-openshift-api-master-verify-crd-schema

pull-ci-openshift-api-master-verify-crdify

pull-ci-openshift-api-master-verify-deps

pull-ci-openshift-api-master-verify-feature-promotion

Details

In response to this:

/test required

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.

[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 joelspeed 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

[sanchezl]

/test unit
/test verify
/test verify-client-go
/test verify-crd-schema
/test verify-crdify
/test verify-deps
/test verify-feature-promotion

[openshift-ci-robot]

@sanchezl: This pull request references CNTRLPLANE-1752 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 sub-task to target the "4.22.0" version, but no target version was set.

Details

In response to this:

• Add PKI API to config.openshift.io/v1alpha1
• make update

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.

[sanchezl]

/retest-required

[openshift-ci]

@sanchezl: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
ci/prow/verify	d09d621	link	true	/test verify

Full PR test history. Your PR dashboard.

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. I understand the commands that are listed here.

[sanchezl]

I want to note that I am not using a discriminated union pattern here, instead it is more of a "parameterized" union pattern (at at least a kind of parameterized union where its all fields or none).

This configuration models a "predefined behavior vs. customization" choice pattern, rather than mutually exclusive options with different configuration requirements (like platform-specific settings).

If we add more predefined behaviors (e.g., type: FIPS, type: CNSACompliant), they would be additional enum values with no configuration fields. They represent different default behaviors, not different configuration structures.

If we need to extend what's configurable (e.g., adding certificate lifetime configuration), we'd add fields to PKIProfile and/or CertificateConfig. These fields would apply regardless of which predefined behavior or custom configuration is in use.

[everettraven]

I'm not sure I'm following why this is a better approach than a discriminated union pattern.

Discriminated unions are a common pattern in OpenShift APIs (so our users will be used to them) and they allow for discriminators with no associated configuration fields.

If we add more predefined behaviors (e.g., type: FIPS, type: CNSACompliant), they would be additional enum values with no configuration fields. They represent different default behaviors, not different configuration structures.

If we need to extend what's configurable (e.g., adding certificate lifetime configuration), we'd add fields to PKIProfile and/or CertificateConfig. These fields would apply regardless of which predefined behavior or custom configuration is in use.

It sounds like if we added any additional pre-defined behaviors any new configuration options we add would be not configurable by end-users with these pre-defined behaviors.

To me, this reads that the only time we anticipate ever being able to configure something is when type is set to Custom - in which case an end-user must supply some kind of configuration.

Is this accurate?