fluxcd failed to automate helmrelease chart-image

[HaveFun83]

Describe the bug
A clear and concise description of what the bug is.

fluxcd is unable to automate a helmrelease structure / chart-image with more than two path values within the repository statement.

Example image path:
private-docker-registry.net/public/bitnami/redis:5.0.6
<registry> <repository (with more than two values)>:<imagetag>

The following helmrelease structure failed to automate the chart-image as the repository statement only accept two path values.

values:
  image:
    registry: docker.io
    repository: repo/image
    tag: version

We found the code source for this behavior here:

flux/pkg/image/image.go

Lines 145 to 161 in 07b3d3d

	elements := strings.Split(s, "/")
	switch len(elements) {
	case 0: // NB strings.Split will never return []
	return id, errors.Wrapf(ErrMalformedImageID, "parsing %q", s)
	case 1: // no slashes, e.g., "alpine:1.5"; treat as library image
	id.Image = s
	case 2: // may have a domain e.g., "localhost/foo", or not e.g., "weaveworks/scope"
	if domainRegexp.MatchString(elements[0]) {
	id.Domain = elements[0]
	id.Image = elements[1]
	} else {
	id.Image = s
	}
	default: // cannot be a library image, so the first element is assumed to be a domain
	id.Domain = elements[0]
	id.Image = strings.Join(elements[1:], "/")
	}

To Reproduce
Steps to reproduce the behaviour:

If you check-in an helmrelease with the following structure:

---
apiVersion: helm.fluxcd.io/v1
kind: HelmRelease
metadata:
  name: rabbitmq
  namespace: test
  annotations:
    flux.weave.works/automated: true
    flux.weave.works/tag.chart-image: semver:~3.8
spec:
  releaseName: rabbitmq
  chart:
    repository: https://kubernetes-charts.storage.googleapis.com/
    name: rabbitmq
    version: 6.8.4
  values:
    image:
      registry: private-docker-registry.net/public
      repository: bitnami/rabbitmq
      tag: 3.8.0-debian-9-r0

fluxcd is unable to automate the helmrelease with the following error:

ts=2019-11-12T15:52:53.944052104Z caller=loop.go:145 component=sync-loop jobID=e4f37091-fe83-3ccb-5c03-fb5fad94c2ae state=done success=false err="verifying changes: failed to verify changes: the image for container \"chart-image\" in resource \"gitops-system:helmrelease/redis-demo\" should be \"private-docker-registry.net/public/bitnami/redis:5.0.6\", but is \"private-docker-registry.net/bitnami/redis:5.0.6\""

we also tried the following

---
apiVersion: helm.fluxcd.io/v1
kind: HelmRelease
metadata:
  name: rabbitmq
  namespace: test
  annotations:
    flux.weave.works/automated: true
    flux.weave.works/tag.chart-image: semver:~3.8
spec:
  releaseName: rabbitmq
  chart:
    repository: https://kubernetes-charts.storage.googleapis.com/
    name: rabbitmq
    version: 6.8.4
  values:
    image:
      registry: private-docker-registry.net
      repository: public/bitnami/rabbitmq
      tag: 3.8.0-debian-9-r0

than the error will be

ts=2019-11-12T18:30:13.745729746Z caller=images.go:159 component=sync-loop err="fetching image metadata for private-docker-registry.net/bitnami/redis: errors:\ndenied: requested access to the resource is denied\nunauthorized: authentication required

as public/ will be ignored and stripped out

Expected behavior
A clear and concise description of what you expected to happen.

fluxcd should support a repository statement with more than 2 path values

Logs
If applicable, please provide logs of fluxd or the helm-operator. In a standard stand-alone installation of Flux, you'd get this by running kubectl logs -n default deploy/flux.

see above

Additional context
Add any other context about the problem here, e.g

• Flux version: 1.15.0
• Helm Operator version: 1.0.0-rc3
• Kubernetes version: 1.15.4
• Git provider: private gitlab
• Container registry provider: private harbor

[hiddeco]

The structure you are linking to works fine, and is actually covered by tests, as can be seen here.

Does this problem only occur for the automation of HelmRelease resources, or for all resources Flux handles? The answer to this could possibly reduce the size of the haystack, before I go looking for the needle.

[HaveFun83]

The structure you are linking to works fine, and is actually covered by tests, as can be seen here.

Does this problem only occur for the automation of HelmRelease resources, or for all resources Flux handles? The answer to this could possibly reduce the size of the haystack, before I go looking for the needle.

Thanks for looking into this issue.
The error only occurs on helmReleases with the following structure:

values:
  image:
    registry: docker.io
    repository: repo/image
    tag: version

[hiddeco]

I managed to find the issue, the problem lies with the assumption we make when we try to construct a valid image.Ref from the values we detect in the HelmRelease resource, in combination with assumptions made during the parsing of the value we pass in.

helmrelease.go:303 makes the assumption that any value we pass in there will either result in a valid image.Ref with just the Image set, or an error.

This is however not true, when we look at image.go:151, we see that the parser on their terms makes the assumption that any passed reference with 2 or more / elements automatically has a domain, and fills the values based on this rule.

I think the solution would be, to first collect all values, and then try to create an image.Ref with all the collected values, preventing a partial parse of any image element snippets that may be interpreted wrong due to missing elements.

@fons @squaremo, thoughts?

[HaveFun83]

Thanks a lot @hiddeco 🎉 🍻