Support even more patterns of specifying images in FluxHelmRelease

[squaremo]

From @justinbarrick's testing of #1258:

A couple of third party charts do not follow any of these patterns:
brigade uses controller.registry and controller.name to form the image name.
stable/influxdb uses image.repo instead of image.repository.
stable/external-dns uses image.name.

These are probably fairly commonly used; even though we (presently) require people to vendor the charts, and they could therefore alter them, it's friendlier if they don't have to.

(This may be a good time to consider implementing some scheme so that people can specify the containers using some scheme, in the FluxHelmRelease.)

[stephenmoloney]

One pattern I see in quite a few places is

values:
  image:
  imageTag:

I don't think this is currently supported by flux.

reference: https://github.com/helm/charts/search?q=imageTag%3A&unscoped_q=imageTag%3A

[billimek]

It would be great if there was a way to tell flux what pattern to use instead of relying on a set of patterns/strings hard-coded into flux.

For example, keel provides a mechanism to define 'where' the image name and image tag are defined: https://keel.sh/v1/guide/documentation.html#Helm-example

[squaremo]

Yar, having a little language to interpret would be modestly more flexible that a set of understood patterns. (I was thinking of a similar thing for dealing with custom resources).

[hiddeco]

Before we can turn this issue into a PR we must agree on how a user should instruct the operator to look for images at certain paths in the values value.

@stefanprodan iirc you had annotations in mind; can you elaborate on this 'design'?

[stefanprodan]

I propose the following annotations:

repository.flux.weave.works/<arbitrary-name>: "path.to.image.repository"
tag.flux.weave.works/<arbitrary-name>: "path.to.image.tag"
filter.flux.weave.works/<arbitrary-name>: "glob|semver|regexp"

Here is how Jenkins could look:

kind: HelmRelease
metadata:
  annotations:
    flux.weave.works/automated: "true"
    repository.flux.weave.works/master: "Master.Image"
    tag.flux.weave.works/master: "Master.ImageTag"
    filter.flux.weave.works/master: semver:~2.60
    repository.flux.weave.works/agent: "Agent.Image"
    tag.flux.weave.works/agent: "Agent.ImageTag"
    filter.flux.weave.works/agent: glob:3.27-*
spec:
  chart:
    repository: https://kubernetes-charts.storage.googleapis.com/
    name: jenkins
    version: 0.33.0
  values:
    Master:
      Image: "jenkins"
      ImageTag: "2.60.2"
    Agent:
      Image: jenkins/jnlp-slave
      ImageTag: 3.27-1

[squaremo]

@stefanprodan How would you encode this

...
spec:
  values:
    Container:
      Image: jenkins:2.60.2

?

[stefanprodan]

@squaremo

• if tag.flux.weave.works/<name> is not specified we'll assume the tag is inlined with the image
• if filter.flux.weave.works/<name> is not specified we'll assume glob:*

[stefanprodan]

We use chart-image annotation:

kind: HelmRelease
metadata:
  annotations:
    flux.weave.works/automated: "true"
    flux.weave.works/tag.chart-image: semver:~4.0
spec:
  releaseName: redis
  chart:
    repository: https://kubernetes-charts.storage.googleapis.com/
    name: redis
    version: 5.1.3
  values:
    image:
      repository: bitnami/redis
      tag: 4.0.12

With the new format looks less confusing but more verbose:

kind: HelmRelease
metadata:
  annotations:
    flux.weave.works/automated: "true"
    repository.flux.weave.works/redis: "image.repository"
    tag.flux.weave.works/redis: "image.tag"
    filter.flux.weave.works/redis: semver:~4.0
spec:
  releaseName: redis
  chart:
    repository: https://kubernetes-charts.storage.googleapis.com/
    name: redis
    version: 5.1.3
  values:
    image:
      repository: bitnami/redis
      tag: 4.0.12