You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is that the same approach we want to take with treasuremap in Airship 2? This should be enabled by a combination of the sync labeller and host generation label support: https://review.opendev.org/c/airship/airshipctl/+/797130
Assuming the same answer for sub-clusters, at least for the workloads being provided by the sub-cluster provider?
The text was updated successfully, but these errors were encountered:
I think another advantage is that an operator can easily manipulate these labels to move a particular workload off a particular node where it is having issues. I guess with the sync labeller this could still work but the changes would need to be made to the BMH instead of the kubernetes node directly, so that the changes don't get undone.
Let's take an approach where we have a label catalog, that defines groups of labels. In the hosts.yaml we will refer to the label group. And the host generator will expand appropriately.
Problem description (if applicable)
In Airship 1 we were driving node selection via workload-specific labels applied to nodes, so that nodeSelectors rarely needed to be changed:
https://github.com/airshipit/treasuremap/blob/v1.9/global/profiles/host/cp.yaml#L57-L116
https://github.com/airshipit/treasuremap/blob/v1.9/global/profiles/host/dp.yaml#L57-L64
Proposed change
Is that the same approach we want to take with treasuremap in Airship 2? This should be enabled by a combination of the sync labeller and host generation label support: https://review.opendev.org/c/airship/airshipctl/+/797130
Assuming the same answer for sub-clusters, at least for the workloads being provided by the sub-cluster provider?
The text was updated successfully, but these errors were encountered: