-
Notifications
You must be signed in to change notification settings - Fork 53
Issue 2090/route table order dependence #236
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
Issue 2090/route table order dependence #236
Conversation
Hi @gfrey. Thanks for your PR. I'm waiting for a aws-controllers-k8s member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. 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-hilaly as discussed yesterday my attempt to address this:
|
/ok-to-test |
/retest |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey @gfrey, thanks for the contribution..left a few comments.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: can we also add an e2e test addressing the issue?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To replicate my initial problem, I'd need to understand when order of routes changes in the AWS API. Otherwise, I wouldn't know how to test this.
5be11fd
to
982441e
Compare
The failing ec2-kind-e2e test seems to be unrelated to my changes, as it also came up in #241. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for your patience @gfrey,
The flaky tests are due to eventual consistencies with tagging..we will have a fix for it in our next release, but this looks good to me, just need to generate with latest code-gen :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
one more comment
In the past the routes were not order independent. Whenever the API would return a different order than specified, the routes would be deleted and recreated. The `getMatchingRoute` code also returned the first route that would have a matching field like the VPCPeeringConnectionId. This resulted in routes not being stable. Now the `customPreCompare` handles routes properly, i.e. is order independent. Also the `syncRoutes` uses the computed diff, to create or delete the according routes.
This is the issue that made the e2e tests fail.
This should help to make obvious what the different steps are doing. Also added information on the route related diffs in the delta.
This is not strictly necessary, but as these are already copied, not an issue either.
The delta contains the routes that are different between the "desired" and the "latest" state. The identical ones are ignored.
341d176
to
86e6f18
Compare
The differences for complex types (e.g. the lists of tags or routes) are given as the entire complex type, but only the changed parts. This is the way it currently is, so stick to that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for the revision @gfrey!!
left a few more comments
- Rename function - Removed `delta` from `syncRoutes` signature and thereby got rid of a lot of additional code. This is possible now that we recompute the differences, instead of using the information from the delta.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @gfrey, I have one more comment, it should be a small fix, and also rebasing to latest changes (they shouldn't affect your PR much), thanks!
Ps: I accidentally added a commit to this PR, while trying to check it out locally, please feel free to remove it!
The CreateRouteInput type supports a lot of references to different types. Those will not be set in latest. So if any references are used, the DeepEqual will always fail. The dedicated compareCreateRouteInput method will only look at the final types.
`latest` is nil if the syncRoutes method is called from createRoutes.
/retest |
1 similar comment
/retest |
This got lost somewhere on the way, so re-add it now.
/test ec2-kind-e2e |
/retest |
1 similar comment
/retest |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome! dankeshoen her @gfrey !!
/retest |
1 similar comment
/retest |
@michaelhtm @a-hilaly Is there anything missing to get this merged? Anything I can help with? |
/retest |
@gfrey: 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. |
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: a-hilaly, gfrey, 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 |
Fixes issue #2090
Description of changes:
customPreCompare
code to take care of the routes (computing the delta ignoring the order of routes).syncRoutes
code to use the delta from the compare phase.By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.