Annotation network.harvesterhci.io/mtu-source-vc isn't cleaned up#237
Annotation network.harvesterhci.io/mtu-source-vc isn't cleaned up#237votdev wants to merge 1 commit intoharvester:masterfrom
network.harvesterhci.io/mtu-source-vc isn't cleaned up#237Conversation
There was a problem hiding this comment.
Pull request overview
This PR addresses dangling MTU-related ClusterNetwork annotations left behind after deleting a VlanConfig (cluster network configuration), ensuring MTU source tracking and MTU annotations are updated/cleared correctly. It also includes a small MTU parsing utility rename and related call-site updates.
Changes:
- Add
VlanConfigremove handling to switch/clearnetwork.harvesterhci.io/mtu-source-vcandnetwork.harvesterhci.io/uplink-mtuon the referencedClusterNetwork. - Update ClusterNetwork webhook validation to allow removing the
uplink-mtuannotation without blocking updates. - Rename MTU parsing helper from
GetMTUFromAnnotationtoGetMTUFromStringand update usages.
Reviewed changes
Copilot reviewed 6 out of 6 changed files in this pull request and generated 4 comments.
Show a summary per file
| File | Description |
|---|---|
| pkg/webhook/nad/validator.go | Switch to GetMTUFromString when validating MTU annotation values. |
| pkg/webhook/nad/mutator.go | Switch to GetMTUFromString when mutating NAD MTU based on ClusterNetwork annotation. |
| pkg/webhook/clusternetwork/validator.go | Allow updates where uplink-mtu annotation is removed; update parser usage. |
| pkg/utils/mtu.go | Rename MTU parsing helper and adjust error messages accordingly. |
| pkg/controller/manager/vlanconfig/controller.go | Add OnVlanConfigRemove handler to update/clear ClusterNetwork MTU annotations on VC deletion. |
| pkg/controller/manager/nad/controller.go | Switch to GetMTUFromString when syncing CN MTU annotation into NAD config. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
9b7abe3 to
fc4a3c6
Compare
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 6 out of 6 changed files in this pull request and generated 3 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| // present in the list). | ||
| var vcCandidate *networkv1.VlanConfig | ||
| for _, item := range vcs { | ||
| if item.Name == vc.Name || item.DeletionTimestamp != nil { | ||
| continue | ||
| } | ||
|
|
||
| if utils.IsValidMTU(utils.GetMTUFromVlanConfig(item)) { | ||
| vcCandidate = item | ||
| break | ||
| } | ||
| } | ||
|
|
There was a problem hiding this comment.
OnVlanConfigRemove picks the first remaining VlanConfig with a valid MTU, but utils.IsValidMTU treats MTU=0 as valid. This can cause the controller to switch mtu-source-vc to a VC with MTU=0 even when another remaining VC has an explicit non-zero MTU, leading to unnecessary annotation churn and potentially incorrect sourcing. Consider preferring a non-zero MTU candidate when available and only falling back to MTU=0 if no non-zero candidates exist (mirroring ensureClusterNetwork’s effective MTU logic).
| // present in the list). | |
| var vcCandidate *networkv1.VlanConfig | |
| for _, item := range vcs { | |
| if item.Name == vc.Name || item.DeletionTimestamp != nil { | |
| continue | |
| } | |
| if utils.IsValidMTU(utils.GetMTUFromVlanConfig(item)) { | |
| vcCandidate = item | |
| break | |
| } | |
| } | |
| // present in the list). Prefer a candidate with a non-zero MTU, and only | |
| // fall back to a zero-MTU candidate if no non-zero MTU candidates exist. | |
| var ( | |
| vcCandidateNonZero *networkv1.VlanConfig | |
| vcCandidateZero *networkv1.VlanConfig | |
| ) | |
| for _, item := range vcs { | |
| if item.Name == vc.Name || item.DeletionTimestamp != nil { | |
| continue | |
| } | |
| mtu := utils.GetMTUFromVlanConfig(item) | |
| if !utils.IsValidMTU(mtu) { | |
| continue | |
| } | |
| if mtu == 0 { | |
| // Record a zero-MTU candidate as a fallback, but keep searching | |
| // for a non-zero MTU candidate. | |
| if vcCandidateZero == nil { | |
| vcCandidateZero = item | |
| } | |
| continue | |
| } | |
| // Prefer the first non-zero MTU candidate. | |
| vcCandidateNonZero = item | |
| break | |
| } | |
| // Choose the best available candidate: prefer non-zero MTU, otherwise | |
| // fall back to a zero-MTU candidate (if any). | |
| vcCandidate := vcCandidateNonZero | |
| if vcCandidate == nil { | |
| vcCandidate = vcCandidateZero | |
| } |
| if vcCandidate != nil { | ||
| mtu := utils.GetMTUFromVlanConfig(vcCandidate) | ||
|
|
||
| // Please note that updating the MTU annotation here may be redundant, | ||
| // as all `VlanConfig`s should have the same MTU value. However, it is | ||
| // safer to update them in case the boundary conditions change in the | ||
| // future. | ||
| cnCopy.Annotations[utils.KeyUplinkMTU] = fmt.Sprintf("%v", mtu) | ||
| cnCopy.Annotations[utils.KeyMTUSourceVlanConfig] = vcCandidate.Name |
There was a problem hiding this comment.
When vcCandidate has MTU=0, this code writes the clusternetwork uplink-mtu annotation as the string "0". Elsewhere (ensureClusterNetwork) MTU=0 is treated as “default” and the annotation is set to DefaultMTU instead. This mismatch can cause the next reconcile to flip the annotation back (thrash). Consider normalizing MTU=0 to DefaultMTU before writing KeyUplinkMTU here, consistent with ensureClusterNetwork.
Do some additional code cleanup: - Rename `GetMTUFromAnnotation` to `GetMTUFromString` Related to: harvester/harvester#8783 Signed-off-by: Volker Theile <[email protected]>
fc4a3c6 to
6c275e8
Compare
Problem:
Build a cluster network, set the mtu annotation. Build a cluster network configuration. Then delete the cluster network configuration. The
network.harvesterhci.io/mtu-source-vcannotation is left dangling on the Cluster Network.Solution:
Make sure the annotations
network.harvesterhci.io/mtu-source-vcandnetwork.harvesterhci.io/uplink-mtuare updated/removed properly.Do some additional code cleanup:
GetMTUFromAnnotationtoGetMTUFromStringRelated Issue:
harvester/harvester#8783
Test plan:
ToDo