Reserved cores.

[erictune]

Thanks for wanting to add a feature to Kubernetes!

If you are just requesting a new feature, but have no plans to start on it, please file an issue at http://github.com/kubernetes/kubernetes

If you are ready to lead the implementation of a new feature, then this is the place for you.
You will be responsible for guiding your feature through completion, and asking the right people for approvals. Please don't file an issue here until you or your team is ready to start work on a new feature.

You can use the checkboxes below to track your progress. First, give this issue a title that describes the feature
you want to add. Then click "Submit new issue". Then follow the checklist that appears.

You can delete the text above once you have read it.
Please keep the text below. You can come back and edit the checklist later using the edit button.

• Propose your feature. See [Advice for proposing features].
  • Start with a < 1 page description in an issue comment below this.
  • Refer to existing issues on http://github.com/kubernetes/kubernetes
  • Request an initial feature review by mentioning @kubernetes/new-feature-reviewers.
  • Keep pinging that every few days if you don't get a response.
  • If the feature is simple, the approver might ask you to write a longer design doc.
  • If there is a design doc, that goes in a PR under github.com/kubernetes/kubernetes/docs/proposals. Link that PR on this issue.
  • Once you get LGTM from a feature reviewer, you can check this checkbox, and the reviewer will apply the "feature-lgtm" label.
• Write code and tests get them merged.
  • Use as many PRs as you need. Write tests in the same or different PRs, as is convenient for you.
  • As each PR is merged, add a comment to this issue referencing the PRs. Code goes in the http://github.com/kubernetes/kubernetes repository,
    and sometimes http://github.com/kubernetes/contrib, or other repos.
  • When you are done with the code, apply the "code-complete" label.
  • When the feature has user docs, please add a comment mentioning @kubernetes/feature-complete-reviewers and they will
    check that the code matches the proposed feature and design, and that everything is done, and that there is adequate
    testing. They won't do detailed code review: that already happened when your PRs were reviewed.
    When that is done, you can check this box and the reviewer will apply the "code-complete" label.
• Write user docs and get them merged in.
  • User docs go into http://github.com/kubernetes/kubernetes.github.io.
  • When the feature has user docs, please add a comment mentioning @kubernetes/docs-reviews.
  • When you get LGTM, you can check this checkbox, and the reviewer will apply the "docs-complete" label.
• And so on...

[erictune]

I want to be able to reserve cores for certain pods.
The pod spec will get a new field called spec.container[].request.reserved_cores. Kubelet will allocate cores on a best effort basis, with no guarantees, and with topological-awareness being best-effort also. The kubelet will report node.spec.free_reserved_cores. The scheduler will prefer not to schedule a pod where there are fewer reserved cores than requested, but will still place where not possible if it wants. Kubelet will set the reserved cores on the requesting container when creating it. I will not restrict existing containers without reserved cores because you cannot change that value through docker without restarting things.

[erictune]

@erictune/design-reviewers please review.

[erictune]

Hey, eric, this is eric. Can you link to any relevant past issues in http://github.com/kubernetes/kubernetes? search for cores.

[erictune]

Sure, eric, I'll do that and ping you back when it is done.

[erictune]

kubernetes/kubernetes#10983 is about using --cpuset-cpus

[sarahnovotny]

if you keep talking to yourself in issues, there will be questions.

[erictune]

For the demo, I want to do something like this but with you being the other half of the conversation.

[sarahnovotny]

works for me.