-
Notifications
You must be signed in to change notification settings - Fork 574
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
Comments
This issue is stale because it has been open for 30 days with no activity. |
I took the liberty of duplicating your issue in the operatorhub.io repo because it was bugging me too. |
Hi @wallrj, Thank you for letting us know that you are also looking for this feature. 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:
However, it shows also a reasonable request for all other catalogues such as https://github.com/redhat-openshift-ecosystem/community-operators-prod. |
This issue is stale because it has been open for 30 days with no activity. |
This issue was closed because it has been inactive for 30 days since being marked as stale. |
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 |
Signed-off-by: ack-bot <82905295+ack-bot@users.noreply.github.com>
Looking at operatorhub.io, the top looks like this:
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 beforeA
, 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 inClusterServiceVersion
v1alpha1 that could be used specifically for this.Perhaps recognising a
deprecated
value for thematurity
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.
The text was updated successfully, but these errors were encountered: