api
api copied to clipboard
openshift
OCPNODE-1716: Update `CgroupModeDefault` to `CgroupModeV2`
cgroupsv2 is the default cgroupMode since OCP-4.14 , hence, the CgroupModeDefault needs to be updated to CgroupModeV2 in the nodes.config.openshift.io object.
@sairameshv: This pull request references OCPNODE-1716 which is a valid jira issue.
In response to this:
In order to make cgroupsv2 by default feature in OCP-4.14, the
CgroupModeDefaultneeds to be updated toCgroupModeV2in thenodes.config.openshift.ioobject.
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.
Hello @sairameshv! 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[bot] avatar](https://avatars.githubusercontent.com/in/91280?v=4 "Published by a pub.dev verified publisher"){kind=small}
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
Is there a related PR from a payload component vendoring this change to prove the stability of the updated configuration here?
Is there a related PR from a payload component vendoring this change to prove the stability of the updated configuration here?
There is no corresponding PR as of now but this should be part of the MCO code base.
Can we create the PR and run CI against it to prove that it's not breaking anything by making this change?
Can we create the PR and run CI against it to prove that it's not breaking anything by making this change?
This change may not break the existing code. Anyway, just to be sure, I've raised a dummy PR to actually monitor the CI jobs
I've just triggered the tests on the MachineConfigOperator PR, if those are green, then I think this can be merged safely
I've just triggered the tests on the MachineConfigOperator PR, if those are green, then I think this can be merged safely
Thanks @JoelSpeed !! Sorry that I missed triggering the tests
Hey @JoelSpeed , https://github.com/openshift/machine-config-operator/pull/3789 has been merged and CgroupModeV2 is the default from the 4.14 release.
Here, I tried to bump api with this change in the MCO repository but looks like a couple of ci tests are failing (not because of this change). I would either try to work on the failures to resolve the same or request MCO team to fix them based on the availability.
Apart from that, I think this PR is ready for the merge. cc: @haircommander @harche @rphillips
/hold
This can't be merged into 4.14 folks. And especially not after the original branching day has passed already. The https://github.com/openshift/machine-config-operator/pull/3789 MUST be reverted too.
NTO and other components are not ready as this was never planned for 4.14.
Ok, we have a plan now. @haircommander is preparing a patch that allows v2 as default, but moves all PerformanceProfile users to v1. That will work, if he manages to post it in time.
But please make sure we (NTO) know about disruptive changes like this before they happen please.
/hold cancel
/hold till 4.15
We have merged MCO changes to set v2 as default. The MCO change is sufficient for 4.14 to set v2 as default for day-0. We would like to retain an ability to quickly revert to cgroups v1, just in case. Having a single MCO PR would be far easier than cycling through API and it's dependent repos.
Hence once the cgroup mode change sails through 4.14, we would merge this PR in 4.15 to mark the API default to v2. Until then we would continue to have a hybrid approach using that MCO PR where day-0 is defaulted to cgroups v2 and upgrade is maintained at the cgroup mode of 4.13 (whichever mode user had selected in 4.13 we carry it forward to 4.14 instead of forcing them to use cgroups v2)
@sairameshv: This pull request references OCPNODE-1716 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.16.0" version, but no target version was set.
In response to this:
cgroupsv2 is the default
cgroupModesince OCP-4.14 , hence, theCgroupModeDefaultneeds to be updated toCgroupModeV2in thenodes.config.openshift.ioobject.
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.
/hold till 4.15
We have merged MCO changes to set v2 as default. The MCO change is sufficient for 4.14 to set v2 as default for day-0. We would like to retain an ability to quickly revert to cgroups v1, just in case. Having a single MCO PR would be far easier than cycling through API and it's dependent repos.
Hence once the cgroup mode change sails through 4.14, we would merge this PR in 4.15 to mark the API default to v2. Until then we would continue to have a hybrid approach using that MCO PR where day-0 is defaulted to cgroups v2 and upgrade is maintained at the cgroup mode of 4.13 (whichever mode user had selected in 4.13 we carry it forward to 4.14 instead of forcing them to use cgroups v2)
/hold cancel
[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: haircommander, sairameshv Once this PR has been reviewed and has the lgtm label, please assign deads2k for approval. For more information see the Kubernetes Code Review Process.
The full list of commands accepted by this bot can be found here.
Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment
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
@sairameshv: 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/e2e-aws-ovn | ccc443d4550e11fd8a36a32e829931b118b3c8cd | link | true | /test e2e-aws-ovn |
| ci/prow/e2e-aws-ovn-techpreview | ccc443d4550e11fd8a36a32e829931b118b3c8cd | link | true | /test e2e-aws-ovn-techpreview |
| ci/prow/e2e-aws-serial | ccc443d4550e11fd8a36a32e829931b118b3c8cd | link | true | /test e2e-aws-serial |
| ci/prow/e2e-upgrade-minor | ccc443d4550e11fd8a36a32e829931b118b3c8cd | link | true | /test e2e-upgrade-minor |
| ci/prow/e2e-aws-serial-techpreview | ccc443d4550e11fd8a36a32e829931b118b3c8cd | link | true | /test e2e-aws-serial-techpreview |
| ci/prow/e2e-upgrade | ccc443d4550e11fd8a36a32e829931b118b3c8cd | link | true | /test e2e-upgrade |
| ci/prow/e2e-aws-ovn-hypershift | ccc443d4550e11fd8a36a32e829931b118b3c8cd | link | true | /test e2e-aws-ovn-hypershift |
| ci/prow/minor-e2e-upgrade-minor | ccc443d4550e11fd8a36a32e829931b118b3c8cd | link | true | /test minor-e2e-upgrade-minor |
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.