prevent the potential for misconfiguration of MetricsInterval

[huntergregory]

In the agent's ConfigMap, MetricsInterval is meant to be a number in seconds: https://github.com/microsoft/retina/blob/30a128b985bc99fc8686ef21afa1cc7358dc7dfd/pkg/config/config.go#L54

But the type for MetricsInterval is time.Duration: https://github.com/microsoft/retina/blob/30a128b985bc99fc8686ef21afa1cc7358dc7dfd/pkg/config/config.go#L21 so someone could configure MetricsInterval: 5s, and unknowingly end up with an actual interval of 150 years 😬

[rbtr]

viper supports duration as config, so we should always expect this value to come in as a valid duration and not turn it in to one later

[huntergregory]

Should we deprecate this field and replace it with say MetricsIntervalDuration? If we reuse the same field, if someone continues to use the current config of MetricsInterval: 10, they would then get a 10 nanosecond interval

[ritwikranjan]

To address the potential misconfiguration of MetricsInterval, I agree with @huntergregory about introducing a new field in the YAML configuration, such as MetricsIntervalDuration. This new field would take precedence over the existing MetricsInterval, but we would include a conditional statement to maintain backward compatibility. This way, if MetricsIntervalDuration is present, it will be used; otherwise, we will fall back to MetricsInterval.

Here's a rough outline of the plan:

• Introduce the new MetricsIntervalDuration field in the YAML configuration.
• Implement a conditional check to prioritize MetricsIntervalDuration if it is set.
• Ensure that if MetricsIntervalDuration is not set, the existing MetricsInterval field will be used. We can also add a log line here to highlight that it is deprecated.

Please let me know your thoughts on this approach!

[rbtr]

@ritwikranjan plan looks good