ManageIQ/kubeclient

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

pravi opened this issue ยท 3 comments

pravi commented

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 commented

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 ๐Ÿ‘, then runs the full unit tests, plus extra integration tests: test/test_real_cluster.rb ๐Ÿ‘.
  • However, k0s image used by that script was not compiled by Debian so that'd probably violate self-contained / reproducible build principles... ๐Ÿ‘Ž 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 ๐Ÿคฃ
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 ๐Ÿค”
    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 commented

@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.