-
Notifications
You must be signed in to change notification settings - Fork 302
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
Create additional NEGs based on subnets in Node Topology CR. #2702
base: master
Are you sure you want to change the base?
Conversation
sawsa307
commented
Oct 18, 2024
- Query Node Topology CR for the current set of NEGs in the cluster.
- When ensureNetworkEndpointGroups(), ensure NEGs are properly provisioned in the non-default subnets as well.
2f593bb
to
29bc49a
Compare
/assign @gauravkghildiyal |
29bc49a
to
8b82474
Compare
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: sawsa307 The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
644e229
to
264bd6c
Compare
/label tide/merge-method-squash |
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.
Just addressed all the comments, @gauravkghildiyal could you take another look when you have time? Thank you!
Also, is this TODO something that we plan on fixing independently? I guess as long as the MSC flags are disabled, this shouldn't cause any problems but please do confirm. Thanks! |
Yes I'm planning to tackle those TODO in follow up PRs(like #2728), but if you would like, I can also include some of them in this PR as well. |
4bc66aa
to
6d44fe7
Compare
pkg/utils/zonegetter/zone_getter.go
Outdated
nodeTopologyNotSynced := z.nodeTopologyInformer != nil && !z.nodeTopologyHasSynced() | ||
if z.onlyIncludeDefaultSubnetNodes || z.nodeTopologyInformer == nil || nodeTopologyNotSynced { | ||
if z.nodeTopologyInformer == nil || nodeTopologyNotSynced { | ||
logger.Info("NodeTopologyInformer is not ready, fall back to use default subnet only") |
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.
I'd recommend
logger.Info("Falling back to only using default subnet", "z.onlyIncludeDefaultSubnetNodes", z.onlyIncludeDefaultSubnetNodes, <Rest of the variables influencing this decision>)
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.
Updated, thanks!
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.
It may be useful to know what was the reason why we are using "default subnet only", which means it's worth logging ALL the variables which went into that decision. So maybe we don't have an if !z.nodeTopologyHasSynced() {
condition for the logs, and instead log:
logger.Info("Falling back to only using default subnet when listing nodes", "z.onlyIncludeDefaultSubnetNodes", z.onlyIncludeDefaultSubnetNodes, "z.nodeTopologyHasSynced()", nodeTopologyHasSynced)
On a related note, it plan on using or logging z.nodeTopologyHasSynced()
, it may be useful to store it in a variable before. Reason being that since it's a function, it may return a different value between two independent invocations -- if that ever happens for some reason, our logs would simply end up confusing us.
* Remove NodeTopologyInformer from controller context hasSynced so it won't block controllers from starting up in case of the CRD or CR does not exist.
* Query Node Topology CR for the current set of NEGs in the cluster. * When ensureNetworkEndpointGroups(), ensure NEGs are properly provisioned in the non-default subnets as well.
6d44fe7
to
055d691
Compare
namer negtypes.NetworkEndpointGroupNamer | ||
l4Namer namer.L4ResourcesNamer |
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.
do we need both. the namer should be L4 / L7 agnostic. The right namer should be set on transactionSyncer creation
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.
We need both since they have different interface and naming schema.
For L4 NEGs, the NEG name is determined by L4Backend(), while NEG() is only for L7 NEGs. As a result, I also separated the naming schema for L4 and L7 non-default subnet NEGs as L4NonDefaultSubnetNEG and NonDefaultSubnetNEG.
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.
Interestingly, because of this complication of having two separate L4 and L7 namers, even the existing code has a bug at:
ingress-gce/pkg/neg/manager.go
Line 246 in 169b2c0
!manager.namer.IsNEG(portInfo.NegName), |
where this value determines the value of customName bool
. The way our new logic is, this should lead to customName
always being true for L4 NEGs and thus it would end up using the L7 custom namer for L4 NEGs.
Do we want to make L4 and L7 namers implement the following?
NonDefaultSubnetNEG(namespace, name, subnetName string, port int32) string
NonDefaultSubnetCustomNEG(customNEGName, subnetName string) (string, error)
- The
port
value will not be used for L4 - Because we will set customNEG for L4 to always be false, the L4
NonDefaultSubnetCustomNEG
should also never be used.
@gauravkghildiyal @swetharepakula This PR is ready for another round of review, please take a look, thank you! |
Github is just the worst at showing newly added comments so sharing the links: |
Addressed both comments, please take a look! @gauravkghildiyal |