-
Notifications
You must be signed in to change notification settings - Fork 468
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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 |
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why the name is ChannelStatus
? it is ChannelMetadata right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Currently hypothetical.
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 |
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 |
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
oc
and the web console to access the channel metadata and display it to the user without hard-coding assumptions about the update service.