Update dry-run KEP with kubectl plan

[julianvmodesto]

For server-side dry-run GA, we want to support --dry-run=server.

This change updates the KEP to describe this plan, as discussed in kubernetes/kubernetes#85652

[k8s-ci-robot]

Hi @julianvmodesto. Thanks for your PR.

I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

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/test-infra repository.

[julianvmodesto]

/sig cli

[julianvmodesto]

cc @apelisse @soltysh @smarterclayton @seans3

[julianvmodesto]

Oh, for backwards compatibility, we need to both support --dry-run=true and --dry-run=false. So we need --dry-run=client, --dry-run=server, and --dry-run=none, where --dry-run=true is equivalent to --dry-run=client, and --dry-run=false is equivalent to --dry-run=none.

[julianvmodesto]

Starting a WIP here: kubernetes/kubernetes#86143

[soltysh]

Nits, but this lgtm.

[soltysh]

Since this was beta, you can remove this in one release, honestly (compare https://kubernetes.io/docs/reference/using-api/deprecation-policy/#deprecation)

[julianvmodesto]

Ah nice, updated

[apelisse]

/lgtm

[apelisse]

The KEP lives in sig-apimachinery, since it's mostly an api-machinery feature (even though this specific change is CLI related). I'll ask someone to approve since Maciej already approved.

[deads2k]

I don't think is the place where you want to end up. I expected the command to eventually have --dry-run mean "server-side dry run". How would you manage the transition of the default?

[julianvmodesto]

As a human user or in CI, the primary use case is to validate that kubectl apply --dry-run -f path/to/manifests works. We do want to change the default to --dry-run=server, and the expectation would not be broken for human users or CI with the new default.

I'll update the KEP to say we're introducing --dry-run=client for backward compatibility in this release (1.18), but will deprecate this option in 1 release after (1.19), and remove it in 3 releases (1.21)? Such that we end in a state where none and server are the only supported values in 3 releases (1.21), with --dry-run=server being the default.

[julianvmodesto]

@apelisse mentioned you discussed ensuring the dry run flag is always explicitly set instead of implicitly defaulted.

Updated the KEP to deprecate the default unset flag behavior and require that the flag is always set in the future.

PTAL @deads2k @soltysh

[deads2k]

As a human user or in CI, the primary use case is to validate that kubectl apply --dry-run -f path/to/manifests works. We do want to change the default to --dry-run=server, and the expectation would not be broken for human users or CI with the new default.

I'll update the KEP to say we're introducing --dry-run=client for backward compatibility in this release (1.18), but will deprecate this option in 1 release after (1.19), and remove it in 3 releases (1.21)? Such that we end in a state where none and server are the only supported values in 3 releases (1.21), with --dry-run=server being the default.

This plan ensures that users get a clear, breaking signal that the default they were using before is broken/gone and makes that pain happen all at once. It will be disruptive, but the alternative is silently changing behavior in ways that users aren't likely to notice until something bad happens. I think this is a reasonable way forward.

/approve
/assign @soltysh

@soltysh owns lgtm for CLI

[soltysh]

👍 for the plan proposed.
/lgtm

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: apelisse, deads2k, julianvmodesto, soltysh

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:

• keps/sig-api-machinery/OWNERS [deads2k]

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