On the call to discuss oc adm upgrade status roadmap to server side-implementation (notes) we discussed that we do not think we know enough of the API clients and users, and we want to collect more information. We have an idea of what do we want to build, we do not know (enough) whether it meets our users expectations and use cases. Therefore we want to write down our current proposal to a Google Doc and through it collect feedback from our expected API consumers.

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.

The status API has two directions:
1. Consumers of the status API: clients read the API for programmatical access to information about cluster upgrade process
2. Providers of the insights: components that want to surface their information through the status API. Providers register themselves with the status API, and the status controller reads their data and surfaces it through the status API.

The main focus is the first direction (consumers). Insight providers are secondary (maybe this needs to go to the architectural card?).

Definition of Done

• Short (three pages text max, six with listings) google doc proposal of what we are building
• Focus on the API surface, not on the implementation
• Focus on status API consumers, not health insights providers
• Encourage to provide feedback for "ongoing upgrade" information
• Socialize the doc to potential consumers (via Subin)