fix(restart): handle daemonset names with dashes in InferNextStartType - #1934
magic-peach wants to merge 1 commit into
Conversation
InferNextStartType looks up the daemonset by taking podName[0] after splitting on '-', which only works if the daemonset itself is a single word. Install via the helm chart and the fullname template can easily produce something like 'cluster-kmesh', so a pod named cluster-kmesh-x7g2p was getting looked up as just 'cluster', which doesn't exist - the Get() call fails and it silently falls back to Normal start every time instead of detecting Restart/Update. Pulled the derivation out into daemonSetNameFromPod, which strips only the last dash segment instead of keeping only the first one. Signed-off-by: Akanksha Trehun <akankshatrehun@gmail.com>
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
Codecov Report❌ Patch coverage is
... and 1 file with indirect coverage changes Continue to review full report in Codecov by Harness.
🚀 New features to boost your workflow:
|
/kind bug
InferNextStartType grabs the daemonset name by splitting POD_NAME on "-" and taking the first piece. That only works if the daemonset is literally named one word. Install through the helm chart with a release name that doesn't already contain "kmesh" and kmesh.fullname renders as e.g. "cluster-kmesh", so a pod like cluster-kmesh-x7g2p gets looked up as daemonset "cluster", which doesn't exist. The Get() errors out and it always falls back to Normal start, even on a real restart where it should detect Restart/Update and reuse the existing bpf state.
Pulled the derivation into its own daemonSetNameFromPod so it strips only the trailing random suffix instead of keeping only the first segment.