describe operator backed services

[kadel]

User Story

As a user, I want to get detailed information about operator backed service before I create it

Acceptance Criteria

• odo catalog describe service <name> should provide detailed information about the service from OperatorHub.
• odo catalog describe service <name> -o json should provide detailed information about the service from OperatorHub in json format

Same AC moved from #2785

• odo catalog describe service <service-mame> - should include all available parameters, that can be used in odo service create command.
• odo catalog describe service <service-mame> -o json - should include all available parameters, that can be used in odo service create command in json format, so it can be programmatically parsed and proper odo service create command can be generated

Links

• Feature Request: odo service describe and odo catalog describe service for operators + services #2480
• Related issue:

/kind user-story
/area catalog
/area service-operators

[kadel]

I would suggest addressing #2613 (Instantiate service through Operator) first.
When #2613 is implemented it will create nice MVP, that can already be used by odo users (list what can be installed odo catalog list services and install it using odo service create)

[openshift-bot]

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[openshift-bot]

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[girishramnani]

Current scoped work

We were able to figure out how a non-admin user was able to still see the CRD form in web console. Its based on spec.customresourcedefinitions present in the ClusterServiceVersion.
Now this CRD def is different then whats provided by the CustomResourceDefinition ( it has less information ) but as we dont have access to CustomResourceDefinition kind as a normal user we cannot use it, so instead we use ClusterServiceVersion's crd def.

This is how one of the customresourcedefinition looks like ( Kafka from strimzi )

{
  "parameters": [
    {
      "description": "Kafka version",
      "displayName": "Version",
      "path": "kafka.version",
      "x-descriptors": [
        "urn:alm:descriptor:com.tectonic.ui:text"
      ]
    },
    {
      "description": "The desired number of Kafka brokers.",
      "displayName": "Kafka Brokers",
      "path": "kafka.replicas",
      "x-descriptors": [
        "urn:alm:descriptor:com.tectonic.ui:podCount"
      ]
    },
    {
      "description": "The type of storage used by Kafka brokers",
      "displayName": "Kafka storage",
      "path": "kafka.storage.type",
      "x-descriptors": [
        "urn:alm:descriptor:com.tectonic.ui:select:ephemeral",
        "urn:alm:descriptor:com.tectonic.ui:select:persistent-claim",
        "urn:alm:descriptor:com.tectonic.ui:select:jbod"
      ]
    },
    {
      "description": "Limits describes the minimum/maximum amount of compute resources required/allowed",
      "displayName": "Kafka Resource Requirements",
      "path": "kafka.resources",
      "x-descriptors": [
        "urn:alm:descriptor:com.tectonic.ui:resourceRequirements"
      ]
    },
    {
      "description": "The desired number of Zookeeper nodes.",
      "displayName": "Zookeeper Nodes",
      "path": "zookeeper.replicas",
      "x-descriptors": [
        "urn:alm:descriptor:com.tectonic.ui:podCount"
      ]
    },
    {
      "description": "The type of storage used by Zookeeper nodes",
      "displayName": "Zookeeper storage",
      "path": "zookeeper.storage.type",
      "x-descriptors": [
        "urn:alm:descriptor:com.tectonic.ui:select:ephemeral",
        "urn:alm:descriptor:com.tectonic.ui:select:persistent-claim",
        "urn:alm:descriptor:com.tectonic.ui:select:jbod"
      ]
    },
    {
      "description": "Limits describes the minimum/maximum amount of compute resources required/allowed",
      "displayName": "Zookeeper Resource Requirements",
      "path": "zookeeper.resources",
      "x-descriptors": [
        "urn:alm:descriptor:com.tectonic.ui:resourceRequirements"
      ]
    }
  ]
}

As first step we would show this value as is when someone asks for json output for Kafka from strimzi.

• odo catalog service describe strimzi-cluster-operator.v0.21.1/Kafka would show the above json

Similarly the output for human readable output would be -

FieldPath                     Display Name                                        Description
zookeeper.resources Zookeeper Resource Requirements     Limits describes the minimum/maximum amount of compute resources required/allowed
....

Or Maybe consider a non tablular approach instead?

- FieldPath: zookeeper.resources
   DisplayName: Zookeeper Resource Requirements
   Description: Limits describes the minimum/maximum amount of compute resources required/allowed
- FieldPath: zookeeper.storage.type
   DisplayName: ....
   ...

Also maybe we can sort the fields using the fieldpath? so it would look like

kafka.version
kafka.replicas
zookeeper.storage.type

So deeper fields are shown lower?

[girishramnani]

@dgolovin can you Please validate the json output part

[girishramnani]

Also do we wanna do autocomplete? we would need to do some caching for a usable autocomplete as the api call would be slow.

[kadel]

Or Maybe consider a non tablular approach instead?

I would go with tabular.
But considering the length of description lets go with non-tabular.

Also maybe we can sort the fields using the fieldpath? so it would look like

I would keep the original ordering. It looks like it follows some logical ordering.

Also do we wanna do autocomplete? we would need to do some caching for a usable autocomplete as the api call would be slow.

We can check autocomplete later. Not a high priority now.

[girishramnani]

I had a question how to distinguish if the user is asking for service catalog service or an operator.
Should I assume if its of the format <operator>/<CR> i.e. strimzi-cluster-operator.v0.21.1/Kafka then its operator CR?
@kadel

[girishramnani]

Also if a user provide just odo catalog describe service <operator-name> then should I show all CRs under it?
If so then we need to find a better way to distinguish if a user is asking for operators backed services or service catalog services

[kadel]

I had a question how to distinguish if the user is asking for service catalog service or an operator.
Should I assume if its of the format <operator>/<CR> i.e. strimzi-cluster-operator.v0.21.1/Kafka then its operator CR?
@kadel

yes

Also if a user provide just odo catalog describe service <operator-name> then should I show all CRs under it?
If so then we need to find a better way to distinguish if a user is asking for operators backed services or service catalog services

if it is operator based service it should always be specified as operator/cr