Skip to content
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

Alphabetical sorting on operatorhub.io is putting deprecated operators first #549

Closed
TBBle opened this issue Jan 6, 2022 · 6 comments
Closed

Comments

@TBBle
Copy link

TBBle commented Jan 6, 2022

Looking at operatorhub.io, the top looks like this:

image

My first-blush reaction was that operatorhub.io itself had been deprecated, which is an unfair reaction driven by my having lived through the github.com/helm/charts deprecation...

Anyway, I assume the underlying cause is that alphabetically, [ sorts before A, and there's no rule preventing naming your operator to (intentionally or unintentionally) take advantage of that.

Putting [Deprecated] at the start of the name of a deprecated operator's entry isn't ideal, but there isn't a "deprecated" field or similar in ClusterServiceVersion v1alpha1 that could be used specifically for this.

Perhaps recognising a deprecated value for the maturity free-string field would work? Or perhaps this is something that should be at the channel level instead, to deprecate a whole operator, rather than a specific version?

Anyway, with that metadata being distinguished, then deprecated operators could be hidden by default, and searched as a separate axis, and the deprecation status could be made visible via something other than the name field.

@github-actions
Copy link
Contributor

github-actions bot commented Feb 6, 2022

This issue is stale because it has been open for 30 days with no activity.

@wallrj
Copy link
Contributor

wallrj commented Feb 11, 2022

I took the liberty of duplicating your issue in the operatorhub.io repo because it was bugging me too.
I added some extra information about the maturity: deprecated thing.

@camilamacedo86
Copy link
Contributor

Hi @wallrj,

Thank you for letting us know that you are also looking for this feature.
IHMO: Using the maturity field does not seem fit.

The CSV is specific per bundle. For this scenario, shows that we would need to have a way to let the authors define what are the packages which will be discontinued and at some point removed from the index catalog ( operatorhub ).

We might no longer have CSV manifests in the future, see: https://github.com/operator-framework/enhancements/blob/master/enhancements/csvless-bundles.md

Then, it seems that we could use the OLM properties to define it, something like:

properties:
- type: olm.package_discontinued
  value:
    message: "This package is discontinued and is planned to be removed at DD/MM/YYYY. Please, ensure that you use its Backup Service in favor to move forward and began to use the project MyOperator. For further information see: <link>."

However, it shows also a reasonable request for all other catalogues such as https://github.com/redhat-openshift-ecosystem/community-operators-prod.

c/c @mvalarh @J0zi @dmesser

@github-actions
Copy link
Contributor

This issue is stale because it has been open for 30 days with no activity.

@github-actions
Copy link
Contributor

This issue was closed because it has been inactive for 30 days since being marked as stale.

@camilamacedo86
Copy link
Contributor

The option to add a feature to address this requirement has been discussed into the EP: https://github.com/operator-framework/enhancements/pull/113/files

christophd pushed a commit to christophd/community-operators that referenced this issue Jan 11, 2023
Signed-off-by: ack-bot <82905295+ack-bot@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

3 participants