It’s probably not the user’s job to do preflight checks. Instead, key consistency between Helm and the daemon/operator should be ensured during development.

Commit 48f86b3 does not match "(?m)^Signed-off-by:".

Please follow instructions provided in https://docs.cilium.io/en/stable/contributing/development/contributing_guide/#developer-s-certificate-of-origin

Commits 48f86b3, 954ad2e do not match "(?m)^Signed-off-by:".

Please follow instructions provided in https://docs.cilium.io/en/stable/contributing/development/contributing_guide/#developer-s-certificate-of-origin

Commit 48f86b3 does not match "(?m)^Signed-off-by:".

Please follow instructions provided in https://docs.cilium.io/en/stable/contributing/development/contributing_guide/#developer-s-certificate-of-origin

Commit 48f86b3 does not match "(?m)^Signed-off-by:".

Please follow instructions provided in https://docs.cilium.io/en/stable/contributing/development/contributing_guide/#developer-s-certificate-of-origin

This is on the way towards what we need here but at least two significant changes are needed:

1. Rather than check a .yaml file, this needs to grab the Cilium config (ConfigMap) from the current cluster, and check its contents. cilium-dbg is the CLI which is available in all running Cilium pods, such as those used by the preflight.enabled Deploymet.
2. An invocation of this command needs to be added to the Cilium preflight Deployment Helm template, with the appropriate exit status upon failure.

See https://github.com/cilium/cilium/blob/main/install/kubernetes/cilium/templates/cilium-preflight/deployment.yaml#L52 for the example of cilium-dbg preflight validate-cnp and it's related implementation.

Hi @asauber Thanks for the feedback!
I’ve addressed both points by updating the preflight Deployment to invoke cilium-dbg and validating the deployed Cilium ConfigMap from the cluster. Please take another look.
FYI, this commit (205c589) fixes the validator readiness change introduced by the Helm refactor in PR #16896 (file-diff).

/test

Hi @asauber @gandro
The CI issues have been fixed and the checks are now passing on my fork.
Could you please approve the CI workflows, Many thanks!

/test

Build seems broken

445.9 cmd/preflight_k8s_valid_configmap.go:46:17: cannot use operatorCmd.Operator (value of type func() "github.com/cilium/hive/cell".Cell) as "github.com/cilium/hive/cell".Cell value in argument to hive.New: func() "github.com/cilium/hive/cell".Cell does not implement "github.com/cilium/hive/cell".Cell (missing method Apply)

Build seems broken

Thanks for pointing this out. I've pushed a fix and the CI is now green.

Thanks. Please don't forget to squash your commits again

/test

/test

The CI: Conformance L3-L4 only run failed. It seems unlikely that this failure is related to this PR.

Most PodToCIDR scenarios fail due to client-side timeouts when connecting to the server.

  [.] Action [no-policies/pod-to-cidr:external-172201100-0: cilium-test-1/client3-74887fc475-b64ks (10.244.3.246) -> external-172201100 (172.20.1.100:443)]
  ❌ command "curl --silent --fail --show-error --connect-timeout 2 --max-time 10 -4 -w %{local_ip}:%{local_port} -> %{remote_ip}:%{remote_port} = %{response_code}\n --output /dev/null --retry 3 --retry-all-errors --retry-delay 3 https://172.20.1.100:443" failed: command failed (pod=cilium-test-1/client3-74887fc475-b64ks, container=client3): command terminated with exit code 28

This appears to be similar to #43787.

Please note that pushing to the branch invalidates the test result (thus making the PR unmergable). Unless there's something to fix, I recommend not pushing to the branch.

Understood. I now have a better understanding of the timing around rebasing and pushing. Thanks for the guidance!

/test

Thanks to gandro, asauber, and squeed for the guidance in helping me complete my first PR!