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
Bug 1791863: lib/resourcemerge/core: Clear livenessProbe and readinessProbe if nil in required #298
Bug 1791863: lib/resourcemerge/core: Clear livenessProbe and readinessProbe if nil in required #298
Conversation
… in required We claimed: if we have no required, then we don't care what someone else has set since this code landed in d9f6718 (lib: add lib for applying objects, 2018-08-14, openshift#7). But we do care in situations like [1], where a 4.3 -> 4.2 downgrade leaves 4.3 readiness probes in place for a 4.2 operator which has no /readyz. With this commit we still have a few other types where we claim to not care: $ git grep -hB1 'someone else has set' | grep func func ensureSecurityContextPtr(modified *bool, existing **corev1.SecurityContext, required *corev1.SecurityContext) { func ensureCapabilitiesPtr(modified *bool, existing **corev1.Capabilities, required *corev1.Capabilities) { func ensureAffinityPtr(modified *bool, existing **corev1.Affinity, required *corev1.Affinity) { func ensurePodSecurityContextPtr(modified *bool, existing **corev1.PodSecurityContext, required *corev1.PodSecurityContext) { func ensureSELinuxOptionsPtr(modified *bool, existing **corev1.SELinuxOptions, required *corev1.SELinuxOptions) { func setBoolPtr(modified *bool, existing **bool, required *bool) { func setInt64Ptr(modified *bool, existing **int64, required *int64) { but I'm leaving them alone until we have a clearer picture about whether we care about those specific properties or not. [1]: https://bugzilla.redhat.com/show_bug.cgi?id=1791863#c1
@wking: This pull request references Bugzilla bug 1791863, 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. |
/bugilla refresh |
@crawford, @smarterclayton: can one of you take a look at this for the 4.3->4.2 rollback bug? |
Of these types, I'd expect us to care (and clear the property) for all of those except maybe |
/bugilla refresh |
Which is a high-CI-load flake that we'll get past if/when this gets approved and retested. |
Set up the cherry-pick chain for this:
/cherrypick release-4.3 |
@wking: once the present PR merges, I will cherry-pick it on top of release-4.3 in a new PR and assign it to you. 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. |
/cherrypick release-4.2 |
@wking: once the present PR merges, I will cherry-pick it on top of release-4.2 in a new PR and assign it to you. 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. |
/cherrypick release-4.1 |
@wking: once the present PR merges, I will cherry-pick it on top of release-4.1 in a new PR and assign it to you. 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 I can't spell :( |
@wking: An error was encountered searching for bug 1791863 on the Bugzilla server at https://bugzilla.redhat.com:
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 |
@wking: This pull request references Bugzilla bug 1791863, which is valid. 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. |
LGTM |
AWS has been really slow with AMI copies today, but we'll eventually squeak through on retest if/when this gets approved. |
It is appropriate to keep this selective. |
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: smarterclayton, wking 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 Please review the full test history for this PR and help us cut down flakes. |
16 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. |
/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. |
/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. |
/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. |
@wking: All pull requests linked via external trackers have merged. Bugzilla bug 1791863 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. |
@wking: new pull request created: #299 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. |
@wking: new pull request created: #300 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. |
@wking: new pull request created: #301 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. |
Even if the manifest authors state no opinions, these are not properties that we want to allow cluster admins to manipulate. For example, a customer cluster recently stuck a Deployment by inserting a reference to a non-existent secret [1]: $ yaml2json <namespaces/openshift-marketplace/apps/deployments.yaml | jq -r '.items[].spec.template.spec.containers[].envFrom[]' { "secretRef": { "name": "openshift-reg" } } $ yaml2json <namespaces/openshift-marketplace/pods/marketplace-operator-f7cc88d59-hhh75/marketplace-operator-f7cc88d59-hhh75.yaml | jq -r '.status.containerStatuses[].state' { "waiting": { "message": "secret \"openshift-reg\" not found", "reason": "CreateContainerConfigError" } } The outgoing logic dates back to the beginning of reconciling these properties in 14fab0b (add generic 2-way merge handler for random types, 2018-09-27, openshift#26), and this commit's tightening follows on a number of reconciliation tightenings like 29b92d2 (lib/resourcemerge/core: Clear livenessProbe and readinessProbe if nil in required, 2020-01-16, openshift#298). [1]: https://bugzilla.redhat.com/show_bug.cgi?id=1951339#c0
We've claimed:
since this code landed in d9f6718 (#7). But we do care in situations like rhbz#1791863, where a 4.3 -> 4.2 downgrade leaves 4.3 readiness probes in place for a 4.2 operator which has no
/readyz
.With this pull-request we still have a few other types where we claim to not care:
but I'm leaving them alone until we have a clearer picture about whether we care about those specific properties or not.