Odo: Display starter project list for odo catalog list components

[elsony]

/kind user-story

User Story

As a user, I want to see the list of starter project that I can create when viewing the component list by calling odo catalog list components.

In https://github.com/openshift/odo/issues/3005#issuecomment-623913169, one of the things that has been discussed is showing the list of available starter projects of a given component when doing catalog list on components. This will help the user to know what starter project is available when they call odo create with the --starter flag.

Acceptance Criteria

• [ ] When calling odo catalog list components, the output should show the Starter project column to display the list of starter projects:

$ odo catalog list components
Odo Devfile Components:
NAME                 DESCRIPTION                            STARTER PROJECTS                REGISTRY
java-maven           Upstream Maven and OpenJDK 11                                          DefaultDevfileRegistry
java-openliberty     Open Liberty microservice in Java      user-app                        DefaultDevfileRegistry
java-quarkus         Upstream Quarkus with Java+GraalVM     quarkus-ex                      DefaultDevfileRegistry
java-springboot      Spring Boot® using Java                springbootproject               DefaultDevfileRegistry
nodejs               Stack with NodeJS 12                   nodejs-starter, other-starter   DefaultDevfileRegistry

• [ ] The starter project list show also show in the output of odo catalog list component -o json
• [ ] odo catalog list component -o json isn't consistent with other json output so that needs to be resolved as well

Links

• Related issue:
  https://github.com/openshift/odo/issues/3005

/kind user-story
/area devfile

[johnmcollier]

Ran into a slight issue with this:

Currently odo catalog list components only downloads the index.json from a registry and retrieves the metadata from it, it does not download each devfile. However the index.json does not contain any information about starter projects.

So, if we want to include the list of starter projects in the output of odo catalog list components, we would to either:
1) Download every devfile when running odo catalog list components and retrieve the list of starter projects
- I don't think we should do this, it'll complicate the registry list logic and slow down every call we make to the registry
2) Store the list of starter projects for a devfile in the index.json and update the index.json generation tool accordingly.

I'm in favour of 2, as it allows to keep downloading only the index.json and prevents us from having to do a costly download of every devfile in all of the registries visible to odo, any time we need to get the devfiles in a registry.

[kadel]

I'm in favour of 2, as it allows to keep downloading only the index.json and prevents us from having to do a costly download of every devfile in all of the registries visible to odo, any time we need to get the devfiles in a registry.

I would go with 2 as well.
Index.json in the registry would be a good fit for this.
And more importantly, we already have problems with doing too many requests to GitHub.

[johnmcollier]

Okay, so this issue will deliver two sets of changes:
1) Update the index.json generator in github.com/odo-devfiles/registry to add the list of projects in each devfile to the index.json
2) Update odo to retrieve the projects from the index.json

[johnmcollier]

This issue is blocked on https://github.com/openshift/odo/issues/3263 and https://github.com/odo-devfiles/registry/pull/29

[metacosm]

Is this really needed considering odo catalog describe component <component name> already does this?

[kadel]

Is this really needed considering odo catalog describe component <component name> already does this?

I would say that we don't need this anymore. odo catalog describe component <component name> should be enough.
I don't see real use-case when I would need to see all starter projects from all devfile components in the registry.

[johnmcollier]

@kadel @metacosm I'm fine with that

@elsony Any concerns closing this out in favour of the functionality that already exists in odo catalog describe component <component name>?

[elsony]

The main concern that I have is the out of the box experience. I consider the component creation with starter is part of the out of the box user experience since it is most likely one of the first things that a new odo user (first time) will do. The current usage flow will be user does odo catalog list components to find out the list of components. If the user wants to create a component with the starter, chances are the user will just do --starter. For components with only one starter, this will work well. However, for components with none or multiple starters, the default --starter path will fail and the user will need to know that they have to do odo catalog describe component to find out the list of available starters.

Given that in the future, we are going to share the same devfile repo with Che, there will be a mix of stacks, some with no starter, some with one starter and some with multiple, e.g. liberty stack is planning to have multiple starters. Without having that starter list show on the catalog list by default, the user will have to try out which has a starter and which one does not. This doesn't translate into a good user experience. If we are concerned with adding things to the index.json without a proper design, I am ok with not showing that on catalog list for the time being. As part of this item, we just need to make sure we provide a good error message when the user uses --starter on a stack that has none or multiple starter project defined, e.g. something like there are multiple starters available on this stack, use odo catalog describe component <component name> to see the list of available starters. We can come back to this later to properly design on it.

One more thing to note is catalog describe is supposed to provide more detailed info, e.g. including description of each starter, repo location of the starter that the user can find the readme on it, etc. Therefore, even if we have the starter list in the catalog list, the catalog describe will not be a duplication of function.

[metacosm]

@elsony I understand the concern. However, as a user the proposed solution of showing the list of starter projects in the component list is not very useful to me as I have no idea what these starters might be. Personally, I'd list the components and then use describe on the ones I might be interested in. describe should then properly describe the offered starters.
Actually, from a user's perspective, a fully interactive flow would be better: you'd just type odo create and then get guided by the tool: which component do you want to use, which starter, which options, etc. As it stands, there are way too many options to remember or even properly discover, resulting in needing to create more commands to help users out. Currently odo is too focused on being consumed by tools, in my opinion, and not enough about being consumed by humans.

[johnmcollier]

So, I'm wondering if we can close out this issue? If there's a strong need for starter projects in odo catalog list components in the future, I guess we can reopen this in the future

On the topic of interactive mode, odo create's interactive mode already supports multiple starter projects. I created a devfile with two starter projects in it and added it to my own devfile registry to test:

@girishramnani On the earlier concerns with odo catalog list components -o json, its output appears to be consistent with other command's json outputs, so I'm not sure if anything needs to be done there either.

[elsony]

@johnmcollier I am ok to close this one

[johnmcollier]

Closing out, let's re-open this if there's a strong desire for this issue again in the future