Remove OPENSHIFT_INSTALL_EXPERIMENTAL_CLUSTER_PROFILE env for installer #373
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
single-node-developer profile is not part of some of the operators and we recently noticed that it is causing the issue for dns operator where openshift/cluster-dns-operator#216 is still not merged and because of that the dns operator manifest doesn't part of CVO. This caused issue for upstream CI and really became hard to debug so this patch will make sure we don't use any profile and go with default. - BZ https://bugzilla.redhat.com/show_bug.cgi?id=1940309
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: praveenkumar The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
/lgtm |
|
/hold wait till the CI passes |
|
@praveenkumar: The following test failed, say
Full PR test history. Your PR dashboard. 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/test-infra repository. I understand the commands that are listed here. |
wking
added a commit
to wking/cluster-version-operator
that referenced
this pull request
Nov 6, 2021
There's an enhancement proposal for this profile [1], and the Code Ready Containers folks took a run at using it in [2] before backing off in [3]. I don't have any problems with having a specific CRC profile, but if we end up going that way, we'll need a lot more CVO manifests with the annotation than just these two admin-ack ConfigMaps (e.g. we'll probably also want the CVO's Namespace and Deployment, etc., or there won't be anything consuming the admin-ack ConfigMaps ;). This commit drops these two annotations, which slipped in when the ConfigMaps landed in 519b466 (Bug 1978376: Add admin ack Upgradeable condition gate, 2021-07-27, openshift#633). [1]: https://github.com/openshift/enhancements/blob/2911c46bf7d2f22eb1ab81739b4f9c2603fd0c07/enhancements/single-node/developer-cluster-profile.md [2]: crc-org/snc#338 [3]: crc-org/snc#373 (comment)
wking
added a commit
to wking/cluster-ingress-operator
that referenced
this pull request
Dec 22, 2021
There's an enhancement proposal for this profile [1], and the Code Ready Containers folks took a run at using it in [2] before backing off in [3]. I don't have any problems with having a specific CRC profile, but until we end up going that way, save ourselves the mental overhead of trying to guess whether it will want each of our manifest resources by dropping the annotation across the board. Effectively reverts abd8a20 (Annotate manifests for single-node-developer cluster profile, 2020-11-27, openshift#498). [1]: https://github.com/openshift/enhancements/blob/2911c46bf7d2f22eb1ab81739b4f9c2603fd0c07/enhancements/single-node/developer-cluster-profile.md [2]: crc-org/snc#338 [3]: crc-org/snc#373 (comment)
wking
added a commit
to wking/cluster-ingress-operator
that referenced
this pull request
Dec 22, 2021
There's an enhancement proposal for this profile [1], and the Code Ready Containers folks took a run at using it in [2] before backing off in [3]. I don't have any problems with having a specific CRC profile, but until we end up going that way, save ourselves the mental overhead of trying to guess whether it will want each of our manifest resources by dropping the annotation across the board. Effectively reverts abd8a20 (Annotate manifests for single-node-developer cluster profile, 2020-11-27, openshift#498). Generated with: $ sed -i '/single-node-developer/d' manifests/*.yaml $ git checkout HEAD -- manifests/00-custom-resource-definition.yaml where I'm leaving the CRD alone to avoid [4]: hack/verify-generated-crd.sh --- vendor/github.com/openshift/api/operator/v1/0000_50_ingress-operator_00-ingresscontroller.crd.yaml 2021-12-22 07:10:24.000000000 +0000 +++ manifests/00-custom-resource-definition.yaml 2021-12-22 07:10:25.000000000 +0000 @@ -5,7 +5,6 @@ metadata: api-approved.openshift.io: openshift/api#616 include.release.openshift.io/ibm-cloud-managed: "true" include.release.openshift.io/self-managed-high-availability: "true" - include.release.openshift.io/single-node-developer: "true" name: ingresscontrollers.operator.openshift.io spec: group: operator.openshift.io invalid CRD: vendor/github.com/openshift/api/operator/v1/0000_50_ingress-operator_00-ingresscontroller.crd.yaml => manifests/00-custom-resource-definition.yaml [1]: https://github.com/openshift/enhancements/blob/2911c46bf7d2f22eb1ab81739b4f9c2603fd0c07/enhancements/single-node/developer-cluster-profile.md [2]: crc-org/snc#338 [3]: crc-org/snc#373 (comment) [4]: https://prow.ci.openshift.org/view/gs/origin-ci-test/pr-logs/pull/openshift_cluster-ingress-operator/692/pull-ci-openshift-cluster-ingress-operator-master-verify/1473551168843026432#1:build-log.txt%3A14
wking
added a commit
to wking/cluster-ingress-operator
that referenced
this pull request
Dec 22, 2021
There's an enhancement proposal for this profile [1], and the Code Ready Containers folks took a run at using it in [2] before backing off in [3]. I don't have any problems with having a specific CRC profile, but until we end up going that way, save ourselves the mental overhead of trying to guess whether it will want each of our manifest resources by dropping the annotation across the board. Effectively reverts abd8a20 (Annotate manifests for single-node-developer cluster profile, 2020-11-27, openshift#498). Generated with: $ sed -i '/single-node-developer/d' manifests/*.yaml $ git checkout HEAD -- manifests/00-custom-resource-definition* where I'm leaving the CRDs alone to avoid things like [4]: hack/verify-generated-crd.sh --- vendor/github.com/openshift/api/operator/v1/0000_50_ingress-operator_00-ingresscontroller.crd.yaml 2021-12-22 07:10:24.000000000 +0000 +++ manifests/00-custom-resource-definition.yaml 2021-12-22 07:10:25.000000000 +0000 @@ -5,7 +5,6 @@ metadata: api-approved.openshift.io: openshift/api#616 include.release.openshift.io/ibm-cloud-managed: "true" include.release.openshift.io/self-managed-high-availability: "true" - include.release.openshift.io/single-node-developer: "true" name: ingresscontrollers.operator.openshift.io spec: group: operator.openshift.io invalid CRD: vendor/github.com/openshift/api/operator/v1/0000_50_ingress-operator_00-ingresscontroller.crd.yaml => manifests/00-custom-resource-definition.yaml [1]: https://github.com/openshift/enhancements/blob/2911c46bf7d2f22eb1ab81739b4f9c2603fd0c07/enhancements/single-node/developer-cluster-profile.md [2]: crc-org/snc#338 [3]: crc-org/snc#373 (comment) [4]: https://prow.ci.openshift.org/view/gs/origin-ci-test/pr-logs/pull/openshift_cluster-ingress-operator/692/pull-ci-openshift-cluster-ingress-operator-master-verify/1473551168843026432#1:build-log.txt%3A14
wking
added a commit
to wking/cluster-samples-operator
that referenced
this pull request
Feb 9, 2022
There's an enhancement proposal for this profile [1], and the Code Ready Containers folks took a run at using it in [2] before backing off in [3]. I don't have any problems with having a specific CRC profile, but if we end up going that way, we'll need a lot more (e.g. we'll need CVO manifests, and I dropped this profile there in [4]). Generated with: $ sed -i '/single-node-developer/d' manifests/*.yaml [1]: https://github.com/openshift/enhancements/blob/2911c46bf7d2f22eb1ab81739b4f9c2603fd0c07/enhancements/single-node/developer-cluster-profile.md [2]: crc-org/snc#338 [3]: crc-org/snc#373 (comment) [4]: openshift/cluster-version-operator#685
wking
added a commit
to wking/cluster-api-provider-openstack
that referenced
this pull request
Jan 3, 2024
As in openshift/cluster-version-operator@48fe9f2669 (install: Drop single-node-developer profile, 2021-11-05, openshift/cluster-version-operator#685). There's an enhancement proposal for this profile [1], and the Code Ready Containers folks took a run at using it in [2] before backing off in [3]. I don't have any problems with having a specific CRC profile, but if we end up going that way, we'll need a lot more manifests with the annotation (e.g. we'll probably also want the CVO manifests to include this annotation, or there won't be anything consuming the admin-ack ConfigMaps ;). This commit drops the annotation from this repository to avoid distracting folks with dead code. [1]: https://github.com/openshift/enhancements/blob/2911c46bf7d2f22eb1ab81739b4f9c2603fd0c07/enhancements/single-node/developer-cluster-profile.md [2]: crc-org/snc#338 [3]: crc-org/snc#373 (comment)
openshift-cherrypick-robot
pushed a commit
to openshift-cherrypick-robot/cluster-api-provider-openstack
that referenced
this pull request
Jan 4, 2024
As in openshift/cluster-version-operator@48fe9f2669 (install: Drop single-node-developer profile, 2021-11-05, openshift/cluster-version-operator#685). There's an enhancement proposal for this profile [1], and the Code Ready Containers folks took a run at using it in [2] before backing off in [3]. I don't have any problems with having a specific CRC profile, but if we end up going that way, we'll need a lot more manifests with the annotation (e.g. we'll probably also want the CVO manifests to include this annotation, or there won't be anything consuming the admin-ack ConfigMaps ;). This commit drops the annotation from this repository to avoid distracting folks with dead code. [1]: https://github.com/openshift/enhancements/blob/2911c46bf7d2f22eb1ab81739b4f9c2603fd0c07/enhancements/single-node/developer-cluster-profile.md [2]: crc-org/snc#338 [3]: crc-org/snc#373 (comment)
mandre
pushed a commit
to shiftstack/cluster-api-provider-openstack
that referenced
this pull request
Feb 5, 2024
As in openshift/cluster-version-operator@48fe9f2669 (install: Drop single-node-developer profile, 2021-11-05, openshift/cluster-version-operator#685). There's an enhancement proposal for this profile [1], and the Code Ready Containers folks took a run at using it in [2] before backing off in [3]. I don't have any problems with having a specific CRC profile, but if we end up going that way, we'll need a lot more manifests with the annotation (e.g. we'll probably also want the CVO manifests to include this annotation, or there won't be anything consuming the admin-ack ConfigMaps ;). This commit drops the annotation from this repository to avoid distracting folks with dead code. [1]: https://github.com/openshift/enhancements/blob/2911c46bf7d2f22eb1ab81739b4f9c2603fd0c07/enhancements/single-node/developer-cluster-profile.md [2]: crc-org/snc#338 [3]: crc-org/snc#373 (comment)
openshift-cherrypick-robot
pushed a commit
to openshift-cherrypick-robot/cluster-api-provider-openstack
that referenced
this pull request
Feb 9, 2024
As in openshift/cluster-version-operator@48fe9f2669 (install: Drop single-node-developer profile, 2021-11-05, openshift/cluster-version-operator#685). There's an enhancement proposal for this profile [1], and the Code Ready Containers folks took a run at using it in [2] before backing off in [3]. I don't have any problems with having a specific CRC profile, but if we end up going that way, we'll need a lot more manifests with the annotation (e.g. we'll probably also want the CVO manifests to include this annotation, or there won't be anything consuming the admin-ack ConfigMaps ;). This commit drops the annotation from this repository to avoid distracting folks with dead code. [1]: https://github.com/openshift/enhancements/blob/2911c46bf7d2f22eb1ab81739b4f9c2603fd0c07/enhancements/single-node/developer-cluster-profile.md [2]: crc-org/snc#338 [3]: crc-org/snc#373 (comment)
mandre
pushed a commit
to shiftstack/cluster-api-provider-openstack
that referenced
this pull request
Apr 18, 2024
As in openshift/cluster-version-operator@48fe9f2669 (install: Drop single-node-developer profile, 2021-11-05, openshift/cluster-version-operator#685). There's an enhancement proposal for this profile [1], and the Code Ready Containers folks took a run at using it in [2] before backing off in [3]. I don't have any problems with having a specific CRC profile, but if we end up going that way, we'll need a lot more manifests with the annotation (e.g. we'll probably also want the CVO manifests to include this annotation, or there won't be anything consuming the admin-ack ConfigMaps ;). This commit drops the annotation from this repository to avoid distracting folks with dead code. [1]: https://github.com/openshift/enhancements/blob/2911c46bf7d2f22eb1ab81739b4f9c2603fd0c07/enhancements/single-node/developer-cluster-profile.md [2]: crc-org/snc#338 [3]: crc-org/snc#373 (comment)
pierreprinetti
pushed a commit
to shiftstack/cluster-api-provider-openstack
that referenced
this pull request
Apr 19, 2024
As in openshift/cluster-version-operator@48fe9f2669 (install: Drop single-node-developer profile, 2021-11-05, openshift/cluster-version-operator#685). There's an enhancement proposal for this profile [1], and the Code Ready Containers folks took a run at using it in [2] before backing off in [3]. I don't have any problems with having a specific CRC profile, but if we end up going that way, we'll need a lot more manifests with the annotation (e.g. we'll probably also want the CVO manifests to include this annotation, or there won't be anything consuming the admin-ack ConfigMaps ;). This commit drops the annotation from this repository to avoid distracting folks with dead code. [1]: https://github.com/openshift/enhancements/blob/2911c46bf7d2f22eb1ab81739b4f9c2603fd0c07/enhancements/single-node/developer-cluster-profile.md [2]: crc-org/snc#338 [3]: crc-org/snc#373 (comment)
pierreprinetti
pushed a commit
to shiftstack/cluster-api-provider-openstack
that referenced
this pull request
Apr 19, 2024
As in openshift/cluster-version-operator@48fe9f2669 (install: Drop single-node-developer profile, 2021-11-05, openshift/cluster-version-operator#685). There's an enhancement proposal for this profile [1], and the Code Ready Containers folks took a run at using it in [2] before backing off in [3]. I don't have any problems with having a specific CRC profile, but if we end up going that way, we'll need a lot more manifests with the annotation (e.g. we'll probably also want the CVO manifests to include this annotation, or there won't be anything consuming the admin-ack ConfigMaps ;). This commit drops the annotation from this repository to avoid distracting folks with dead code. [1]: https://github.com/openshift/enhancements/blob/2911c46bf7d2f22eb1ab81739b4f9c2603fd0c07/enhancements/single-node/developer-cluster-profile.md [2]: crc-org/snc#338 [3]: crc-org/snc#373 (comment)
pierreprinetti
pushed a commit
to shiftstack/cluster-api-provider-openstack
that referenced
this pull request
Apr 22, 2024
As in openshift/cluster-version-operator@48fe9f2669 (install: Drop single-node-developer profile, 2021-11-05, openshift/cluster-version-operator#685). There's an enhancement proposal for this profile [1], and the Code Ready Containers folks took a run at using it in [2] before backing off in [3]. I don't have any problems with having a specific CRC profile, but if we end up going that way, we'll need a lot more manifests with the annotation (e.g. we'll probably also want the CVO manifests to include this annotation, or there won't be anything consuming the admin-ack ConfigMaps ;). This commit drops the annotation from this repository to avoid distracting folks with dead code. [1]: https://github.com/openshift/enhancements/blob/2911c46bf7d2f22eb1ab81739b4f9c2603fd0c07/enhancements/single-node/developer-cluster-profile.md [2]: crc-org/snc#338 [3]: crc-org/snc#373 (comment)
mdbooth
pushed a commit
to shiftstack/cluster-api-provider-openstack
that referenced
this pull request
Apr 23, 2024
As in openshift/cluster-version-operator@48fe9f2669 (install: Drop single-node-developer profile, 2021-11-05, openshift/cluster-version-operator#685). There's an enhancement proposal for this profile [1], and the Code Ready Containers folks took a run at using it in [2] before backing off in [3]. I don't have any problems with having a specific CRC profile, but if we end up going that way, we'll need a lot more manifests with the annotation (e.g. we'll probably also want the CVO manifests to include this annotation, or there won't be anything consuming the admin-ack ConfigMaps ;). This commit drops the annotation from this repository to avoid distracting folks with dead code. [1]: https://github.com/openshift/enhancements/blob/2911c46bf7d2f22eb1ab81739b4f9c2603fd0c07/enhancements/single-node/developer-cluster-profile.md [2]: crc-org/snc#338 [3]: crc-org/snc#373 (comment)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
single-node-developer profile is not part of some of the operators and
we recently noticed that it is causing the issue for dns operator where
openshift/cluster-dns-operator#216 is still not
merged and because of that the dns operator manifest doesn't part of
CVO.
This caused issue for upstream CI and really became hard to debug so
this patch will make sure we don't use any profile and go with default.