Change Request: Do not derive internal number types from config file number types.

[ghost]

Would it be agreeable/possible to derive the types from the APIC API itself?

see: google/jsonnet#683

I looked at this over in my fork: https://github.com/josdotso/prometheus_aci_exporter/pulls?q=is%3Apr+is%3Aclosed

Please let me know if I should PR my commits to your repo.

[RavuAlHemio]

I think this merits further discussion.

The current architecture allows the user to choose, through judicious modification of the config file, the kind of comparison to be performed on the value. If the config file contains a string value, a string comparison is performed. If the config file contains an integral value, the value provided by the APIC, even if it's a string or a floating-point number, is compared as an integer.

(There seems to be consensus among Python modules how to handle JSON's -- well, JavaScript's -- decision to have only one numeric data type: the built-in json module as well as the external modules PyYAML and ruamel.yaml parse numbers as int if they contain no decimal point and as float if they do. Since Python 3's int is a big-int type, there is no loss of precision with larger numbers, something more likely if all JSON numeric values were treated as float.)

Also, it appears that the Python prometheus module converts any gauge metric value into float anyway, even if it was originally integral.

Those are the reasons behind the current behavior. Do you have a use case negatively affected by this?

[ghost]

Thanks for the background.

Yes, my broken use case is to generate my aci exporter config from/with jsonnet (see link above). Jsonnet outputs JSON or YAML, but it doesn't use the decimal point as a hint as you describe folks doing in Python. If you look at the jsonnet issue I opened (link above) it is the logical-inverse of this issue for aci exporter. That is, I'm asking them to allow me to write 100.0 in jsonnet and have it not become 100 in its conversion to JSON and YAML. Sounds like JSON is out of alignment with YAML in this special inference using the decimal point.

Therefore, my preference would be for some way ACI exporter to accept what JSON -> YAML would give -- which is apparently 100 not 100.0. Perhaps the best thing to do is to make the type an explicit user field. Similar to the way Prometheus gives you gauge vs. counter. That way, ACI exporter could typecast more deterministically.

Thanks!

[RavuAlHemio]

Sorry for keeping silent for a week; my job had me focused elsewhere.

I've introduced a value_type key that can be "float", "int" or "str". The value from the APIC is converted to this type relatively early in the value transformation process; I hope this helps your situation.

[ghost]

Thanks so much, @RavuAlHemio . I will check this out as soon as I can.