It's not possible to install Kong through helm chart

[zarelit]

Environment

Tanka version v0.24.0 KIC chart v0.10.2 (https://github.com/Kong/charts/blob/main/charts/ingress/Chart.yaml)

Scenario

I've been trying to set up Kong Ingress controller with something like this

local tanka = import 'github.com/grafana/jsonnet-libs/tanka-util/main.libsonnet';
local helm = tanka.helm.new(std.thisFile);
{
  _config:: {
    ns: 'kong',
  },
  kong_ingress_controller: helm.template('kong', './path/to/kong/ingress', {
    namespace: $._config.ns,
    includeCRDs: true,
  }),
  kong_namespace: {
    apiVersion: 'v1',
    kind: 'Namespace',
    metadata: {
      name: $._config.ns,
    },
  },
}

The chart has been vendored using

tk tool charts add-repo kong https://charts.konghq.com
tk tool charts add kong/[email protected]

Outcome

• with includeCRDs: false Kong it's not being installed correctly
• with includeCRDs: true tanka is not able to render the manifests because of a duplicated resource

note that officially only Helm is supported so, for instance, they removed the all-in-one yaml manifest

Further debugging information

The ingress controller chart is actually an umbrella chart that renders nothing but calls the "kong" chart twice with different parameters, once to install the controller and another time to install the gateway.

This means that the output from Helm actually has the same non-namespaced resource (a CRD) twice, so Tanka bails out with an error.

Conclusion

How should tanka handle this duplicated resource? Is there a way to ask it to "take the first/last" or "merge"?

[Duologic]

Perhaps you can call it twice, once with CRDs and controller enabled and explicitly gateway disabled. Second the other way around.

[zarelit]

The problem lies in the fact that the kong chart template emits the very same CRDs regardless of the values. So the possible workarounds are:

Reimplement the umbrella chart in jsonnet

• instead of templating kong/ingress we template kong/kong twice, one for controller and one for ingress
• includeCRDs = true only for one component

Pros: it's still declarative and you can tk apply once Cons: if the umbrella chart changes upstream, the workaround does not work anymore

Template the umbrella chart twice with different values

• we template kong/ingress twice, with values for controller and for ingress
• includeCRDs = true only for one call of helm.template

Pros: it's still declarative and you can tk apply once, compatible with upstream chart as long as the values don't change Cons: leaves user wondering why we are templating the same thing twice

Template the umbrella chart once but apply twice

• kong/ingress templated only once in the jsonnet code
• change values and apply twice
• includeCRDs= true only in one apply call

Pros: committed code looks like we're just applying an helm chart Cons: not declarative, what values have been applied before needs to be documented

[zarelit]

Can we have a relaxed mode for duplicated resources for niche cases like this one?

[Duologic]

I was able to get it execute this way:

local tanka = import 'github.com/grafana/jsonnet-libs/tanka-util/main.libsonnet';
local helm = tanka.helm.new(std.thisFile);
{
  _config:: {
    ns: 'kong',
  },
  kong_ingress_controller: helm.template('kong', './charts/ingress/', {
    namespace: $._config.ns,
    includeCRDs: true,
    values+: {
      gateway+: { enabled: false },
    },
  }),
  kong_ingress_gateway: helm.template('kong', './charts/ingress/', {
    namespace: $._config.ns,
    includeCRDs: false,
    values+: {
      controller+: { enabled: false },
    },
  }),
  kong_namespace: {
    apiVersion: 'v1',
    kind: 'Namespace',
    metadata: {
      name: $._config.ns,
    },
  },
}

[zarelit]

@Duologic Thank you for your help, that's the mid option described above and it works. I still feel it is a workaround and would like to see a way to tell Tanka "yes there are duplicated resources, deal with it". So I'm going to close this issue about kong. Let me know if I should open another one for a feature request "relaxed duplicated resources". If you feel this is not needed or in general not in the scope of tanka, I won't ask for it.

[Duologic]

The duplication protection prevents unintended ambiguity. Imagine you have a Deployment defined twice, but one of them has replicas: 1 and the other replicas: 10, which value should Tanka choose? This kind of ambiguity leads to mistakes down the line and making it harder to debug.

Or with other words, the Helm chart should probably not spit out the CRDs twice.