OCPBUGS-36870: Remove tuned/rendered object #1110
Conversation
openshift-ci-robot
added
jira/severity-important
|
@jmencak: This pull request references Jira Issue OCPBUGS-36870, which is valid. 7 validation(s) were run on this bug
No GitHub users were found matching the public email listed for the QA contact in Jira ([email protected]), skipping review request. The bug has been updated to refer to the pull request using the external bug tracker. In response to this:
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. |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: jmencak 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 |
openshift-ci
bot
added
the
approved
|
Right, so the linter is failing on the deprecated
Opinions, reviewers? Thank you. |
@ffromani thoughts keeping other backporting efforts in mind? Both options should work, the first one will probably be more more invasive. (Slightly) leaning towards bullet point 2 myself, but happy with both. |
same here, slightly leaning towards 2. I'd go for it unless other reviewers have stronger opinions |
The NTO operand is controlled by the operator by updates to two resources. Its corresponding k8s Tuned Profile resource and tuned/rendered object, which contains a list of all TuneD (daemon) profiles. While this setup works for most cases, there is a problem with this approach when a cluster administator changes both a current TuneD profile content and (at the same) time switches to a new TuneD profile completely. Then, depending on the k8s object update timing, we could see two TuneD daemon reloads instead of just one. Remove the tuned/rendered object and carry TuneD (daemon) profiles directly in the Tuned Profile k8s objects. Resolves: OCPBUGS-36870
jmencak
force-pushed
the
4.15-OCPBUGS-36870-no-rendered
branch
from
14ea159 to
2287f21
Compare
|
@jmencak: 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. |
Thank you. Changed the PR to use option 2 and the tests pass. @Tal-or , opinions? Thank you. |
Works for me as well. We can change it later during some maintenance work in the future |
|
/lgtm |
|
/hold |
openshift-ci
bot
added
the
do-not-merge/hold
Thank you for looking, Francesco. May I have the reasoning behind this? Thank you! |
|
/hold cancel |
openshift-ci
bot
removed
the
do-not-merge/hold
Makes sense, thank you for the reasoning. |
|
/label backport-risk-assessed |
openshift-ci
bot
added
the
backport-risk-assessed
|
/label cherry-pick-approved |
openshift-ci
bot
added
the
cherry-pick-approved
openshift-merge-bot
bot
merged commit 7eab9a3
into
openshift:release-4.15
|
@jmencak: Jira Issue OCPBUGS-36870: All pull requests linked via external trackers have merged: Jira Issue OCPBUGS-36870 has been moved to the MODIFIED state. In response to this:
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. |
|
[ART PR BUILD NOTIFIER] Distgit: cluster-node-tuning-operator |
|
Fix included in accepted release 4.15.0-0.nightly-2024-07-23-123403 |
This is a backport openshift#1110 of which resolved OCPBUGS-36870 in 4.15. The NTO operand is controlled by the operator by updates to two resources. Its corresponding k8s Tuned Profile resource and tuned/rendered object, which contains a list of all TuneD (daemon) profiles. While this setup works for most cases, there is a problem with this approach when a cluster administator changes both a current TuneD profile content and (at the same) time switches to a new TuneD profile completely. Then, depending on the k8s object update timing, we could see two TuneD daemon reloads instead of just one. Remove the tuned/rendered object and carry TuneD (daemon) profiles directly in the Tuned Profile k8s objects. Resolves: OCPBUGS-37754
This is a backport openshift#1110 of which resolved OCPBUGS-36870 in 4.15. The NTO operand is controlled by the operator by updates to two resources. Its corresponding k8s Tuned Profile resource and tuned/rendered object, which contains a list of all TuneD (daemon) profiles. While this setup works for most cases, there is a problem with this approach when a cluster administator changes both a current TuneD profile content and (at the same) time switches to a new TuneD profile completely. Then, depending on the k8s object update timing, we could see two TuneD daemon reloads instead of just one. Remove the tuned/rendered object and carry TuneD (daemon) profiles directly in the Tuned Profile k8s objects. Resolves: OCPBUGS-37754
This is a backport #1110 of which resolved OCPBUGS-36870 in 4.15. The NTO operand is controlled by the operator by updates to two resources. Its corresponding k8s Tuned Profile resource and tuned/rendered object, which contains a list of all TuneD (daemon) profiles. While this setup works for most cases, there is a problem with this approach when a cluster administator changes both a current TuneD profile content and (at the same) time switches to a new TuneD profile completely. Then, depending on the k8s object update timing, we could see two TuneD daemon reloads instead of just one. Remove the tuned/rendered object and carry TuneD (daemon) profiles directly in the Tuned Profile k8s objects. Resolves: OCPBUGS-37754 Co-authored-by: Jiri Mencak <[email protected]>
This is a manual backport of #1036 . Changes from #1036: using the current (deprecated)
k8s.io/utils/pointerpackage and adjusted the test code to use it.The NTO operand is controlled by the operator by updates to two resources. Its corresponding k8s Tuned Profile resource and tuned/rendered object, which contains a list of all TuneD (daemon) profiles.
While this setup works for most cases, there is a problem with this approach when a cluster administator changes both a current TuneD profile content and (at the same) time switches to a new TuneD profile completely. Then, depending on the k8s object update timing, we could see two TuneD daemon reloads instead of just one.
Remove the tuned/rendered object and carry TuneD (daemon) profiles directly in the Tuned Profile k8s objects.
Resolves: OCPBUGS-36870