Skip to content

Commit 59ee6ce

Browse files
author
Han Kang
committed
move discovery consistency to unresolved section
1 parent 8cd8369 commit 59ee6ce

File tree

1 file changed

+18
-14
lines changed
  • keps/sig-api-machinery/3903-unknown-version-interoperability-proxy

1 file changed

+18
-14
lines changed

keps/sig-api-machinery/3903-unknown-version-interoperability-proxy/README.md

Lines changed: 18 additions & 14 deletions
Original file line numberDiff line numberDiff line change
@@ -192,20 +192,6 @@ incorrectly or objects being garbage collected mistakenly.
192192
We will use the existing `StorageVersion` API to figure out which group, versions,
193193
and resources an apiserver can serve.
194194

195-
We will also need to make discover reports the same set of resources everywhere. We propose
196-
routing discovery requests from old-apiservers to the new api-server, so that all discovery
197-
requests reflect the newest one. We specifically rule out merging discovery docs, because
198-
merging discovery is:
199-
200-
* complicated
201-
* represents an intermediate state which may not even make sense
202-
* the problems that merging discovery solves (i.e. preventing orphaned objects) can actually
203-
be solved by the dynamic feature flag KEP, so solving it here would be redundant and
204-
unnecessarily complex.
205-
206-
By routing all discovery requests to the newest apiserver, we can ensure that namespace and gc
207-
controllers do what they would be doing if the upgrade happened instantaneously.
208-
209195

210196
API server change:
211197
* A new handler is added to the stack:
@@ -282,6 +268,24 @@ TODO: explanation of how the security handshake between apiservers works.
282268
* generate self-signed cert on startup, put pubkey in apiserver identity lease
283269
object?
284270

271+
### Unresolved (how we will make discovery consistent)
272+
273+
One option is routing discovery requests from old-apiservers to the new api-server,
274+
so that all discovery requests reflect the newest one. We specifically rule out
275+
merging discovery docs, because merging discovery is:
276+
277+
* complicated
278+
* represents an intermediate state which may not even make sense
279+
* the problems that merging discovery solves (i.e. preventing orphaned objects) can actually
280+
be solved by the dynamic feature flag KEP, so solving it here would be redundant and
281+
unnecessarily complex.
282+
283+
By routing all discovery requests to the newest apiserver, we can ensure that namespace and gc
284+
controllers do what they would be doing if the upgrade happened instantaneously.
285+
286+
Alternatively, we can use the storage version objects to reconstruct a merged discovery
287+
document and serve that in all apiservers.
288+
285289

286290
### Test Plan
287291

0 commit comments

Comments
 (0)