Automatic merge from submit-queue.
Volume topology aware scheduling design
Proposal for a smarter scheduler that influences PV binding.
Part of kubernetes/features#121
/sig storage
/sig scheduling
/cc @kubernetes/sig-storage-proposals @kubernetes/sig-scheduling-proposals
Automatic merge from submit-queue.
Update Example conventions
**Why this PR is needed**
Currently `kubectl-conventions.md` contains incorrect conventions for command examples. File currently stipulates that example commands should start with a `$`, this is incorrect.
Currently conventions stipulate that command example comments should terminate with a period. This is overly restrictive and trivial. Conventions would be better if this was relaxed to allow developer discretion.
**What this PR does**
Remove `$` convention and stipulate explicitly that command examples **do not** start with a `$`. Remove convention stipulating command examples terminate with a period.
Automatic merge from submit-queue.
Propose a feature to troubleshoot running pods
This feature allows troubleshooting of running pods by running a new "Debug Container" in the pod namespaces.
This proposal was originally opened and reviewed in kubernetes/kubernetes#35584.
This proposal needs LGTM by the following SIGs:
- [ ] SIG Node
- [ ] SIG CLI
- [ ] SIG Auth
- [x] API Reviewer
Work in Progress:
- [x] Prototype `kubectl attach` for debug containers
- [x] Talk to sig-api-machinery about `/debug` subresource semantics
Automatic merge from submit-queue. .
Update generator to use WHAT variable
Having to set two different variables is confusing. Changed this to look at the `WHAT` envvar and match on a suffix.
Fixes#1126.
cc: @jamiehannaford
Automatic merge from submit-queue. .
Clarify relationship of KEP to release note process
I'm opening this up to have a discussion on what the relationship between a KEP and the release note process is. I see KEPs being most useful for things that will often span releases. I *want* us to think bigger and across multiple releases. Often times a KEP will be discussed and accepted before and outside of the release cycle.
I've also moved some stuff around so that this doc stands more on its own vs. being a "delta" on our current process. In a years time this will be our current process and this won't read as clearly.
I believe it is time to adopt a new development process given the
current scale of Kubernetes. The inadequacy of our current process
is particularly apparent within SIGs with cross project concerns
such as SIG Release, SIG Testing, SIG Architecture, and SIG PM
so additional process around proposing changes to Kubernetes is
suggested.
Automatic merge from submit-queue. .
Restore sig apps zoom url
When the README and other files for a SIG were autogenerated the zoom meeting URL for sig apps changed. This restores to the previous URL.