odo catalog list components command output improvement

[elsony]

User Story

As a user, I want to see more details on the output of the odo catalog list components so that I can easily decide which component to pick when looking at the returned list.

Acceptance Criteria

• Add a column for the description of the component entry to help user to understand what is each component used for. For devfile style, description can be found in meta.yaml in the Che devfile repo.
• When running with experimental flag true, add a column to list the style of the component, e.g. devfile, s2i (final label still needs to be decided), to help user to understand if a given component is using s2i or devfile style of build.

Background

When the experimental flag is set to true, devfile code path is enabled. When the user do odo catalog list components, the list that get returned can potentially return multiple entries for similar support, e.g. there will be a node support for s2i style as well as devfile style. Adding a style column will allow the user to figure out the style of the individual component entry that got returned.

/kind user-story
/area devfile

[kadel]

One important piece of information is missing: Where to get the list of devfiles.

odo should support listing devfiles from two types of sources: public and private.

For the public one, odo should use the same devfile registry as hosted Che (https://che.openshift.io).
The registry is hosted at https://che-devfile-registry.openshift.io/ (source: https://github.com/eclipse/che-devfile-registry)

For the private one. I see two options.

1. we assume that the private registry is always hosted on the cluster that odo is connected and we try to autodetect it, so the user doesn't have to do any configuration.
2. we add a new command that will allow adding and removing registries that odo searches. Maybe this could be a preference. odo preference add DevfileRegistry my-registry "https://my-devfile-registry.example.com, odo preference remove DevfileRegistry my-registry.

For MVP I would just stick with the public one.

[girishramnani]

This issue is related to just viewing the information, the getting dev files from registry and filtering them is already being done as part of a different issue

[elsony]

The filtering of the dev files from registry will be covered as part of #2557.

[GeekArthur]

I agree with @kadel 's comment #2608 (comment), we should have a mechanism to let user specify the registry for registry flexibility. Probably we can combine the two options, by default we automatically detect the registry on user's cluster, if it doesn't exist we provide option to let user specify the registry. We can open a separate issue for this if we don't have one before.

Currently my implementation of #2557 sticks with Che registry.

Regarding this issue (the output format of odo catalog list components), below is the current output format

NAME	PROJECT	TAGS

If we would like to share the same format for devfile and s2i, we may need to remove PROJECT and TAGS and reconsider the shared format. The reason is that PROJECT is to let user know the specific builder image exists in which namespace, and TAGS is to let user know what tags the specific image has, from my understanding the two columns are only related with images (s2i), and they can't apply to devfile. I think the general design would be we need to ensure all the columns can apply to both s2i and devfile.

[cdrage]

@GeekArthur Why not both?

I know it may be tricky. But at the moment, we have two tables being outputted when doing odo catalog list components:

github.com/openshift/odo  improve-error-messages ✔                                                                                                                                                                                                                                                                                                                      0m  
▶ odo catalog list components
Odo Supported OpenShift Components:
NAME       PROJECT       TAGS
java       openshift     11,8,latest
nodejs     openshift     10-SCL,8,8-RHOAR,latest

Odo Unsupported OpenShift Components:
NAME              PROJECT       TAGS
dotnet            openshift     2.1,2.2,3.0,latest
golang            openshift     1.11.5,latest
httpd             openshift     2.4,latest
modern-webapp     openshift     10.x,latest
nginx             openshift     1.10,1.12,latest
perl              openshift     5.24,5.26,latest
php               openshift     7.0,7.1,7.2,latest
python            openshift     2.7,3.6,latest
ruby              openshift     2.4,2.5,latest

I'd suggest that we combine the tables, for example, we'd have one table that shows S2I images (if enabled):

NAME              PROJECT     SUPPORTED       TAGS 
dotnet            openshift     YES           2.1,2.2,3.0,latest
golang            openshift     YES           1.11.5,latest
httpd             openshift     YES           2.4,latest
modern-webapp     openshift     YES           10.x,latest
nginx             openshift     YES           1.10,1.12,latest
perl              openshift     NO            5.24,5.26,latest
php               openshift     NO            7.0,7.1,7.2,latest
python            openshift     NO            2.7,3.6,latest
ruby              openshift     NO            2.4,2.5,latest

Then have another table for Devfile.

Notes:

• We should support them alphabetically and first supported and then unsupported images.

Giving a lot more flexibility / showcasing both options, using Devfile (which obviously uses something different / not using tags or project, as well as S2I.

What do you think @GeekArthur ?

[GeekArthur]

@cdrage That sounds to me, actually I like your design

• Independently maintain the two tables (s2i and devfile tables) can provide more unique information to user for each table (eg. PROJECT and TAGS for s2i table)
• Combine supported and unsupported tables can reduce the total number of tables from 4 to 2

I heard we have a design of sharing the same format for s2i and devfile, that's why I mention some conflicts exist if would like to go for the design.

@kadel @elsony Any comments for @cdrage 's design?

[kadel]

@kadel @elsony Any comments for @cdrage 's design?

Nope. I think that it is good to approach. We will show different information for devfile than for s2i builder images, si two separate tables make sense.

[elsony]

I think it make sense to use two different tables to show different set of information for the two styles and combine the supported and unsupported table list.

One thing that I am not sure is if we should show the unsupported ones by default. The devfile support will be using a public devfile registry by default if there is no private registry on a cluster. There may be a sizable number of devfile that doesn't meet our default criteria. Should we show both the supported and unsupported ones by default or should we just show the supported ones by default and add a flag like '--all' to allow the user to see all of them?

If we only show the supported ones by default, then we can skip the SUPPORTED column to further simplify the output. That's probably the view that a typical odo user will be interested in anyway. And we only show the SUPPORTED column if the '--all' flag has been used when the user calls the catalog list command.

[GeekArthur]

@kadel @cdrage

Any ideas for @elsony 's suggestion #2608 (comment)?

We discussed this in today's Codewind status meeting. Given we combined Che devfile registry and our own devfile registry, we had so many unsupported devfile components displayed, the solution we came up with was by default we only displayed supported devfile components, user could check all devfile components (supported + unsupported) by adding flag which was odo catalog list components --all.

Currently we don't have --all flag and we display all devfile components (supported + unsupported) by odo catalog list components. Please let me know if we want the --all flag design and I can implement that.

[cdrage]

Hi @GeekArthur

To be honest, I'd like to still show unsupported, so we could potentially get outside support on improving those languages as well as showing what perhaps will be supported in the future.

That's just my opinon though.

I'm going to assign this issue to you for now (unassign myself) as you've been doing an amazing job at this. Makes sense for you to take over!

[GeekArthur]

@cdrage Sure, no problem! I can take this one. Personally both ways (show unsupported and doesn't show unsupported) are good for me since seems like they both have legit reasons. From the last discussion, currently by default devfile component doesn't show unsupported but s2i component show unsupported. I will leave as it is until we have further design and use this issue to just format the output.