Context
As this project matures, there's potential for some patterns to be adopted into Kubernetes core. We should establish reserved taint prefix conventions now to avoid breaking changes later.
Currently users can use ANY taint key prefix - there's no enforcement of naming conventions.
Proposed Change
Forbid below reserved prefixes for readiness taints:
readiness.k8s.io/system/*
readiness.k8s.io/core/*
readiness.k8s.io/node/*
readiness.k8s.io/device/*
readiness.k8s.io/network/*
readiness.k8s.io/storage/*
User-space prefix (allowed):
readiness.k8s.io/* (excluding reserved subpaths above)
Changes required
- Add a CRD validation for enforcing pattern for
TaintSpec.key
- Document reserved prefixes in project README and API documentation
- Update examples to follow the conventions
Context
As this project matures, there's potential for some patterns to be adopted into Kubernetes core. We should establish reserved taint prefix conventions now to avoid breaking changes later.
Currently users can use ANY taint key prefix - there's no enforcement of naming conventions.
Proposed Change
Restrict users to use only taint key prefix under
readiness.k8s.io/*Reserve certain taint key prefixes for "core" to avoid potential conflicts in the future:
Forbid below reserved prefixes for readiness taints:
readiness.k8s.io/system/*readiness.k8s.io/core/*readiness.k8s.io/node/*readiness.k8s.io/device/*readiness.k8s.io/network/*readiness.k8s.io/storage/*User-space prefix (allowed):
readiness.k8s.io/*(excluding reserved subpaths above)Changes required
TaintSpec.key