Stability Initiative

[clux]

We plan to provide a series of stability guarantees, policies, and a stable governance via CNCF, for kube-rs going forward.

This is an umbrella issue tracking progress and major outstanding work before we mark ourselves as stable. It pertains to the Stability category on the roadmap.

Background

This is part of a set of stable client requirements plus extra requirements that we would like to provide on top so that users can feel safe choosing kube-rs as a reliable set of libraries to build upon kubernetes.

There's been a lot of introductory work in this area already as part of our in-progress CNCF setup (#584), along with stability work in #508 (which this issue replaces).

A lot of this is document pertains to process/policy writing that needs to be argued for/against, and then their subsequent implementations and enforcement of these proposed processes through continuous integration.

Tasks

Community & Governance

• adopting the cncf code of conduct - #593
• architecture.md - #416
• initial roadmap / governance / security policy / maintainers file / issue templates - #670
• cncf sandbox application #584
• move org-wide policies into .github repo or website - #kube-rs/website/issues/11
• achieve CII best practices badge #737

Policies & Clarity:

• documented release process - via release.toml by release team
• minimum rust version (msrv) defined and under CI - #668
• N documented users - #735
• document support level per-platform - kube-rs/website#18
• document kubernetes flavour test levels per-platform - kube-rs/website#18
• panic policy -> delayed- #634
• library documentation #[deny(missing_docs)] at root of repos
  • remove last few #[allow(missing_docs)] overrides - #728
  • doctest readme - #736
• minimum supported kubernetes version - #684 - kube-rs/k8s-pb#10 and kube-rs/website#19
• deprecation policies - kube-rs/website#18
  • decide on a strategy for deprecated attrs - kube-rs/website#18
  • document strategy and for how long we deprecate - currently have done 5 versions (e.g. try_flatten_applied) - kube-rs/website#18
• document interface changes pre 1.0 - kube-rs/website#18
• document change policy post 1.0 - delayed - #923
• investigate a way to gradually introduce unstable features - kube-rs/website#18

Security:

• trust and authority of dependencies
  • cargo deny multiple-versions - #711
  • cargo deny unknown git sources - #727
  • cargo deny strict licenses and rustsec vulnerabilities - #611
• security policy
• cargo audit on CI
• limit dependabot lock-step upgrade issues:
  • kube as a super-crate facade - #651
  • re-export generated structs from kube? - maybe post k8s-pb
• #[forbid(unsafe_code)] for cargo-geiger 🔒 - #734
• fortify secrets with secrecy wrappers - #751

Continuous Integration:

• run tests in strategy.matrix for linux/mac
• extend unit test set to windows - #566
• provide coverage builds and test policies for prs - #745
• integration/e2e extensions:
  • convert e2e test to run as matrix job against clusters (k3d first) - #924
  • run integration as a matrix job against min supported kubernetes versions - #924
  • extend e2e test matrix job to be able to run on both k3d and extra cluster - we would need one first
  • use cloud clusters to point to in CI? (maybe sponsored or / cncf service / cncf community)
  • extend e2e test to cover token renewal -> delayed #832

[clux]

We've accomplished the main overarching thing we wanted to achieve to at least mark us stable w.r.t. the client stability doc:

🎉

So will close this as I'm tired of having this massive issue around (not a huge fan of the ergonomics of umbrella issues after having tried them).

There are three minor points that did not make it and will need some clarity/improvements in the future, but they have their own issues:

• panic policy - #634
• e2e test for cover token renewal - #832
• document change policy post 1.0 - #923