helm: avoid generating ConfigMapList

[kaworu]

According to the Kubernetes documentation, List objects should not appear in requests.

See also prometheus-operator/kube-prometheus#1735

[kaworu]

This intend to fix a helm lint warning, before this patch we have

% helm lint --debug --with-subcharts --values ./install/kubernetes/cilium/values.yaml ./install/kubernetes/cilium
==> Linting ./install/kubernetes/cilium
[WARNING] templates/hubble/dashboards-configmap.yaml: object name does not conform to Kubernetes naming requirements: "": metadata.name: Invalid value: "": a lowercase RFC 1123 subdomain must consist of lower case alphanumeric characters, '-' or '.', and must start and end with an alphanumeric character (e.g. 'example.com', regex used for validation is '[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*')

1 chart(s) linted, 0 chart(s) failed

and after the patch:

% helm lint --debug --with-subcharts --values ./install/kubernetes/cilium/values.yaml ./install/kubernetes/cilium
==> Linting ./install/kubernetes/cilium

1 chart(s) linted, 0 chart(s) failed

[chancez]

According to the Kubernetes documentation, List objects should not appear in requests.

I don't see anywhere in the documentation that it says that specifically. Unless you mean this note:

Note:
Keep in mind that the Kubernetes API does not have a kind named List.

kind: List is a client-side, internal implementation detail for processing collections that might be of different kinds of object. Avoid depending on kind: List in automation or other code.

Which I believe is talking specifically about kind: List, not kind: FooList (the prior isn't a real API type, the latter is: kubectl explain podlist vs kubectl explain list)

Which leads me to: is this PR actually necessary? NVM, I see that the helm lint fails, annoyingly, this should be valid, but I see the motivation at least.

[chancez]

Functionally this looks fine. We lost the if $files check, but that should be fine since we range over $files which will produce nothing if $files is empty.

[kaworu]

[…] We lost the if $files check, but that should be fine since we range over $files which will produce nothing if $files is empty

It wasn't lost, it was removed 😉

[kaworu]

/test

Job 'Cilium-PR-K8s-1.16-kernel-4.9' failed:

Click to show.

Test Name

K8sKafkaPolicyTest Kafka Policy Tests KafkaPolicies

Failure Output

FAIL: Found 1 k8s-app=cilium logs matching list of errors that must be investigated:

If it is a flake and a GitHub issue doesn't already exist to track it, comment /mlh new-flake Cilium-PR-K8s-1.16-kernel-4.9 so I can create one.

[kaworu]

/test-runtime

EDIT: previous run here, error was

[13:44:00] FAIL: ipsec_linux_test.go:122: IPSecSuitePrivileged.TestUpsertIPSecEndpoint
[13:44:00]
[13:44:00] ipsec_linux_test.go:146:
[13:44:00]     cleanIPSecStatesAndPolicies(c)
[13:44:00] ipsec_linux_test.go:206:
[13:44:00]     c.Fatalf("Can't delete XFRM state: %v", err)
[13:44:00] ... Error: Can't delete XFRM state: no such process
[13:44:00]
[13:44:00] level=error msg="Error while getting xfrm stats" error="error due to some reason" subsys=ipsec
[13:44:00] level=error msg="Error while getting xfrm stats" error="error due to some reason" subsys=ipsec
[13:44:00] level=error msg="Error while getting xfrm stats" error="error due to some reason" subsys=ipsec
[13:44:00] OOPS: 6 passed, 1 FAILED

Re-running to see whether it is a flake or not.

[kaworu]

/test-1.16-4.9

EDIT: previous run here, error

FAIL: Found 1 k8s-app=cilium logs matching list of errors that must be investigated:
level=error