use swagger.json to get available parameters for `odo service create`

[kadel]

Acceptance criteria:

• [x] output format of odo catalog describe service and odo catalog describe service -o json needs to be the same regardless of where the information about parameters is coming from CSV or swagger.json
• [x] output of odo catalog describe service -o json should be in some standard format like OpenAPIV3, JSONSchema etc...
• [ ] information about parameters should be cached for both CSV and swagger.json. No need to cache the whole swagger.json we can just store information about parameters (more at https://github.com/openshift/odo/pull/4751#discussion_r652797931)
• [ ] allow setting parameters using odo service create -p ...

[girishramnani]

link to the proposal https://github.com/openshift/odo/blob/main/docs/proposals/improved-schema-for-services.md

[dharmit]

/triage needs-information

As a part of research, please also break this "Epic" down into "User Stories".

[dharmit]

We need to consider how this will help odo catalog describe service <operator>/<cr>. For example, currently, odo can't print anything helpful for Redis Operator:

$ odo catalog list services
Services available through Operators
NAME                                CRDs
etcdoperator.v0.9.4-clusterwide     EtcdCluster, EtcdBackup, EtcdRestore
redis-operator.v0.6.0               RedisCluster, Redis

$ odo catalog describe service redis-operator.v0.6.0/RedisCluster 
Kind: RedisCluster
Version: v1beta1
Description: Redis Cluster
Parameters:

 PATH  DISPLAYNAME  DESCRIPTION 

$ odo catalog describe service redis-operator.v0.6.0/Redis       
Kind: Redis
Version: v1beta1
Description: Redis
Parameters:

 PATH  DISPLAYNAME  DESCRIPTION 

[dharmit]

Currently, there are three places where we know we can get the parameters' info from:

• X Descriptors from the CSV
• swagger.json
• CRD (but only accessible via admin user)

Based on the discussion between @kadel and Adapters team, ODC is mainly using swagger.json and relies on X descriptors only for additional data it provides on top of what's available via swagger.json.

In odo, so far, we have relied on X descriptors as primary source of info, and only now we're trying to use what swagger.json has to offer. odo should try and change its approach to how ODC is doing it, because swagger seems to have much more information than X Descriptors.

[mik-dass]

Three cases (arranged by ascending priority):

Case 1: User has access to the CRD's api path, cluster provides an api to get metadata for any CRD needed. URL - <cluster-url>/api/kubernetes/apis/apiextensions.k8s.io/v1/customresourcedefinitions

Case 2: Get the swagger.json from the openapi endpoint provided by kubernetes, <cluster-url>/api/kubernetes/openapi/v2. We fetch the file during odo catalog list services. Steps: https://github.com/openshift/odo/blob/main/docs/proposals/improved-schema-for-services.md#kuberenetes-cluster-swagger-has-the-schema

Case 3: Admin-only approach of using CRD api from the cluster: https://github.com/openshift/odo/blob/main/docs/proposals/improved-schema-for-services.md#fetch-clusterserviceversion-to-generate-the-information

Parsing the data

Case 1:

• Traverse the openAPIv3schema and if we find standard types (like string, integer) we add it to the descriptor listing with its path
• while traversing if we find any complex types like object or array we don't add then to the listing but traverse deeper.
• if we find an array we add [*] as a suffix of the path traversed so far, so that its obvious to the user that they need to add an index there. i.e. zookeeper.env[*].key

Case 2: Fetch the same openAPIV3Schema from the cluster's swagger.json from the endpoint /api/kubernetes/openapi/v2 and parse it as mentioned in https://github.com/openshift/odo/blob/main/docs/proposals/improved-schema-for-services.md#user-has-access-to-openapiv3schema

Case 3: Use the spec.customresourcedefinitions present in the ClusterServiceVersion. This CRD def is different from what is provided by the CustomResourceDefinition as it has less information. Example output: https://github.com/openshift/odo/blob/main/docs/proposals/improved-schema-for-services.md#fetch-clusterserviceversion-to-generate-the-information

Commands

odo catalog describe service

Human readable output:

- FieldPath: zookeeper.resources.limit.min
  DisplayName: Limit Min
  Description: <description>
  Type: string
- FieldPath: zookeeper.storage.type
  Type: string
- FieldPath: zookeeper.env[*].key
  Type: string

odo service create

Parse the user inputs provided via -p and validate it as mentioned in https://github.com/openshift/odo/blob/main/docs/proposals/improved-schema-for-services.md#allowing-user-to-set-the-parameters

[dharmit]

Scope:

• Get hands on swagger.
• Store swagger in user's system
• Pull swagger each time (don't cache)
• odo catalog describe for Redis operator should work fine.
• Parse whatever comes from swagger.json

[dharmit]

Scope

• [x] If there is swagger info, we use that to validate the parameters.
• [x] if swagger info doesn't exist, we use x-descriptors from CSV
• [x] if nothing exists; we don't validate the parameters
• [x] we don't want to do caching right now
• [x] integration tests
• [ ] Documentation, if possible.