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
Besides the filtering/selection use case this would make it possible to create a special label format that would allow propagate certain labels to node selectors and/or tolerations.
The use case expressed here is to make sure that certain launcher pods could be scheduled to certain nodes using the nodeSelector.
Maybe node labels can be put to work for this use case.
The text was updated successfully, but these errors were encountered:
taking the clab labels and just putting them on the launcher deployments (like srl1 labels go to srl1 deployment labels, ceos1 labels to go ceos1 deployment labels, etc.) is a great idea imo. should do that regardless.
the only way I see changing the node selector setup right now would be to breaking change it to make it like the resources field where its a map of nodename-->our scheduling object. obviously I am down to break things at any point and also we are 0.x so I extra dont care 😁 . but thats probably the only way I think adding this would make sense.
Looking forward to this as it would facilitate mixed clusters with a subset of nodes supporting nested virtualization. This enables cost optimizations for large setups.
https://containerlab.dev/manual/nodes/#labels
Besides the filtering/selection use case this would make it possible to create a special label format that would allow propagate certain labels to node selectors and/or tolerations.
The use case expressed here is to make sure that certain launcher pods could be scheduled to certain nodes using the nodeSelector.
Maybe node labels can be put to work for this use case.
The text was updated successfully, but these errors were encountered: