fix duration regex about prometheus-k8s-operator HOT 4 CLOSED

@sed-i The regular expression of the official docs is not something I would like to allow since this permits a "0s" time interval (apart from being rather verbose). If you can not find pressing reason why such durations should be allowed then I am inclined to close this ticket.

from prometheus-k8s-operator.

In the prometheus source for the client side I see both the long form and the short form being used

• https://github.com/prometheus/prometheus/blob/5a754bc043b8e8c2d57cf906386734a73761e2a2/web/ui/react-app/src/utils/index.ts#L53
• https://github.com/prometheus/prometheus/blob/5a754bc043b8e8c2d57cf906386734a73761e2a2/web/ui/static/js/prom_console.js#L166

Didn't dive into go code.

from prometheus-k8s-operator.

In the prometheus source for the client side I see both the long form and the short form being used

That is a good observation. Though both their forms allow null values like "0s" and I am not aware of any reason why we would want to allow that. Hence I placed the restriction that leading digit must be non-zero. In any case we can always reopen this issue in the future if it crops up.

from prometheus-k8s-operator.

The duration must be greater than 0, which is actually sort-of at adds with the actual regex. Except that prometheus overtly checks for a return value of 0 (ok from the parser) and re-raises an error.

For the actual config, though, this is tricky. Which is actually checked from prometheus/common, so 0 is ok, (the type is declared here, and the SetValue() call here will call back out to Set in prometheus/common, which checks model.ParseDuration, which does allow zeros).

And even negative values... for some reason, the importance of either is actually verified later.

All of that is a long way of saying "the code paths were walked, 0 is ok, 5d1w is not", so despite the verbosity and allowing zero, the "long" regexp is the correct one.

from prometheus-k8s-operator.