-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
compute: support labelling spot instance as boolean #263
Comments
This issue feels like a fine one to add to me. It does expand the set of labels for compute instances by one per metric, but doesn't add cardinality, and will probably have conveniences down the line. I don't even think we need this as a config, to be honest, we can just straight-up add a spot boolean where:
|
@jjo and I synced up on this yesterday and came to the agreement that the best thing to do here is to simply add a new label called The rationale for a new label is
|
Closing after syncing with @the-it on fully embracing |
What
Support e.g.
--compute.spot-as-boolean-label=LABEL_NAME
(e.g. with_LABEL_NAME_=is_spot
), to set such additional label.Why
As a Spot instance is driven by "upper" level workloads' choice (when setting the nodeSelectors/taints/labels to trigger CA to allocate such specific nodes to them), with workloads explicitly knowing the rewards/risk aspects of spots. This is quite different from ondemand vs RIs (granted the latter are the only ones guaranteed to be available).
In the case of GrafanaLabs, this has grown in our recording rules to be used as
spot={true|false}
, which is now forcing us to use below relabeling trick (actually add-labelling) to set it:The above needs to be done for every you may run (especially the case if you have a centralized TSDB), note also that you need to visit every timeseries to perform this relabelling (under the context of TSDB pressure), create the two TSs sets, to then
OR
them.The text was updated successfully, but these errors were encountered: