Maksytka/kind
1
0
Fork 0
mirror of https://github.com/kubernetes-sigs/kind.git synced 2025-12-01 07:26:05 +07:00
Code Issues Packages Projects Releases Wiki Activity
Files
856f984eefaf8e74881dfaa62f1b2acb023b7ac9
kind/site/content/docs/contributing/project-scope.md
Benjamin Elder 95440514d9 fixup some styling, add dedicated descriptions, add dockershim notice 
sorry for the big commit, I've been hacking to get things looking good and out quickly with all the dockershim concern out there 🤷‍♂️
2020-12-02 16:54:13 -08:00

4.2 KiB
Raw Blame History

title, menu, toc, description
title menu toc description
Project Scope
main
parent identifier weight
contributing project-scope 2
true This document outlines some scoping and major priorities for kind. See also: the [1.0 roadmap], and the [1.0 tracking milestone]. [1.0 roadmap]: /docs/contributing/1.0-roadmap [1.0 tracking milestone]: https://github.com/kubernetes-sigs/kind/milestone/2

Priorities (from greatest to least)

P-1: Bootstrapping the kind Project Itself

Stakeholders:

  • kind maintainers
  • kind contributors

Covered Work:

  • Releases & tooling
  • Automated image publishing
  • Documentation bootstrapping (IE this site)
  • Enough Kubernetes testing to test kind itself (Kubernetes Conformance tests)
  • Setting up linters and other tools to verify quality
  • Setting up a recurring subproject meeting

P0: Support Testing Kubernetes

Stakeholders:

Covered Work:

  • Limited workloads / e2e testing
  • Cluster bring-up (IE kubeadm)
  • Kubernetes build (and currently install, but that may be problematic for cross-platform #166)
  • Node skew, client skew (kubectl / e2e versions)
  • Image publishing
  • Kubernetes CI tooling and jobs
  • Most everything in the 1.0 roadmap
  • ...

P1: Support Testing Kubernetes Applications

Stakeholders: Various projects both inside & outside the Kubernetes Org.

Covered Work:

Most of the necessary work should be covered under P1: Support Testing Kubernetes Applications, however there is some additional work.

  • Improve "kind as a library"
    • better and more controllable logging
    • generally more control over output
    • example usage & documentation
    • better / tighter API contracts
  • Most of the rest should be covered by improving "kind the binary" outlined above
  • ...

P2: Provide Cheap Bootstrap Clusters for the Cluster-API

Stakeholders:

P3: Extended Testing Not Covered Above

Stakeholders:

  • Indeterminate / many

Possibly supporting various things that we cannot reasonably test today including:

  • "node" tests, e.g. reboot
  • Upgrades, downgrades
  • Anything depending on ingress
  • Anything depending on persistent storage / PVs
  • Testing the cluster-api proper with some sort of machine provisioning
  • Device plugin, e.g. GPU
  • ...

Several of these make sense but are not possible with the current tooling and will require a reasonable amount of design and thought to do well. Some of them may not be solve-able in a good way, but are at least technologically feasible to explore.

Out of Scope

Some things we can likely never cover in a reasonable way:

  • Cloud provider / CCM
  • Some of the node testing (which portions exactly is currently unclear)
  • Being an alternative to "docker compose" etc.
  • Replacing Phippy ❤️ 🦒 ❤️
  • ...