Aggregated Discovery #3352
Comments
k8s-ci-robot
added
the
needs-sig
|
/sig api-machinery |
k8s-ci-robot
added
sig/api-machinery
Priyankasaggu11929
added
the
tracked/yes
|
/milestone v1.25 |
Priyankasaggu11929
added
the
stage/alpha
|
Hello @Jefftree 👋, 1.25 Enhancements team here. Just checking in as we approach enhancements freeze on 18:00 PST on Thursday June 16, 2022. For note, This enhancement is targeting for stage Here's where this enhancement currently stands:
Looks like for this one, we would just need to get the open KEP PR #3364 merged by the Enhancements Freeze. For note, the status of this enhancement is marked as |
|
Hello @Jefftree 👋, just a quick check-in again, as we approach the 1.25 enhancements freeze. Please plan to get the open KEP PR merged before enhancements freeze on Thursday, June 23, 2022 at 18:00 PM PT. For note, the current status of the enhancement is at |
|
With KEP PR #3364 merged now, the enhancement is ready for the upcoming Enhancements Freeze. For note, the status is now marked as |
|
Hello @Jefftree 👋, 1.25 Release Docs Shadow here. This enhancement is marked as ‘Needs Docs’ for the 1.25 release. Please follow the steps detailed in the documentation to open a PR against the dev-1.25 branch in the k/website repo. This PR can be just a placeholder at this time and must be created by August 4. Also, take a look at Documenting for a release to familiarize yourself with the docs requirement for the release. Thank you! |
|
Hi @Jefftree, Enhancements team here again 👋 Checking in as we approach Code Freeze at 01:00 UTC on Wednesday, 3rd August 2022. Please ensure that the following items are completed before the code-freeze:
Currently, the status of the enhancement is marked as Thanks :) |
|
Hey @Jefftree , reaching out again as we approach Code Freeze at 01:00 UTC on this Wednesday i.e 3rd August 2022. The status of the enhancement is still marked as |
|
Hello, we will be dropping this enhancement for 1.25. Thanks! |
|
Thanks for the update @Jefftree ! I have marked this enhancement as |
Priyankasaggu11929
added
tracked/no
|
If you're moving forward with this, please update the kep.yaml that just merged as it has milestone 1.25 still :) |
|
/milestone v1.26 |
k8s-ci-robot
added
the
lead-opted-in
meganwolf0
moved this from At Risk for Code Freeze
to Tracked for Code Freeze
in 1.30 Enhancements Tracking
drewhagen
moved this from Tracked for Code Freeze
to At Risk for Docs Freeze
in 1.30 Enhancements Tracking
drewhagen
moved this from At Risk for Docs Freeze
to Tracked for Code Freeze
in 1.30 Enhancements Tracking
drewhagen
moved this from Tracked for Code Freeze
to Tracked for Doc Freeze
in 1.30 Enhancements Tracking
|
Hi @Jefftree 👋, 1.31 Enhancements Lead here. Since this KEP has been graduated to GA in v1.30 and the status marked as implemented, we can close this issue. /remove-label lead-opted-in |
k8s-ci-robot
removed
the
lead-opted-in
This change makes the `RESTMapper` use [AggredatedDiscovery][0] if available. `AggregatedDiscovery` is beta and thus enabled by default since Kube 1.28. What this means in particular is that during startup, we will always do a request to `/api` and `/apis`. If `AggregatedDiscovery` is enabled, that is all we have to do. If not, we have to do a third request. The behavior for reloading remains the same: Do one request unless the request didn't include a version. In that case we have to find the group. If the group is unknown, we will keep on doing a request to `/api` and one to `/apis` to find it. If it is found we are again done in the `AggregatedDiscovery` case and have to do a third request otherwise. All in all this means that with `AggregatedDiscovery` enabled, the only case where this is worse is if the client interacts with only one `GroupVersion`, as we end up doing one additional api request. If it is disabled, we effectively waste two api requests. [0]: kubernetes/enhancements#3352
This change makes the `RESTMapper` use [AggredatedDiscovery][0] if available. `AggregatedDiscovery` is beta and thus enabled by default since Kube 1.28. What this means in particular is that during startup, we will always do a request to `/api` and `/apis`. If `AggregatedDiscovery` is enabled, that is all we have to do. If not, we have to do a third request. The behavior for reloading remains the same: Do one request unless the request didn't include a version. In that case we have to find the group. If the group is unknown, we will keep on doing a request to `/api` and one to `/apis` to find it. If it is found we are again done in the `AggregatedDiscovery` case and have to do a third request otherwise. All in all this means that with `AggregatedDiscovery` enabled, the only case where this is worse is if the client interacts with only one `GroupVersion`, as we end up doing one additional api request. If it is disabled, we effectively waste two api requests. [0]: kubernetes/enhancements#3352
This change makes the `RESTMapper` use [AggredatedDiscovery][0] if available. `AggregatedDiscovery` is beta and thus enabled by default since Kube 1.28. What this means in particular is that during startup, we will always do a request to `/api` and `/apis`. If `AggregatedDiscovery` is enabled, that is all we have to do. If not, we have to do a third request. The behavior for reloading remains the same: Do one request unless the request didn't include a version. In that case we have to find the group. If the group is unknown, we will keep on doing a request to `/api` and one to `/apis` to find it. If it is found we are again done in the `AggregatedDiscovery` case and have to do a third request otherwise. All in all this means that with `AggregatedDiscovery` enabled, the only case where this is worse is if the client interacts with only one `GroupVersion`, as we end up doing one additional api request. If it is disabled, we effectively waste two api requests. [0]: kubernetes/enhancements#3352
|
The Kubernetes project currently lacks enough contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
k8s-ci-robot
added
the
lifecycle/stale
This change makes the `RESTMapper` use [AggredatedDiscovery][0] if available. `AggregatedDiscovery` is beta and thus enabled by default since Kube 1.28. What this means in particular is that during startup, we will always do a request to `/api` and `/apis`. If `AggregatedDiscovery` is enabled, that is all we have to do. If not, we have to do a third request. The behavior for reloading remains the same: Do one request unless the request didn't include a version. In that case we have to find the group. If the group is unknown, we will keep on doing a request to `/api` and one to `/apis` to find it. If it is found we are again done in the `AggregatedDiscovery` case and have to do a third request otherwise. All in all this means that with `AggregatedDiscovery` enabled, the only case where this is worse is if the client interacts with only one `GroupVersion`, as we end up doing one additional api request. If it is disabled, we effectively waste two api requests. [0]: kubernetes/enhancements#3352
This change makes the `RESTMapper` use [AggredatedDiscovery][0] if available. `AggregatedDiscovery` is beta and thus enabled by default since Kube 1.28. What this means in particular is that during startup, we will always do a request to `/api` and `/apis`. If `AggregatedDiscovery` is enabled, that is all we have to do. If not, we have to do a third request. The behavior for reloading remains the same: Do one request unless the request didn't include a version. In that case we have to find the group. If the group is unknown, we will keep on doing a request to `/api` and one to `/apis` to find it. If it is found we are again done in the `AggregatedDiscovery` case and have to do a third request otherwise. All in all this means that with `AggregatedDiscovery` enabled, the only case where this is worse is if the client interacts with only one `GroupVersion`, as we end up doing one additional api request. If it is disabled, we effectively waste two api requests. [0]: kubernetes/enhancements#3352
|
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle rotten |
k8s-ci-robot
added
lifecycle/rotten
Feature has graduated and issue can be closed. /close |
|
@Jefftree: Closing this issue. In response to this:
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. |
This change makes the `RESTMapper` use [AggredatedDiscovery][0] if available. `AggregatedDiscovery` is beta and thus enabled by default since Kube 1.28. What this means in particular is that during startup, we will always do a request to `/api` and `/apis`. If `AggregatedDiscovery` is enabled, that is all we have to do. If not, we have to do a third request. The behavior for reloading remains the same: Do one request unless the request didn't include a version. In that case we have to find the group. If the group is unknown, we will keep on doing a request to `/api` and one to `/apis` to find it. If it is found we are again done in the `AggregatedDiscovery` case and have to do a third request otherwise. All in all this means that with `AggregatedDiscovery` enabled, the only case where this is worse is if the client interacts with only one `GroupVersion`, as we end up doing one additional api request. If it is disabled, we effectively waste two api requests. [0]: kubernetes/enhancements#3352
This change makes the `RESTMapper` use [AggredatedDiscovery][0] if available. `AggregatedDiscovery` is beta and thus enabled by default since Kube 1.28. What this means in particular is that during startup, we will always do a request to `/api` and `/apis`. If `AggregatedDiscovery` is enabled, that is all we have to do. If not, we have to do a third request. The behavior for reloading remains the same: Do one request unless the request didn't include a version. In that case we have to find the group. If the group is unknown, we will keep on doing a request to `/api` and one to `/apis` to find it. If it is found we are again done in the `AggregatedDiscovery` case and have to do a third request otherwise. All in all this means that with `AggregatedDiscovery` enabled, the only case where this is worse is if the client interacts with only one `GroupVersion`, as we end up doing one additional api request. If it is disabled, we effectively waste two api requests. [0]: kubernetes/enhancements#3352
This change makes the `RESTMapper` use [AggredatedDiscovery][0] if available. `AggregatedDiscovery` is beta and thus enabled by default since Kube 1.28. What this means in particular is that during startup, we will always do a request to `/api` and `/apis`. If `AggregatedDiscovery` is enabled, that is all we have to do. If not, we have to do a third request. The behavior for reloading remains the same: Do one request unless the request didn't include a version. In that case we have to find the group. If the group is unknown, we will keep on doing a request to `/api` and one to `/apis` to find it. If it is found we are again done in the `AggregatedDiscovery` case and have to do a third request otherwise. All in all this means that with `AggregatedDiscovery` enabled, the only case where this is worse is if the client interacts with only one `GroupVersion`, as we end up doing one additional api request. If it is disabled, we effectively waste two api requests. [0]: kubernetes/enhancements#3352
This change makes the `RESTMapper` use [AggredatedDiscovery][0] if available. `AggregatedDiscovery` is beta and thus enabled by default since Kube 1.28. What this means in particular is that during startup, we will always do a request to `/api` and `/apis`. If `AggregatedDiscovery` is enabled, that is all we have to do. If not, we have to do a third request. The behavior for reloading remains the same: Do one request unless the request didn't include a version. In that case we have to find the group. If the group is unknown, we will keep on doing a request to `/api` and one to `/apis` to find it. If it is found we are again done in the `AggregatedDiscovery` case and have to do a third request otherwise. All in all this means that with `AggregatedDiscovery` enabled, the only case where this is worse is if the client interacts with only one `GroupVersion`, as we end up doing one additional api request. If it is disabled, we effectively waste two api requests. [0]: kubernetes/enhancements#3352
This change makes the `RESTMapper` use [AggredatedDiscovery][0] if available. `AggregatedDiscovery` is beta and thus enabled by default since Kube 1.28. What this means in particular is that during startup, we will always do a request to `/api` and `/apis`. If `AggregatedDiscovery` is enabled, that is all we have to do. If not, we have to do a third request. The behavior for reloading remains the same: Do one request unless the request didn't include a version. In that case we have to find the group. If the group is unknown, we will keep on doing a request to `/api` and one to `/apis` to find it. If it is found we are again done in the `AggregatedDiscovery` case and have to do a third request otherwise. All in all this means that with `AggregatedDiscovery` enabled, the only case where this is worse is if the client interacts with only one `GroupVersion`, as we end up doing one additional api request. If it is disabled, we effectively waste two api requests. [0]: kubernetes/enhancements#3352
and others
Enhancement Description
One-line enhancement description (can be used as a release note): Aggregated Discovery
Kubernetes Enhancement Proposal: KEP
Discussion Link:
Primary contact (assignee): @Jefftree
Responsible SIGs: SIG API Machinery, SIG CLI
Enhancement target (which target equals to which milestone):
Alpha
k/enhancements) update PR(s):k/k) update PR(s):Beta
k/enhancements) update PR(s): KEP-3352 Aggregated Discovery to Beta #3722k/k) update PR(s):k/website) update(s): Doc update for KEP-3352 Aggregated Discovery website#40024Stable
k/enhancements) update PR(s): KEP-3352: Aggregated Discovery to GA #4472k/k) update PR(s):k/website) update(s):Please keep this description up to date. This will help the Enhancement Team to track the evolution of the enhancement efficiently.
The text was updated successfully, but these errors were encountered: