6 tests fail KubeclientConfigTest#test_explicit_secure Expected false to be truthy.

[pravi]

Originally reported in debian https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1032551

kubeclient 4.11 also fails the same way. This may be because we have ruby 3.1 and openssl 3.0.

[cben]

Thanks. That's not ruby-dependent, it's some TLS certs that expired again (used by tests only, never by kubeclient itself)
=> regenerated now on both v4.y branch (from where we currently make releases) and future master.

@pravi Do you need a new release for debian to pick up the fix? (despite no user-visible changes, only tests)

---

I suppose the "time-bomb" nature of these tests is suboptimal for debian...

• If you build infrastructure can run podman/docker, you could try switching the package tests to run env TESTOPTS="--verbose" test/config/update_certs_k0s.rb instead of bundle exec rake test. That launches a local temp k0s cluster, and generates fresh certs every time :+1:, then runs the full unit tests, plus extra integration tests: test/test_real_cluster.rb :+1:.
• However, k0s image used by that script was not compiled by Debian so that'd probably violate self-contained / reproducible build principles... :-1: Is k8s packaged by debian in any form that's easy to launch a local cluster?

There must certainly be easier ways to generate CA + certs than creating a cluster :rofl:
I hadn't bothered to find one because I wanted those test/test_real_cluster.rb integration tests anyway.

• Another idea is to skip those tests (or better just that assertion assert(context.ssl_options[:cert_store].verify(context.ssl_options[:client_cert]))) outside of update_certs_k0s.rb mode where they're fresh :thinking:
  That way they'd never "time-bomb"!
  • However, we currently know to run k0s only on Linux, so this would reduce CI coverage of TLS aspects on Mac & Windows. Well, maybe skip by default but opt-in to that assertion in our CI, but not recommend it for downstream distros.

[pravi]

@pravi if there is a patch/commit, I can pick it up. I don't think we can create a cluster during build, if it is pulling something outside the archive. Even if there was an image, that would be difficult to pull during package builds. We can only pull other packages during builds. If there is an easier way to generate certificates before tests, without creating a cluster, that would as well. If there is an easier way to skip those tests, that should be enough for now.

[pravi]

For now I have disabled this assertion https://salsa.debian.org/ruby-team/ruby-kubeclient/-/commit/0aea66eab2af3fdbec0d36b936ed4429fc49efd7