Label Data Typing

[cameronbrunner]

@davidopp

There needs to be a method to specify the data type of a label when it is something other than a string. In #18261 strings can be interpreted as integers but there is no way to represent a values that are natively numbers as numbers throughout Kubernetes. Kubernetes should additionally support float, boolean, and integer labels. The additional datatypes are most useful when integrating with third party schedulers, reporting, and monitoring solutions allowing for a consistent and accurate representation of the values in all systems.

[resouer]

This is interesting. Is it possible for you to give some explicit examples of this use case here?

[davidopp]

In the worst case we can encode the type in the label name (for example, num_cores implies an integer, is_foo implies a boolean, etc.), in addition to using the operator to imply the type. I agree this requires some kind of schema (though perhaps it could be hardcoded), unlike if you had explicit types. As for float, do we want to encourage people to use it? So far we've been using things like millicores to represent as integers. Floats are always a mess to deal with and life is simpler if we can avoid them.

[cameronbrunner]

With well defined built in resources we could probably avoid the need for floats like you did for cores by defining a minimum increment and then scaling appropriately. I imagine that this could get cumbersome when kubernetes adds full support for custom resources where things could have many significant digits and scaling to an integer value could yield an awkward value. Once again this would be seen in something like a reporting interface that has to potentially display these values in a user friendly way. An example here would be standard system load... we would have to say that we round to 100ths and then multiply by 100 and call it centiload. If someone wants more resolution, lets say to the 1000ths then we would have milliload.

Thinking a bit more about it perhaps the encoding for numerical fields should include the scale factor... so instead of just 'num_' we could additionally have 'centi_', 'milli_', 'micro_', etc. when encoding numbers that have been scaled. This could significantly reduce the need for a floating point data type.

[davidopp]

Thinking a bit more about it perhaps the encoding for numerical fields should include the scale factor... so instead of just 'num_' we could additionally have 'centi_', 'milli_', 'micro_', etc. when encoding numbers that have been scaled. This could significantly reduce the need for a floating point data type.

Label keys are namespaced and can be set by users. I guess a namespace could by convention choose keys with the syntax you're describing. We could say the labels published by kubernetes.io/ follow the convention, and the labels published using the mechanism in #19082 would be in kubernetes.io/

[bgrant0607]

No floats:
https://github.com/kubernetes/kubernetes/blob/master/docs/devel/api-conventions.md#primitive-types

[bgrant0607]

Why is this important?

[cameronbrunner]

The primary reason for having a method of data typing is to allow for third party tools reporting and monitoring tools to better insight into the meaning of the data that is made available. Currently in Kubernetes CPU and Memory are typed and have their own suffix's for managing scale. Since everyone know the types its very easy to make tools that consume these metrics.

In the near term we will be adding domain scoped labels to pods that have special meaning to our add-on scheduler and eventually we will have a reporting tool that consumes these labels. It would be great if other tools could see and the labels and it would be great if our reporting tool could work with labels other system components might set.

I am definitely agree with no floats as long we can provide a general scaling suffix scheme for encoding numbers into strings.

[davidopp]

As we've discussed a workaround is just to adopt a convention of having a portion of the key name specify the type.

[0xmichalis]

/sig api-machinery

[fejta-bot]

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.

Prevent issues from auto-closing with an /lifecycle frozen comment.

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

[bgrant0607]

I think this is addressed by resource extension:
kubernetes/community#782