OCPNODE-1717: Update config node spec while explicitly updating the cgroups mode

[sairameshv]

• Future OCP releases will default to cgroupsv2
• During the upgrades, in order to honor the cgroupsv1 on the existing cluster, there should be a reference in the node spec for the future code to depend on deciding the cgroup version.
• Hence, this code updates the config node spec whenever the cgroupsv1 is explicitly set

[openshift-ci]

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

[sairameshv]

/test all

[sairameshv]

/cc @yuqi-zhang @harche

[sairameshv]

/hold cancel
This PR has been tested for upgrade to the current code base, ready for the review and hence cancelling the hold

[yuqi-zhang]

I think this path should work, but we would need to be a bit careful of how we update the nodes config.

So the expectation here is for upgraded clusters, the user would need to manually set the cgroups to v2 via nodes.config, or delete the nodes.config object in cluster (thereby defaulting it back to the RHCOS default (of v2)?

We should definitely document the behaviour change and how users should do this carefully. Let's also talk to the release team about edge blocking, just so they are ok with this solution.

[openshift-ci-robot]

@sairameshv: This pull request references OCPNODE-1717 which is a valid jira issue.

In response to this:

• Future OCP releases will default to cgroupsv2
• During the upgrades, in order to honor the cgroupsv1 on the existing cluster, there should be a reference in the node spec for the future code to depend on deciding the cgroup version.
• Hence, this code updates the config node spec whenever the cgroupsv1 is explicitly set

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.

[yuqi-zhang]

Ok, based on the CI run I think the behaviours are as expected. We end up with duplicated kargs for now, but that shouldn't be an issue once we upgrade to 4.14.

[sunilcio]

/label cherry-pick-approved

[rphillips]

/lgtm

[rphillips]

/label backport-risk-assessed

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: rphillips, sairameshv, yuqi-zhang

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:

• OWNERS [yuqi-zhang]

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

[rphillips]

/hold

@haircommander brought up a great point... Does this PR upgrade successfully to? #3782

[yuqi-zhang]

Since this is a bit of an exception to the regular process (4.13 only) we may need to either:

1. ask for someone to help merge this PR by adding the valid bug label, or
2. create a dummy 4.14 bug, mark as verified directly, then doing a /jira cherry-pick on here

[yuqi-zhang]

Does this PR upgrade successfully to? #3782

In theory it should, the MCO upon upgrade will generate a new config without the kargs in the base, but since the kargs still exist in the update node.configs object generated 97-generated-kubeletconfig, it will end up in the render and just be a no-op change by itself. @sairameshv did you verify that path? I seem to recall you did

[sairameshv]

Does this PR upgrade successfully to? #3782

In theory it should, the MCO upon upgrade will generate a new config without the kargs in the base, but since the kargs still exist in the update node.configs object generated 97-generated-kubeletconfig, it will end up in the render and just be a no-op change by itself. @sairameshv did you verify that path? I seem to recall you did

Yes, this upgrade has been tested.

[rphillips]

/hold cancel

ok. thanks!

[sairameshv]

/hold

@haircommander brought up a great point... Does this PR upgrade successfully to? #3782

I created a payload using this PR(to 4.14) and performed oc adm upgrade --to-image
It worked as expected honoring the existing cgroupsMode

[openshift-ci]

@sairameshv: 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/test-infra repository. I understand the commands that are listed here.