updates: capture offline discussion on eus-upgrades-mvp #800
Conversation
Incorporate the outcome of the thread terminating at https://github.com/openshift/enhancements/pull/762/files#r626609451 into the doc. Signed-off-by: Doug Hellmann <dhellmann@redhat.com>
openshift-ci
bot
added
the
priority/important-soon
openshift-ci
bot
requested review from
crawford,
deads2k,
markmc,
sdodson and
sttts
| to attend based on [review comments on the original | ||
| PR](https://github.com/openshift/enhancements/pull/762/files#r626609451): | ||
|
|
||
| * The API server ships with a set of built-in types (pod and node). |
There was a problem hiding this comment.
unclear why this matters?
Do you want to say that the pod subresources are implemented through APIs served by the kubelet and called by the kube-apiserver? This puts a constraint on maximal skew.
There was a problem hiding this comment.
I'm not sure what the background is, I wasn't in the meeting. I'm capturing @derekwaynecarr's comment from the original PR.
| ensure that skew in either direction (api-server or kubelet) is | ||
| preserved that both operators in our context should report a desired | ||
| action (apiserver operator should say I cannot upgrade, machine config | ||
| operator should promote an upgrade). |
There was a problem hiding this comment.
I still disagree with this assessment. This is not about REST API skew (of built-in resources) at all, and hence kubelet as an API client does not matter. This is about kube-apiserver->kubelet API usage to implement certain subresources. Hence, the apiserver is the client and the kubelet dictates which APIs it serves. And therefore it makes sense that the apiserver has to block upgrades.
There was a problem hiding this comment.
To be clear: the outcome of my logic is the same: the ckao will report Upgradable=False.
There was a problem hiding this comment.
@sttts Does that mean this enhancement doc needs a different change? I want to capture the argument in the body, so maybe this text needs to be proposed as an update to the alternatives section, instead of here? I'm not aware of what the final outcome was, so help me work out what updates are needed, please.
There was a problem hiding this comment.
I believe the intent is really to capture the leading component must not upgrade, in this scenario that's the apiserver. The details around API types and compatibility are just in support of that.
|
/lgtm |
|
/approve |
|
Thanks, @sdodson ! |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: dhellmann 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:
Approvers can indicate their approval by writing |
openshift-ci
bot
added
the
approved
Incorporate the outcome of the thread on #762 terminating at
https://github.com/openshift/enhancements/pull/762/files#r626609451
into the doc for better discoverability.
/priority important-soon
/cc @crawford
/cc @markmc
/cc @sdodson
/cc @sttts
/cc @deads2k
/assign @derekwaynecarr