Two names for one thing: flowcontrol and API Priority and Fairness

[MikeSpreitzer]

What happened?

In the rush to alpha, we merged the code with an inconsistency: we used the term "flow control" in some places, "API Priority and Fairness" in others. These two terms are used interchangeably for the same thing. This is unnecessarily confusing.

What did you expect to happen?

I expected to use one term consistently.

I think "API Priority and Fairness" is the better choice. The term "flow control" is broad and misleading. I did a web search for "flow control". The first hit was https://en.wikipedia.org/wiki/Flow_control_(data) . As you would expect from the words, the concepts there are around controlling rate rather than concurrency. The techniques listed on that web page do not include things like APF. While it is true that the two are connected, so controlling either has an effect on the other, the problem with the term "flow control" is that it suggests that rate rather than concurrency is being directly controlled.

How can we reproduce it (as minimally and precisely as possible)?

Look at the name of the feature gate. Look at the user-facing documentation. Look at the API group name. Look at the code directory structure.

Anything else we need to know?

The latest case where this inconsistency causes pain is #111222 , but this is hardly the first. The inconsistency has been present from the start.

Kubernetes version

This pain has been present from the start of this feature.

Cloud provider

N/A

OS version

N/A

Install tools

N/A

Container runtime (CRI) and version (if applicable)

N/A

Related plugins (CNI, CSI, ...) and versions (if applicable)

N/A

[MikeSpreitzer]

@kubernetes/sig-api-machinery-misc

[leilajal]

/triage accepted

[k8s-triage-robot]

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

This bot triages issues and 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 issue is closed

You can:

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

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

/lifecycle stale

[vaibhav2107]

/remove-lifecycle stale

[k8s-triage-robot]

This issue has not been updated in over 1 year, and should be re-triaged.

You can:

• Confirm that this issue is still relevant with /triage accepted (org members only)
• Close this issue with /close

For more details on the triage process, see https://www.kubernetes.dev/docs/guide/issue-triage/

/remove-triage accepted

[seans3]

/triage accepted