Support resource configuration on VSphere Machine API

[rikatz]

/kind feature

Describe the solution you'd like
Today the vSphere Machine API supports configuring an amount of CPU and memory, but no limit. In this case, setting this counters just represents "a count" but a user or an admin cannot limit and have some QoS over what is requested and what is guaranteed (as per Kubernetes resource/limits model).

Setting memory and cpu requests and limits is supported on VMOperator mode.

The desire here is, following the simpler approach as possible, add the CPU and Memory requests and limits on VSphereMachineCloneSpec and also inheriting this to the VSphereMachineTemplate.

Then, during the clone process, consume this information and create the underlying virtual machines containing also the right resource configuration

Anything else you would like to add:

Environment:

• Cluster-api-provider-vsphere version:
• Kubernetes version: (use kubectl version):
• OS (e.g. from /etc/os-release):

/assign

[sbueringer]

Sounds good!

[rikatz]

just an update, I didn't had time to touch back this and library implementation yet but I plan on doing it during Kubecon week :D

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[zhanggbj]

I assume this is still valid.
/remove-lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[neolit123]

/remove-lifecycle stale