-
Notifications
You must be signed in to change notification settings - Fork 303
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
Fix creation of NEGs in the new zone when cluster spans to the new zone #1754
Conversation
Hi @gauravkghildiyal. Thanks for your PR. I'm waiting for a kubernetes 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. |
/ok-to-test |
pkg/neg/controller.go
Outdated
// - CandidateNodesPredicate() function decides the candidate nodes for the GCE_VM_IP_PORT kind of NEGs | ||
// | ||
// If we find a change in the candidacy of the node according to any of the two functions above, we should enqueue the node. | ||
if utils.CandidateNodesPredicateIncludeUnreadyExcludeUpgradingNodes(oldNode) != utils.CandidateNodesPredicateIncludeUnreadyExcludeUpgradingNodes(currentNode) || |
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.
The only concern I have with this approach is that we may cause L4 NEGs to be synced more than needed. we probably need to be able to differentiate later on, how not to trigger extra syncs.
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. That makes sense.
The reason why I initially thought it shouldn't be a problem was based on the need that we want to minimize the number of calls made to GCE APIs. Since isZoneChange()
function was just making calls to the Kubernetes Cluster API, I thought it would be okay.
But it's true that there was scope of improvement there as we can save these O(number of nodes) operations used by isZoneChange()
for each NEG, by just calculating it at the beginning and not doing it for each NEG
417c4bf
to
0a2139e
Compare
e4a4e34
to
178112e
Compare
178112e
to
43ec4e1
Compare
43ec4e1
to
0b294be
Compare
0b294be
to
0ddfb88
Compare
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 the change!
/approve
/lgtm
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: gauravkghildiyal, swetharepakula 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 |
This reverts the behaviour to what existed prior to kubernetes#1754
This reverts the behaviour to what existed prior to kubernetes#1754
This reverts the behaviour to what existed prior to kubernetes#1754
This reverts the behaviour to what existed prior to kubernetes#1754
This reverts the behaviour to what existed prior to kubernetes#1754
Propagate node update events for both NEG types (GCE_VM_IP_PORT + GCE_VM_IP)
Configure separate zoneMaps for the NEG types (
vmIpZoneMap
andvmIpPortZoneMap
). These zoneMaps will be updated using the same predicate function that is eventually used insidetransactionSyncer.isZoneChange()
for the respective NEG types.Introduce a new function
NodePredicateForNetworkEndpointType
that will be the source of truth for the type of predicate function to be used for a given NEG type.For future reference, here's another related PR: #1600
/assign @swetharepakula