enhancements/update/channel-metadata: Distribute channel description strings #531
Conversation
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: wking The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
wking
force-pushed
the
channel-metadata
branch
from
072a6e1
to
8a738af
Compare
| ## Motivation | ||
|
|
||
| Exposing channel descriptions to provide more context about the current channel or possible channel choices makes it easier for cluster administrators to select the channel that aligns with their intended update semantics. | ||
| It reduces the chance that cluster administrators misinterpret the channel names (e.g. expecting `fast-*` to be unsupported, when in fact, it [is supported][channel-docs-fast]). |
There was a problem hiding this comment.
I am curious to know when fast channel is misinterpreted as unsupported.
|
|
||
| // status contains information about the channel. | ||
| // +optional | ||
| Status ChannelStatus `json:"status"` |
There was a problem hiding this comment.
Why the name is ChannelStatus? it is ChannelMetadata right?
There was a problem hiding this comment.
Kube objects have spec and status. metadata is already used by ObjectMeta, which will hold the channel name.
| // channel semantics. | ||
| // +optional | ||
| Description string `json:"description,omitempty"` | ||
| } |
There was a problem hiding this comment.
An example using these new API would be better for review as it will help to see how it will look like when used.
| With interfaces like the web console and `oc adm upgrade ...` exposing channel descriptions channel semantics, she will no longer have to discover [these docs][channel-docs-fast] to understand what `fast-4.6` means. | ||
|
|
||
| By exposing these semantics via an API, it's also possible for folks using alternative update services to declare their own semantics for their own channels. | ||
| They will not need to match patterns used by Red Hat when managing channels for our hosted update service. |
There was a problem hiding this comment.
it's also possible for folks using alternative update services to declare their own semantics for their own channels. They will not need to match patterns used by Red Hat when managing channels for our hosted update service.
This is a hypothesis right? Or do you know anyone doing it?
|
Issues go stale after 90d of inactivity. Mark the issue as fresh by commenting If this issue is safe to close now please do so with /lifecycle stale |
openshift-ci-robot
added
the
lifecycle/stale
|
Stale issues rot after 30d of inactivity. Mark the issue as fresh by commenting If this issue is safe to close now please do so with /lifecycle rotten |
openshift-ci-robot
added
lifecycle/rotten
|
Rotten issues close after 30d of inactivity. Reopen the issue by commenting /close |
|
@openshift-bot: Closed this PR. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
We have official documentation for channels and their intended semantics, but not all customers read the docs. This enhancement proposes an API which update services may use to declare channels and associated metadata, and a path for propogating that data into clusters, where tooling like
oc adm upgrade [channel]and the web console can expose them to users as they are considering channel choices or the resulting update recommendations. This is similar to available-update metadata (#123, #408), but for different data.Exposing channel descriptions to provide more context about the current channel or possible channel choices makes it easier for cluster administrators to select the channel that aligns with their intended update semantics. It reduces the chance that cluster administrators misinterpret the channel names (e.g. expecting
fast-*to be unsupported, when in fact, it is supported).Distributing the information via an API allows the update service, which is in charge of populating the channel-specific update recommendations, to declare the semantics it is using for each channel. This allows user-facing interfaces like
ocand the web console to access the channel metadata and display it to the user without hard-coding assumptions about the update service.