@@ -149,7 +149,7 @@ Items marked with (R) are required *prior to targeting to a milestone / release*
149
149
## Summary
150
150
151
151
When a cluster has multiple apiservers at mixed versions (such as during an
152
- upgrade or downgrate ), not every apiserver can serve every resource at every
152
+ upgrade or downgrade ), not every apiserver can serve every resource at every
153
153
version.
154
154
155
155
To fix this, we will add a filter to the handler chain in the aggregator which
@@ -189,19 +189,18 @@ incorrectly or objects being garbage collected mistakenly.
189
189
190
190
## Proposal
191
191
192
- API change:
193
- * To the apiservices API, add an "alternates" clause, a list of
194
- apiservers which believe they can serve the group-version.
192
+ We will use the existing ` StorageVersion ` API to figure out which group, versions,
193
+ and resources an apiserver can serve.
195
194
196
195
API server change:
197
- * A controller adds the apiserver to the list of alternates for its built-in
198
- group-versions.
199
- * The same controller removes expired apiservers from the list. (Enabled by the
200
- apiserver identity work.)
201
196
* A new handler is added to the stack:
202
- - If the request is for a group/version the apiserver doesn't have locally (we
203
- can use the StorageVersion API), it will proxy the request to one of the
204
- alternates instead.
197
+ - If the request is for a group/version/resource the apiserver doesn't have
198
+ locally (we can use the StorageVersion API), it will proxy the request to
199
+ one of the ` serviceableBy ` s if one is available. If one is not available,
200
+ then we will return a 503 (there is a small possibility of a race between
201
+ the controller registering the apiserver with the resources it can serve
202
+ and receiving a request for a resource that is not yet available on that
203
+ apiserver).
205
204
206
205
### User Stories (Optional)
207
206
0 commit comments