fix: ignore field setting in sdkUpdate DBInstance #221
Conversation
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: michaelhtm 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 |
| # sdk_delete_post_request: | ||
| # code: return r, fmt.Errorf("wait for delete") |
There was a problem hiding this comment.
should we do something like this instead? ignoring sdkUpdate output? https://github.com/aws-controllers-k8s/efs-controller/blob/af06340fb3246dc107feac45136b465ade226d3c/generator.yaml#L59-L60
There was a problem hiding this comment.
Just to make sure I understand the two approaches.
In this PR you selectively ignored certain fields for the DBInstance which were receiving out of date values from the Update response. The alternative you're asking about is to completely ignore the update response for every field as a way of ensuring that no other fields are erroneously updated with out of date values from the Update response. Is that correct?
| ackcondition.SetSynced(desired, corev1.ConditionFalse, &msg, nil) | ||
| return desired, requeueWaitWhileDeleting | ||
| ackcondition.SetSynced(&resource{res}, corev1.ConditionFalse, &msg, nil) | ||
| return &resource{res}, requeueWaitWhileDeleting |
There was a problem hiding this comment.
Q: What's the purpose of replacing desired with a copy modified to have the latest status?
There was a problem hiding this comment.
This ensures that the status of the latest is patched (resource state for example, whether it is creating, updating, etc.)
The output of an sdkUpdate ends up here:
https://github.com/aws-controllers-k8s/runtime/blob/dc7be0dac4ba4706eb3ac1153c6921c59089a5db/pkg/runtime/reconciler.go#L756-L768
And if latest == desired, the status that is returned from sdkFind will be discarded.
We only need to patch the status returned from AWS API, because we want Spec to be user defined.
| # sdk_delete_post_request: | ||
| # code: return r, fmt.Errorf("wait for delete") |
There was a problem hiding this comment.
Just to make sure I understand the two approaches.
In this PR you selectively ignored certain fields for the DBInstance which were receiving out of date values from the Update response. The alternative you're asking about is to completely ignore the update response for every field as a way of ensuring that no other fields are erroneously updated with out of date values from the Update response. Is that correct?
|
@michaelhtm: Would it be possible to create a test that reproduces the bug? Having that test would both make us a bit more confident in this fix and make sure that we don't accidentally have a regression in future changes. |
When we make a ModifyDBInstance call, the output returned is outdated. Currently we've been relying on `pendingModifiedValues` to return the desired field values, but based on the longs, pendingModifiedValues is not a reliable source. These changes specifically ignore setting the fields after ModifyDBInstance is called. A better approach can be to ignore setting anything after Update is called. Just in case we're missing some values that we should ignore instead!!!
michaelhtm
force-pushed
the
fix/ignoreoutdatedfields
branch
from
1d79229 to
7a87712
Compare
michaelhtm
force-pushed
the
fix/ignoreoutdatedfields
branch
from
7a87712 to
ed1a046
Compare
|
@michaelhtm: The following test failed, say
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. |
Issue #2086
Description of changes:
When we make a ModifyDBInstance call, the output returned is outdated.
Currently we've been relying on
pendingModifiedValuesto return thedesired field values, but based on the longs, pendingModifiedValues is not
a reliable source.
These changes specifically ignore setting the fields after ModifyDBInstance
is called.
A better approach can be to ignore setting anything after Update is called.
Just in case we're missing some values that we should ignore instead!!!
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.