Update Aggregated Discovery for 1.26

[Jefftree]

KEP-3352

• One-line PR description: Updating milestone and comments for 1.26

• Issue link: Aggregated Discovery #3352

• Other comments:

[Jefftree]

/cc @lavalamp @smarterclayton @deads2k @liggitt
/cc @apelisse @seans3 @alexzielenski

[apelisse]

Sounds good.

[deads2k]

Also worth noting that this API is a GET, so the client doesn't provide a schema'd type, and this is not persisted in the cluster?

[Jefftree]

I think this is covered by the first point that Discovery is a non-resource API class. Would you like it to be elaborated?

[deads2k]

I think this is covered by the first point that Discovery is a non-resource API class. Would you like it to be elaborated?

we have resource APIs that are not persisted, but still have client provided schema. See subjectaccessreviews. It even happens for other GET APIs, like pods/logs.

I think being explicit here will help future us.

[deads2k]

@smarterclayton my understanding was that this still started with an alpha featuregate, but a beta serialization. So effectively it was off-by-default, but stable for clients if available.

[liggitt]

I don't really understand an alpha feature gate gating a beta API... off by default seems reasonable, but we can do a beta off-by-default gate

[smarterclayton]

I think from a clarity perspective "off by default" is the first phase of non-resource APIs and the next phase is "on by default and can't evolve it" (i.e. metrics is 'stable' once we turn it on by default since we have no versioning scheme). We have no question here whether we want to evolve our discovery API to add "at once" retrieval (so it's not alpha because we need feedback first). We have a versioning scheme here, so "off by default" but "beta" doesn't prevent us from evolving or killing the API either. So the necessary preconditions for not being treated as an alpha "experiment" are in place, in my mind.

I think based on what we've demonstrated we would be comfortable with users turning this flag on within one release, because the mechanisms give us the ability to evolve, and if we decided not to graduate it would be no different from any other beta feature being dropped. So beta gate is based on assessed confidence in the feature.

[deads2k]

I don't really understand an alpha feature gate gating a beta API.

The featuregate is also gating the new controllers that are providing the data and the (hopefully settling) etag calculation across multiple HA servers. The serialization is based on experience, so beta stability serialization is logical, but the code providing the data to serialize are fully novel.

If we're going to require an "on by default beta" before going GA, what benefit have we gained by exposing unvetted controllers as beta in their first release? Calling our off-by-default alpha is consistent, doesn't preclude using a more stable serialization, and keeps maturity graduation consistent. Vendors can (and do) turn alpha features on for testing and maybe even production: see p&f and graceful node shutdown.

So beta gate is based on assessed confidence in the feature.

Is this confidence a thing that any sig can say about any feature they wish? Choosing a couple at semi-random

1. pleg performance improvements
2. node swap
3. kubelet credential providers

[apelisse]

If we're going to require an "on by default beta" before going GA, what benefit have we gained by exposing unvetted controllers as beta in their first release?

I think the plan was to do "off-by-default" beta followed by "on-by-default" GA.

Is this confidence a thing that any sig can say about any feature they wish?

I think this is a combination of the 9 points enumerated above.

[deads2k]

/lgtm
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: deads2k, Jefftree

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

[deads2k]

/label tide-merge-method-squash

[k8s-ci-robot]

@deads2k: The label(s) /label tide-merge-method-squash cannot be applied. These labels are supported: api-review, tide/merge-method-merge, tide/merge-method-rebase, tide/merge-method-squash, team/katacoda, refactor, lead-opted-in, tracked/no, tracked/out-of-tree, tracked/yes. Is this label configured under labels -> additional_labels or labels -> restricted_labels in plugin.yaml?

In response to this:

/label tide-merge-method-squash

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.