Skip to content

update to release.openshift.io/feature-set to match OCP 4.12 #1261

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
openshift-merge-robot merged 1 commit into from
Oct 12, 2022
Merged

update to release.openshift.io/feature-set to match OCP 4.12 #1261

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion enhancements/installer/component-selection.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -150,7 +150,7 @@ excluded while ServiceMonitors associated with other capabilities would not be).
To determine which manifests are managed for a given cluster, the CVO will:

1. Start with all the manifests in the payload.
2. If TechPreviewNoUpgrade is not set, [remove all the manifests with `release.openshift.io/feature-gate=TechPreviewNoUpgrade`](../update/cvo-techpreview-manifests.md).
2. If TechPreviewNoUpgrade is not set, [remove all the manifests with `release.openshift.io/feature-set=TechPreviewNoUpgrade`](../update/cvo-techpreview-manifests.md).
3. Remove all the manifests that lack [`include.release.openshift.io/{profile}=true`](../update/cluster-profiles.md).
4. Remove all the manifests that declare a capability in `capability.openshift.io/name` which is not part of the current enabled capabilities.

Expand Down
4 changes: 2 additions & 2 deletions enhancements/olm/platform-operators.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -233,7 +233,7 @@ spec:
featureSet: TechPreviewNoUpgrade
```

Enabling the tech preview feature set will result in the installation of the PO components in the cluster. This requires adding the "release.openshift.io/feature-gate" annotation key to the PO's downstream CVO manifests, and setting that key's value to "TechPreviewNoUpgrade".
Enabling the tech preview feature set will result in the installation of the PO components in the cluster. This requires adding the "release.openshift.io/feature-set" annotation key to the PO's downstream CVO manifests, and setting that key's value to "TechPreviewNoUpgrade".

#### Reconcile POM "aggregate" ClusterOperator object

Expand Down Expand Up @@ -522,7 +522,7 @@ type PlatformOperator struct {

#### Mitigations

The v1alpha1 CRDs won't be deployed by default, and those APIs will be hidden behind the "TechPreviewNoUpgrade" feature set that admins need to explicitly enable before cluster creation. Any new components introduced during these early phases will also specify the `release.openshift.io/feature-gate` annotation in their CVO manifests, and set that key's value to "TechPreviewNoUpgrade".
The v1alpha1 CRDs won't be deployed by default, and those APIs will be hidden behind the "TechPreviewNoUpgrade" feature set that admins need to explicitly enable before cluster creation. Any new components introduced during these early phases will also specify the `release.openshift.io/feature-set` annotation in their CVO manifests, and set that key's value to "TechPreviewNoUpgrade".
This annotation will ensure that the CVO won't deploy any tech preview components in a non-tech preview cluster.

The BundleDeployment API is a cluster-scoped API, which means that only users with wildcard permissions should be able to access this API by default. It's recommended that admins should limit access to the BundleDeployment API to the minimum set of users in order to mitigate the plain provisioner's wide net of permissions. This behavior may require explicit downstream documentation.
Expand Down