Closed mdbooth closed 5 months ago
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
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:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle rotten
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten
+1
@mdbooth see Add AdditionalLabels to cloudprovider.InstanceMetadata, So now IMO it is possible to just extend the cloud-provider-openstacks' InstanceMetadata with some AdditionalLabels
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.
This bot triages issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/reopen
/remove-lifecycle rotten
Please send feedback to sig-contributor-experience at kubernetes/community.
/close not-planned
@k8s-triage-robot: Closing this issue, marking it as "Not Planned".
My specific use case here is adding a node label representing the specific hypervisor a node is on. This is an extremely common request on OpenStack, where not all deployments use availability zones. Even in deployments which use availability zones, the ability to schedule a workload to survive node maintenance within a single AZ is still a common request.
There is no well-known label representing a node's hypervisor. In fact, to the best of my knowledge this has been specifically discussed and rejected in the past. Consequently I would likely implement this as an OpenStack-specific node label.
I could write a new controller for OpenStack, but the existing node controller very nearly does this already. We could add a new field to InstanceMetadata:
This should have no impact on cloud providers which do not implement it.
I propose this rather than a new
Hypervisor
field as I suspect it may be generally useful for a number of use cases over time in addition to this one.