Respect the "catalog.cattle.io/deprecated" annotation when used on ui extensions

[mantis-toboggan-md]

Is your feature request related to a problem? Please describe.
It would be good to have an official means of deprecating extensions (eg capi). There is a Rancher annotation already defined for this: "catalog.cattle.io/deprecated" we should re-use that annotation.

Describe the solution you'd like
Inform users that an extension is deprecated, or outright prevent them from installing it

Describe alternatives you've considered
un-publishing extensions

Additional context

[richard-cox]

@momesgin / @aalves08 is there an issue about converted the extension cards to use the normal cataloge ones, if so how do we handle the deprecated part?

[momesgin]

@richard-cox we detect the deprecated status of an extension by checking the deprecated property returned by the backend, we don't check for catalog.cattle.io/deprecated annotation. When detected we display a red info icon on the card but we don't block installing them. This behaviour is consistent with the catalog logic in the Apps > Charts page.

[richard-cox]

I'm guessing it gets that value from the annotation

Best to confirm with the capi plugin (does it now return deprecated:true), and was there something in gh to use standard cards for ui extension lists?

[aalves08]

@richard-cox There's no gating for catalog.cattle.io/deprecated afaik. We need to hook that in.

If an extension is deprecated, it doesn't mean it should not be installed, it means that it will stop being supported so a message should be conveyed to the user via card AND slide-in panel. TBD what's the best UX solution.

If we are, at some point in time, to prevent installation/running a deprecated extension we need something else... Either another annotation OR something like catalog.cattle.io/deprecated: 2.10 <= 2.14, which would mean that in 2.15 not only we would show the deprecated "sign" but also prevent installation/running.

These are my two cents on the subject.

@momesgin in terms of extensions (UI installable bit) right now, I don't think we are reacting to a deprecated property. I would stick to annotations, imho, as it has been the go-to method up until now and the control is on the side of the developer of the extension.

Let's try to come up with a solution we all agree so that we can groom this issue and put it in for 2.15

[momesgin]

@richard-cox I checked the CAPI UI extension from https://rancher.github.io/capi-ui-extension, it doesn't have either of the two(i.e. the annotation or deprecated: true).

was there something in gh to use standard cards for ui extension lists?

if you mean the GH issue for the redesign, here's the issue

@aalves08 Regarding the detection of deprecated extensions, I don't see any reason not to rely on both sources:

deprecated: !!chart.deprecated || chart.annotations['catalog.cattle.io/deprecated']

but if we go with your suggestion for specific versions for preventing the installation we might need a different check. I'm personally not a fan of displaying deprecated extensions while simultaneously preventing users from installing them. cc @oboc-sts

[aalves08]

@momesgin I would keep only one source of truth. Also, I don't know from where that deprecated thing came from.

The advantage of doing catalog.cattle.io/deprecated: 2.10 <= 2.14 is that we can mark as deprecated an extension just by the mere existance of catalog.cattle.io/deprecated + we have the option to do even more based on the range in the annotation IF needed.

For me it's either between Product and UX to decide if an extension should be installed after it's been deprecated for a while or not. No personal opinion from my side on that matter.

We just leave the door open for more with this option.

Remember that whatever we implement in terms of checks goes baked into the Rancher instance and not the shell that's published so we can be limiting ourselves.