cluster-api-provider-vsphere
cluster-api-provider-vsphere copied to clipboard
kubernetes-sigs
Apply VM tags based on machine label prefix
/kind feature
Describe the solution you'd like The machine spec should define some label prefix to indicate which tags and values should be applied to VMs. For example:
labels:
vsphere.infrastructure.cluster.x-k8s.io/tag-region: west
vsphere.infrastructure.cluster.x-k8s.io/tag-zone: 2
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /lifecycle stale
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /lifecycle rotten
Now that it's v1alpha3, sure. But this was from last fall when it was v1alpha2, and:
- The above model is extensible to tags of any kind/purpose
- Didn't require changing the VSphereMachine spec
FWIW, I think this issue was frozen because there was a misunderstanding of failure domains and CAPI and the CPI's Zones interface. This is for the latter. However, I didn't have time to respond yesterday when I saw this frozen. I intended to ping @vincepri later about it. Thanks for following up @ncdc!
Perhaps we could have fields for region & zone as well as a map for tags. Merge them together, but the region & zone fields override any value in the map for the same keys.
@ncdc - we'd still need a way to convey other random tags desired by the users ?
That's what Andy meant by the map for tags. Whether it's still needed is unclear, but it's not the worst feature to include.
Do we still have a use case for this feature given the TagIDs field in the clone spec?
