WRKLDS-1380: DeploymentConfig: drop capability from the enabled-by-default set

[ingvagabund]

DeploymentConfigs are deprecated. They will not get removed from 4.Y. Users are expected to migrate to Deployments wherever possible. Disabling the capability by default is part of making the default installation smaller while providing only the necessary key components.

Removal tested in openshift/cluster-version-operator#1066.

[openshift-ci-robot]

@ingvagabund: This pull request references WRKLDS-1380 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 story to target the "4.17.0" version, but no target version was set.

Details

In response to this:

DeploymentConfigs are deprecated. They will not get removed from 4.Y. Users are expected to migrate to Deployments wherever possible. Disabling the capability by default is part of making the default installation smaller while providing only the necessary key components.

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.

[openshift-ci]

Hello @ingvagabund! 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]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: ingvagabund
Once this PR has been reviewed and has the lgtm label, please assign joelspeed for approval. For more information see the Kubernetes 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

[ingvagabund]

/retest-required

[ingvagabund]

openshift/cluster-version-operator#1073 to resolve the failing unit test.

[ingvagabund]

/retest-required

[openshift-ci-robot]

@ingvagabund: This pull request references WRKLDS-1380 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 story to target the "4.17.0" version, but no target version was set.

Details

In response to this:

DeploymentConfigs are deprecated. They will not get removed from 4.Y. Users are expected to migrate to Deployments wherever possible. Disabling the capability by default is part of making the default installation smaller while providing only the necessary key components.

Removal tested in openshift/cluster-version-operator#1066.

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.

[ingvagabund]

/jira refresh

[openshift-ci-robot]

@ingvagabund: This pull request references WRKLDS-1380 which is a valid jira issue.

Details

In response to this:

/jira refresh

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.

[ingvagabund]

/hold
This will impact some tests that are run only when the DC api is installed.

[ingvagabund]

e2e test migration PR under openshift/origin#28957

[JoelSpeed]

What does the install configuration look like for someone who still needs deployment configs/how will that be documented to show that users can still get deployment configs on new clusters?

[ingvagabund]

We will be updating the openshift docs to mention the DC capability needs to be enabled explicitly if DCs are still needed. The same procedure as for any capability that's currently known but not enabled will be suggested.

[ingvagabund]

Periodic jobs with BASELINE_CAPABILITY_SET: None:

• https://prow.ci.openshift.org/job-history/gs/test-platform-results/logs/periodic-ci-openshift-release-master-ci-4.17-e2e-aws-ovn-no-capabilities (https://github.com/openshift/release/blob/master/ci-operator/config/openshift/release/openshift-release-master__ci-4.17.yaml)
• https://prow.ci.openshift.org/job-history/gs/test-platform-results/logs/periodic-ci-openshift-release-master-ci-4.16-e2e-aws-ovn-no-capabilities (https://github.com/openshift/release/blob/master/ci-operator/config/openshift/release/openshift-release-master__ci-4.16.yaml)
• https://prow.ci.openshift.org/job-history/gs/test-platform-results/logs/periodic-ci-openshift-release-master-ci-4.15-e2e-aws-ovn-no-capabilities (https://github.com/openshift/release/blob/master/ci-operator/config/openshift/release/openshift-release-master__ci-4.15.yaml)
• and others

Looks like noone is paying attention to these since they all are red.

[ingvagabund]

@dgoodwin @JoelSpeed one way is to introduce a new periodic job that will run all e2es with all caps enabled. There's no point of running a new e2e with just DeploymentConfig capability enabled in addition. Also probably unlikely to run a new e2e with all caps enabled for every PR across all repositories given how many variants we have. Nevertheless, given the "no capabilities" periodic job is going red I wonder if the new periodic job will end up the same?

[JoelSpeed]

Having an all capabilities test makes sense to me, but we need to make sure that something in origin is still exercising the DCs, else that will be pointless. Not sure how to make those tests only run on those particular clusters but I'm sure there's probably precedent for that.

[ingvagabund]

Oh sorry, I wanted to post these comments under openshift/origin#28957.

[JoelSpeed]

@ingvagabund Do we now have a test that will continue to test DCs into the future once this is merged? Otherwise I think we are ready to merge this aren't we?

[ingvagabund]

Not yet. I am currently discussing how to produce a periodic job testing DC enabled.

[wking]

I think we need to table this pull request until HyperShift grows support for implicitly-enabled capabilities. See discussion here. So even though there's already a hold on this pull, I'll add my own:

/hold

I'm not an API approver though; feel free to remove/ignore my hold if the reasoning isn't clear or convincing.

[openshift-ci]

@ingvagabund: The following tests 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/lint	a36180d	link	true	/test lint
ci/prow/verify-client-go	a36180d	link	true	/test verify-client-go

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.

[openshift-bot]

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[openshift-bot]

Stale issues rot after 30d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle rotten
/remove-lifecycle stale

[JoelSpeed]

@ingvagabund Are we planning to move this forward?

[ingvagabund]

Not for now :). Thank you for the reminder.