Limit the Random Hash in the MachineSet Name

[AxiomSamarth]

What this PR does / why we need it:
Currently, MachineSet names are with variable length of the random hash. The MCM is also not limiting the random hash in the machineset names. But if we limit the length of the random hash, it will help to reduce the occurrences of the CSI issue till it is fixed upstream

Which issue(s) this PR fixes:
Fixes #461

Special notes for your reviewer:

Release note:

NONE

[prashanth26]

/invite @danielfoehrKn I don't think this change hinders the g/g worker actuator code by any chance. However, just wanted you to take a look at this change.

@AxiomSamarth - Also did you confirm though both scenario based testing and code logic that this wouldn't trigger rolling updates of existing machine sets backed by deployments?

[AxiomSamarth]

@prashanth26 I tested this with the fresh deployment. I will test to see if this triggers any rolling updates of existing machine sets backed by deployment.

[amshuman-kr]

@prashanth26 @hardikdr Perhaps a stupid question. Why do we not simply use GenerateName and let the kube-apiserver figure out the name generation?

[danielfoehrKn]

I don't think this change hinders the g/g worker actuator code by any chance. However, just wanted you to take a look at this change.

The generic worker actuator deploys the Machine Deployment - how the MCM generates the MachineSets etc. is unrelated I think.

[prashanth26]

@danielfoehrKn - Okay thanks for that. I thought the same but wanted to just confirm from you.

[AxiomSamarth]

@prashanth26 @hardikdr Perhaps a stupid question. Why do we not simply use GenerateName and let the kube-apiserver figure out the name generation?

@amshuman-kr Hi Amshu, seems like even with the GenerateName, the random hash generated will be 5-8 characters long if I understand correctly. So, again, there is a possibility of variable length. Limiting it to 5 would help avoid that variable length of the machine set name is the assumption in this context.

[prashanth26]

@prashanth26 @hardikdr Perhaps a stupid question. Why do we not simply use GenerateName and let the kube-apiserver figure out the name generation?

Back then this code was copied over from the replicaSet controller code. And this was the code there back then i think. Even now they use kind of similar code ther.

[amshuman-kr]

Back then this code was copied over from the replicaSet controller code. And this was the code there back then i think. Even now they use kind of similar code ther.

Thanks for the clarification. Is there any hurdle to start using GenerateName now (like support for older kubernetes versions etc.)? If not, I would suggest to start using GenerateName already. Not in all the places in one shot, of course. Just starting here and later in other places when we touch them. WDYT?

[hardikdr]

Is there any hurdle to start using GenerateName now (like support for older kubernetes versions etc.)?

That's actually a good suggestion, and we should probably move to generateName eventually for all the occurrences.
I am not completely aware of all the effects of the move and would like to be a little more cautious before that change.

As this is only a ramp-up task for Samarth, and he is still getting familiar with the code-base, I'd refrain from having him test e2e with this pov.
For now, let's go ahead with the current PR, and later create an issue and follow-up separately for the generateName feature.

Ref : #502

[hardikdr]

We should probably cross-check once, if this change has any side-effect on the rolling-update, hopefully not.

/lgtm otherwise.
Thanks for the PR :)

[prashanth26]

/lgtm