Skip to content

[RFE] Make it easier to discover older versions of Operators in a CatalogSource #1788

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

Closed
awgreene opened this issue Oct 1, 2020 · 4 comments
Labels
lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. triage/unresolved Indicates an issue that can not or will not be resolved.
Milestone

Comments

@awgreene
Copy link
Member

awgreene commented Oct 1, 2020

Feature Request

Is your feature request related to a problem? Please describe.
Today it's not possible to install an older version of an Operator unless the user exactly knows the CSV semantic version. Furthermore, no tooling exists that helps users understand the contents of CatalogSources on cluster.

Why is this important:
There are many reasons why a user may not want to choose not to install the latest version of an operator - whether it's lack of testing or known problems. It should be easy for a user to discovers what versions of an Operator OLM has in its catalogs and update graphs and expose this information in a consumable way to the user.

Why is this important to happen on the cluster:
On-cluster catalog inspection can help an admin check:

  • If a catalog with known content works correctly on the cluster.
  • If certain versions of an Operator have been deprecated.
  • If newer z-streams versions of a desired minor versions are available.
  • If a certain version got removed.

Describe the solution you'd like

  • A user can see list of available versions of an Operator in a channel on the cluster
  • A user can see a list of available channels of an Operator on the cluster
  • A user can see all available Operators in a particular catalog on the cluster
@awgreene awgreene modified the milestones: 0.17.0, Backlog Oct 1, 2020
@stale
Copy link

stale bot commented Nov 30, 2020

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the wontfix label Nov 30, 2020
@openshift-ci-robot openshift-ci-robot added triage/unresolved Indicates an issue that can not or will not be resolved. and removed wontfix labels Dec 1, 2020
@stale
Copy link

stale bot commented Mar 2, 2021

This issue has been automatically marked as stale because it has not had any recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contribution.
For more help on your issue, check out the olm-dev channel on the kubernetes slack [1] and the OLM Dev Working Group [2] [1] https://kubernetes.slack.com/archives/C0181L6JYQ2 [2] https://github.com/operator-framework/community#operator-lifecycle-manager-wg

@stale stale bot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Mar 2, 2021
@stale
Copy link

stale bot commented Mar 9, 2021

This issue has been automatically closed because it has not had any recent activity. Thank you for your contribution.

@stale stale bot closed this as completed Mar 9, 2021
@codihuston
Copy link

Just wanted to bump this... for all of the reasons OP listed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. triage/unresolved Indicates an issue that can not or will not be resolved.
Projects
None yet
Development

No branches or pull requests

3 participants