KEP-1040: Weighted borrowing

[MikeSpreitzer]

• One-line PR description: Add weighting to the borrowing between APF priority levels

• Issue link:

[MikeSpreitzer]

/cc @deads2k
/cc @wojtek-t
/cc @tkashem
/cc @linxiulei

[MikeSpreitzer]

Cutting this out because this plan did not come to fruition.

[linxiulei]

I might not have fully understood those formulae, but questions:

• why can't we just apply the previous logic -- scaling down the CurrentCL proportional to RemainingServerCL / LowerBoundSum? why do the weights have to impact this if no borrowing is happening here.
• A more direct question: I tested APF a while ago and learned a rule of "the owner keeps the shares if inuse", now would the weights break this rule? i.e. PLs with lower weights will be borrowed even when their demands are higher than their NominalCL?

[MikeSpreitzer]

First, remember that the PR that you are looking at is actually combining two changes: one is #4623 , which aims to heal the long-standing divergence between code and KEP by moving both to a middle ground, and then there is the change to add weighting to the priority levels.

It is true that when MinCLSum < RemainingServerCL < MinCurrentCLSum there is no borrowing between non-exempt priority levels, but the exempt level(s) have borrowed so much from the non-exempt ones that each must give up some concurrency. So it is actually a borrowing scenario.

Remember that you have not tested the behavior described in #4623 unless you tested its implementation in kubernetes/kubernetes#124736 .

Regarding "the owner keeps the shares if in use", I would be a little more precise: the rule is that each non-exempt level gets its nominal concurrency limit if at least that much has been in use AND the borrowing by exempt levels is not so great as to cut into that. The formulae that you have commented on concern the case where the exempt level(s) have borrowed so much that the non-exempt ones can not get their nominal concurrency limits.

[MikeSpreitzer]

/easycla

[MikeSpreitzer]

/easycla

[MikeSpreitzer]

@MikeSpreitzer

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all PRs.

This bot triages PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the PR is closed

You can:

• Mark this PR as fresh with /remove-lifecycle stale
• Close this PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all PRs.

This bot triages PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the PR is closed

You can:

• Mark this PR as fresh with /remove-lifecycle rotten
• Close this PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[linxiulei]

I feel LE should be higher than node-high & system as it can cause severe disruptions than the other two but not sure what practical difference it'd make with different weight values.

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the PR is closed

You can:

• Reopen this PR with /reopen
• Mark this PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close

[k8s-ci-robot]

@k8s-triage-robot: Closed this PR.

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the PR is closed

You can:

• Reopen this PR with /reopen
• Mark this PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[MikeSpreitzer]

/remove-lifecycle rotten
/reopen
Still being studied

[k8s-ci-robot]

@MikeSpreitzer: Reopened this PR.

In response to this:

/remove-lifecycle rotten
/reopen
Still being studied

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: MikeSpreitzer
Once this PR has been reviewed and has the lgtm label, please assign jpbetz for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• keps/sig-api-machinery/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment