[1479 ] Make probes in hub configurable

[mrow4a]

Closes #1479

[consideRatio]

I'd like to see both the hub and proxy deployment's configurable with the same options. That way we avoid breaking the expectancy that if we can configure one we should be able to configure the other, something I believe will cause confusion otherwise.

Sidetrack

Hmmm.. I wonder if we can apply some neat trick to not have to hardcode too much here, but instead merge fields from the passed probes.

Hmmm... One would do something like this.

# 1: inspect if the probe is enabled
# 2: load the defaults as a object
# 3: merge the provided values with the default object

Nevermind, it requires a lot of added complexity to load the default stuff, I've done similar things like this before and it can be quite a mess, the crux is that anything written in a Helm template file is text and is troublesome to get back in to an object that can be manipulated as an object.

Back on track

Okay, then lets decide what to support to be configurable among the valid probe fields: https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#probe-v1-core

Perhaps we settle with periodSeconds and initialDelaySeconds for now?

[mrow4a]

@consideRatio if we have lots of defaults maybe this makes sense. The goal is to avoid having too much things in values.yaml, is that correct ? Could you give me some example of existing code to see?

Regarding probe defaults themselves, yes periodSeconds and initialDelaySeconds seem reasonable as a start, and will be easy to add later.

[consideRatio]

@mrow4a sorry to bug you with that sidetrack, I saw Helm 3 was released now, and with Helm 3 things will be easier I think so let's not get stuck in heavy patterns like the one I considered in the sidetrack so to say. (But here are examples: values.yaml + a helm template merging that with other stuff)

Regarding probe defaults themselves, yes periodSeconds and initialDelaySeconds seem reasonable as a start, and will be easy to add later.

I agree! Aim for that (without the overly complicated merge stuff i linked to).

[mrow4a]

@consideRatio done :)

[consideRatio]

I like it! A future tweak to consider in another PR is to let the initial delay be tweaked to likely make the proxy ready as quick as possible, perhaps the hub also assuming for example the pod is running already and a hub restarts.

[consideRatio]

Thank you @mrow4a for your work on this!