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
[release-4.3] Bug 1822750: [ctrcfg controller] Use a struct array instead of map when creating new ignitions #1645
[release-4.3] Bug 1822750: [ctrcfg controller] Use a struct array instead of map when creating new ignitions #1645
Conversation
@umohnani8: This pull request references Bugzilla bug 1822750, which is invalid:
Comment 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 kubernetes/test-infra repository. |
A map doesn't guarantee order when we are creating new ignitions. When we update the image CR with blocked registries, the ctrcfg controller needs to update two files registries.conf and policy.json. Since we get an update from the image CR about every 20 mins, we compare the semantics to see if anything has changed. But since the order is not guaranteed, the controller might think that the semantics is not equal even if nothing in the data changed. Hence another MC is created, and everytime we get an update the MC applied to the nodes keeps flipping back and forth for the 2 possible orders causing the nodes to reboot a bunch of times. So move to using a struct array to ensure the order is always the same and we don't have two similar MCs being created. Signed-off-by: Urvashi Mohnani <umohnani@redhat.com>
Manually opened this as automatic cherry-pick failed #1637 (comment) |
/skip e2e-aws-scaleup-rhel7 |
/bugzilla refresh |
@ashcrow: This pull request references Bugzilla bug 1822750, which is invalid:
Comment 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 kubernetes/test-infra repository. |
Made some changes to the BZs, now it should be good and dependent on the correct BZ /bugzilla refresh |
@runcom: This pull request references Bugzilla bug 1822750, which is invalid:
Comment 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 kubernetes/test-infra repository. |
/approve |
/skip |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: runcom, umohnani8 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 |
/retest |
/retest Please review the full test history for this PR and help us cut down flakes. |
2 similar comments
/retest Please review the full test history for this PR and help us cut down flakes. |
/retest Please review the full test history for this PR and help us cut down flakes. |
/bugzilla refresh Recalculating validity in case the underlying Bugzilla bug has changed. |
@openshift-bot: This pull request references Bugzilla bug 1822750, which is invalid:
Comment 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 kubernetes/test-infra repository. |
/bugzilla refresh Recalculating validity in case the underlying Bugzilla bug has changed. |
@openshift-bot: This pull request references Bugzilla bug 1822750, which is invalid:
Comment 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 kubernetes/test-infra repository. |
/bugzilla refresh Recalculating validity in case the underlying Bugzilla bug has changed. |
@openshift-bot: This pull request references Bugzilla bug 1822750, which is invalid:
Comment 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 kubernetes/test-infra repository. |
/bugzilla refresh Recalculating validity in case the underlying Bugzilla bug has changed. |
@openshift-bot: This pull request references Bugzilla bug 1822750, which is invalid:
Comment 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 kubernetes/test-infra repository. |
/bugzilla refresh Recalculating validity in case the underlying Bugzilla bug has changed. |
@openshift-bot: This pull request references Bugzilla bug 1822750, which is invalid:
Comment 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 kubernetes/test-infra repository. |
/bugzilla refresh Recalculating validity in case the underlying Bugzilla bug has changed. |
@openshift-bot: This pull request references Bugzilla bug 1822750, which is invalid:
Comment 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 kubernetes/test-infra repository. |
/bugzilla refresh |
@umohnani8: This pull request references Bugzilla bug 1822750, which is valid. The bug has been moved to the POST state. The bug has been updated to refer to the pull request using the external bug tracker. 6 validation(s) were run on this bug
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 kubernetes/test-infra repository. |
/retest Please review the full test history for this PR and help us cut down flakes. |
4 similar comments
/retest Please review the full test history for this PR and help us cut down flakes. |
/retest Please review the full test history for this PR and help us cut down flakes. |
/retest Please review the full test history for this PR and help us cut down flakes. |
/retest Please review the full test history for this PR and help us cut down flakes. |
@umohnani8: The following test failed, say
Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR. 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. |
/retest Please review the full test history for this PR and help us cut down flakes. |
1 similar comment
/retest Please review the full test history for this PR and help us cut down flakes. |
@umohnani8: All pull requests linked via external trackers have merged: openshift/machine-config-operator#1645. Bugzilla bug 1822750 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 kubernetes/test-infra repository. |
Fixes #1822750 (https://bugzilla.redhat.com/show_bug.cgi?id=1822750)
cherry-pick of #1637
Signed-off-by: Urvashi Mohnani umohnani@redhat.com
- What I did
A map doesn't guarantee order when we are creating new ignitions.
When we update the image CR with blocked registries, the ctrcfg
controller needs to update two files registries.conf and policy.json.
Since we get an update from the image CR about every 20 mins, we compare
the semantics to see if anything has changed. But since the order is not
guaranteed, the controller might think that the semantics is not equal
even if nothing in the data changed. Hence another MC is created, and
everytime we get an update the MC applied to the nodes keeps flipping
back and forth for the 2 possible orders causing the nodes to reboot a
bunch of times. So move to using a struct array to ensure the order is
always the same and we don't have two similar MCs being created.
- How to verify it
Update the image.config.openshift.io CR with blocked registries and watch to ensure
that 2 MCs are not created after a few mins or hours.
- Description for the changelog
Use a struct array instead of map when creating new ignitions for the container
runtime config controller.