On the call to discuss oc adm upgrade status roadmap to server side-implementation (notes) we agreed on basic architectural direction:

• status API will be backed by a new controller
• new controller will be a separate binary but delivered in the CVO image (=release payload) to avoid needing new ClusterOperator
• we do not want an OLM-delivered operator because the upgrade is core OCP functionality
• new operator will maintain a singleton resource of a new UpgradeStatus CRD - this is the interface to the consumers
• we eventually want to implement the extension mechanism where insight producers register themselves with the new controller via a new UpdateInformer API, but for 4.17 we may not need the extension mechanism and let the controller scrape the primary health insight producers: CVO and MCO
• eventual extension mechanism involves new http endpoints => security considerations are necessary

In general, we want to build on Justin's initial design ideas: https://github.com/jupierce/oc-update-design-ideas/blob/main/status.md

Because the footprint of status API is rather large (new controller delivered with CVO, two new apis, extension mechanisms, tighter integration with CVO and MCO), we need to start socializing the design and getting feedback on it. It may be too soon for enhancement process but writing down a less formal variant of that in google doc and sharing it with others would be helpful (and eventually we would do the enhancement after we get some feedback).

This document has different audience that OTA-1266 but it may make sense to work on them together (possibly they can be two sections of a single doc, but that can overwhelm and confuse the separate audiences).

Sooner is better; the doc does not need to be very detailed or formal, but the sooner we get feedback going the better.

Scope

oc adm upgrade status is often understood very broadly, the focus of this card should be to collect feedback to support 4.17 GA. We are mostly interested in use cases that concern status during the upgrade, not the broader domain like pre-checks and post-checks.

Definition of Done

• Short (three pages text max, six with listings) google doc proposal - it can follow enhancement template but does not need to go deep into details
• Describe how the new controller fits into OCP
• Describe API types from the implementation PoV
• Socialize the doc to potential consumers: API reviewers, involved staff engineers (Doug Hellman?), MCO team