Skip to content
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.

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

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

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

ingvagabund
Copy link
Member

@ingvagabund ingvagabund commented Jul 10, 2024

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.

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.
@openshift-ci-robot openshift-ci-robot added the jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. label Jul 10, 2024
@openshift-ci-robot
Copy link

openshift-ci-robot commented Jul 10, 2024

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

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.

Copy link
Contributor

openshift-ci bot commented Jul 10, 2024

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 openshift-ci bot added the size/XS Denotes a PR that changes 0-9 lines, ignoring generated files. label Jul 10, 2024
Copy link
Contributor

openshift-ci bot commented Jul 10, 2024

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

Needs approval from an approver in each of these files:

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

@ingvagabund
Copy link
Member Author

/retest-required

@ingvagabund
Copy link
Member Author

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

@ingvagabund
Copy link
Member Author

/retest-required

@openshift-ci-robot
Copy link

openshift-ci-robot commented Jul 26, 2024

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

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
Copy link
Member Author

/jira refresh

@openshift-ci-robot
Copy link

openshift-ci-robot commented Jul 26, 2024

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

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
Copy link
Member Author

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

@openshift-ci openshift-ci bot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Jul 26, 2024
@ingvagabund
Copy link
Member Author

e2e test migration PR under openshift/origin#28957

@JoelSpeed
Copy link
Contributor

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
Copy link
Member Author

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
Copy link
Member Author

@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
Copy link
Contributor

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
Copy link
Member Author

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

Copy link
Contributor

openshift-ci bot commented Aug 15, 2024

@ingvagabund: all tests passed!

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. size/XS Denotes a PR that changes 0-9 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants