Upgrade to Micrometer 1.0.6

[jkschneider]

Resolves #13746.

A couple notes:

1. Authorization key access has shifted to be lazily evaluated on each publish internally in push-based registries that require them. The purpose of this was to allow users to rotate keys at runtime.

2. This PR contains two commits, the second of which adds 3 new properties to the configuration of InfluxDB. While I'd typically reserve additions like this for a minor release, I think that these properties were an "error of omission" earlier. We've gotten feedback that retention policy is a critical thing to configure on any production Influx database. If you decide not to allow this in 2.0.4, please cherry pick to the master branch or I can open a separate PR.

[wilkinsona]

Thanks, Jon. I guess it’s too late now, but the new duration properties would have been more consistent with the rest of Boot if they were a Duration. It would ensure consistent handling of mapping a String to a Duration across all of Boot’s properties. Could they perhaps be overloaded?

[snicoll]

(e.g. 2h, 52w)

@jkschneider do I understand that you've replicated Spring Boot's Duration format? It is important if we want to expose Duration on our side as we need to give a String that would work. Can you explain a bit more how that format works? Can we pass back a number of ms for instance?

[izeye]

@snicoll Looking at the code, it's for the Influx durations which are different from the Spring Boot ones.

[snicoll]

Thanks Johnny!

[jkschneider]

@wilkinsona In InfluxProperties we can make them Duration if you'd like, but then we'll have to write serialization logic to stuff them back into strings in InfluxPropertiesConfigAdapter. Ultimately, we have to ship a string on to Influx.

[wilkinsona]

Thanks, @jkschneider. I'm torn on this now. The benefit of a String -> Duration -> String round-trip would be that we'd get an early failure if the user provides a value that's malformed. If we just pass the String straight through the failure won't occur till the call to Influx is made. The downside is that if a user if familiar with Influx, they may instinctively expect to be able to use Influx's duration format and, as @izeye notes above, it is subtly different to Boot's. On balance, I'm leaning towards passing a String straight through.

[izeye]

How about relaxing String to Duration conversion rules in Spring Boot to be able to accommodate the Influx durations if they are reasonable?

[snicoll]

Isn't that breaking the harmonization we've made for Duration? I know this one is subtle as it's reproducing a similar yet different format but I think I'd prefer us to be consistent. I expect us to also drop the duration part of the property name as we've done in other places.

[wilkinsona]

Isn't that breaking the harmonization we've made for Duration?

No, I don't think it is.

In all the other places where we use Duration, the value that's passed into the component we're configuring is, I believe, a number. Using Duration provides flexibility around the number's unit. In this case, the value that's passed into the component we're configuring is a String.

I expect us to drop the duration part of the property name as we've done in other places.

That would leave us with properties named retention and retentionShard. I don't think they make sense. DURATION and SHARD DURATION are clauses in the CREATE DATABASE command. Combined with some other clauses they create a retention policy for the database. I think the current property names reflect what they do accurately and concisely.

[wilkinsona]

How about relaxing String to Duration conversion rules in Spring Boot to be able to accommodate the Influx durations if they are reasonable?

Unfortunately, I don't think u or µ is reasonable as it just means micro with no unit. They have ns for nanoseconds and ms for milliseconds which makes u or µ all the more confusing as it looks like it's millionths of anything.

[snicoll]

One more argument to put on the balance for this is tooling support (Duration is or will be supported whereas this particular String needs a parser on its own which probably means no support at all). I guess it's no surprise if that's the main reason I am pushing for this.

Perhaps I am also expecting Spring Boot users to be more at ease with what they know in Spring Boot vs. the specificities of influx. If I am right, that should feel weird that there is a well-supported and documented format for durations in general but this one particular property behaves differently.

[wilkinsona]

I think the key thing here is that this isn't a java.time.Duration but an InfluxDB duration. It's unfortunate that the term is overloaded, but they are separate things and I now think we should treat them as such.

Given that we have no control over the format of an InfluxDB duration, and there's no guarantee that it won't diverge further from a java.time.Duration, I've come to the conclusion that it would be a mistake to use java.time.Duration as the type of the property. Doing so would back us into a corner and may make it impossible for a user to specify a value that's perfectly legal in InfluxDB but that we would not want to or would not be able to support in our String to java.time.Duration converter.

[snicoll]

Thanks for the feedback. I agree this is the proper course of action.