Add machine class to the Cluster API

[rsdcastro]

From @rsdcastro on January 29, 2018 22:0

This issue tracks discussion on adding machine class (as used/suggested in several API discussions) and any work required to make that happen if we decide to do it.

Copied from original issue: kubernetes-retired/kube-deploy#529

[rsdcastro]

Assigning to @roberthbailey to drive discussion and decision.

[scheeles]

@roberthbailey I know there are several discussion about the machine class. Do we have documented why we need it.

[hardikdr]

Couple of them I can recall are:

• MachineClass should bring-in re-usability of machine-spec related details even across MachineSets/Deployments. This should help us in having a more sophisticated use of machine-controllers.

• Once cluster-api gets stable enough, cluster-autoscaler community is expected to re-define the cloud interface to include only Machine/Cluster-api specifics and not maintain cloud-specific code in autoscaler-repository anymore. Currently, autoscaler relies on Node-objects and tags on ASGs[cloud specific machine-pools] to understand the available/used resources in Machines, which should then be replaced by MachineClasses- which is also the ask from them.

• Having only in-line MachienSpec could also create concerns around maintaining consistency of spec-details across all the layers of MachineDeployment/MachineSet/Machines and incase in future we decide to propogate part of those details in cluster-spec.

• There was also discussion around thinking about alternatives from only SSH based approach inside Machine-controller, where we may see multiple machine-controller-implementations per cloud-provider, one of which could be via cloud-init script or generic-shell-script. Injecting that script via MachineClass.ConfigMap/Secret looks nicer than having it in MachineSpec.ProviderConfig.

One of the concern was though,

• What really happens when MachineClass modifies?
  Ideally it could be immutable[not sure how in CRDs], but then we might be little defensive and expect only newer machines to read the modified MachineClass and behave accordingly.
  Aggressive approach could be to trigger the rolling-update then, which I believe should be configurable.

I think this thread is more about enabling both the facilities of in-line providerConfig and MachineClasses, and let user decide whichever fits best to her. I hope I have not misunderstood any points please correct otherwise.

@scheeles

[roberthbailey]

/close

Fixed by #488

[k8s-ci-robot]

@roberthbailey: Closing this issue.

In response to this:

/close

Fixed by #488

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.