flow control metrics: switch to snake_case for labels

[adtac]

Fixes #24895

/cc @MikeSpreitzer

[adtac]

ref PR in k/k: kubernetes/kubernetes#96236

[netlify]

Deploy preview for kubernetes-io-master-staging ready!

Built with commit 5ab1d97

https://deploy-preview-24905--kubernetes-io-master-staging.netlify.app

[sftim]

I recommend adding a note callout ({{< note >}} … {{< note >}}) on line 333 or thereabouts to tell readers that these metric labels have changed case in release v1.20

and that readers running older versions of Kubernetes should switch to the documentation for the version that they are running.

[sftim]

/hold
kubernetes/kubernetes#96236 is not yet merged

[sftim]

/sig api-machinery
/sig instrumentation

[adtac]

@sftim added a note about k8s < v1.20. Also, kubernetes/kubernetes#96236 has been merged, so:

/hold cancel

[MikeSpreitzer]

/LGTM
Thanks!

[k8s-ci-robot]

LGTM label has been added.

Git tree hash: de0c918b195eabe02dcf2e4addd92ab2c19603c8

[MikeSpreitzer]

@sftim : I think this is ready for you to take another look and approve.

[adtac]

/assign @sftim

[lavalamp]

Tech LGTM here.

@sftim is there any reason to wait on this longer? I think it's good to go.

[sftim]

/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: MikeSpreitzer, sftim

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

The pull request process is described here

Needs approval from an approver in each of these files:

• content/en/OWNERS [sftim]

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

[sftim]

D'oh. This should have been on the dev-1.20 branch, right?

[lavalamp]

Oh yes, probably. Sorry!

[sftim]

I'll get it reverted - can we get another PR opened that targets the dev-1.20 branch instead?

[adtac]

I understand why I'd need to create a new PR targeting dev-1.20, but can I know why the merge into master needs to be reverted? As far as I understand, we'd still need the same changes in 1.21 and beyond. Not too familiar with the release cut process, sorry.

[sftim]

We shouldn't tell readers

If you're running Kubernetes versions v1.19 and earlier, you should refer to the documentation for your version.

if they are looking at the v1.19 docs - it's unhelpfully recursive.

[sftim]

BTW the master branch is docs for the current release

[MikeSpreitzer]

@sftim : Please help me understand what you are saying about the master branch. Are you saying that right now the master branch is docs for release 1.19 and that when 1.20 is released the master pointer (in the sense that a branch is just a pointer to a commit) will be switched to point to the same commit as dev-1.20?

[sftim]

The Kubernetes website uses a continuous deployment process. This table should explain how we use branches.

Scenario	Branch
Existing or new English language content for the current release of Kubernetes	master (pending future rename)
(English) content for a feature change release	The branch which corresponds to the major and minor version the feature change is in, using the pattern dev-<version>. For example, if a feature changes in the v1.20 release, then add documentation changes to the dev-1.20 branch.
Content in other languages (localizations)	Use the localization's convention.

[sftim]

We will merge the dev-1.20 branch into master by approving PR #24138; this happens as part of the release process. At that point, Netlify will see a change to master and will deploy the updated website.