Add odo `catalog describe service <service_name>`

[surajnarwade]

odo catalog describe service <service_name> should print information about given service, for example,

odo catalog describe service <service_name>

Description:
...
...
Plans:

* Dev: 
...
...

* Prod:
...
...

[cmoulliard]

Why do you place the verb describe after catalog and not instead after service -> odo catalog describe service <service_name> ?

[surajnarwade]

we followed this earlier,

* odo catalog search service <service_name>

Similarly,

* odo catalog describe service <service_name>

[cmoulliard]

As the rule to name a command is following this convention odo <entity> <verb>, I think that we should do the same when we add a second entity odo <entity> <sub-entity> <verb> and by consequence the commands should be :

odo catalog service search or odo catalog service describe as we want to say. I want to search for services part of the catalog or I want to describe a service part of the catalog.

That also simplifies how you would like to switch between same related <entity> commands but by changing the <verb> only

I search for a service and then I describe it

odo catalog service search dh-mysql
odo catalog service describe dh-mysql-apb

will need less changes in my terminal (2 words to be changed) vs

odo catalog search service dh-mysql
odo catalog describe service dh-mysql-apb

where 3 words must be changed when I will describe a service after doing a search

[surajnarwade]

agreed @cmoulliard , thanks for nice explanation :)

[cmoulliard]

Can we document such decision globally to make sure that we will adopt/follow same convention for all the odo commands ? @kadel @jorgemoralespou @surajnarwade

[jorgemoralespou]

@cmoulliard One of the goals of the tools is to be fluent and intuitive.

In English you would most likely say describe service rather than service describe. It is a matter of preference, and in your example about less typing, depends how you type, you can just replace the term that changes easily and not to type again from that term to the end of the line.

This is something that needs to be discussed further if need to change.

[mik-dass]

@kadel @jorgemoralespou @surajnarwade What data should I include in the output? I am currently assuming name, short description and long description and the plan details. Will it be a good id to include the UID, tags and other similar stuffs?

[cmoulliard]

I'm not sure if UID should be included but we need the info you proposed plus also bindable: true | false, tags

Example

svcat get classes dh-postgresql-apb -o yaml
...
  Name: dh-postgresql-apb
  Bindable: true
  Operated by the broker : ansible-service-broker
  Short description: SCL PostgreSQL apb implementation
  Long Description: An apb that deploys postgresql 9.5, 9.6 or 10.
  Versions available :
    - docker.io/centos/postgresql-95-centos7
    - docker.io/centos/postgresql-96-centos7
    - docker.io/centos/postgresql-10-centos7
  tags:
  - database
  - postgresql
  Plans:
  - Name: dev
    Display Name: Development
    Description: This plan provides a single non-HA PostgreSQL server without persistent storage
    Parameters:
      - postgresql_database:
        default: admin
        pattern: ^[a-zA-Z_][a-zA-Z0-9_]*$
        title: PostgreSQL Database Name
        type: string
      - postgresql_password:
        pattern: ^[a-zA-Z0-9_~!@#$%^&*()-=<>,.?;:|]+$
        title: PostgreSQL Password
        type: string
      - postgresql_user:
        default: admin
        maxLength: 63
        pattern: ^[a-zA-Z_][a-zA-Z0-9_]*$
        title: PostgreSQL User
        type: string
      - postgresql_version:
        default: "10"
        enum:
        - "10"
        - "9.6"
        - "9.5"
        title: PostgreSQL Version
        type: string
    required:
    - postgresql_database
    - postgresql_user
    - postgresql_password
    - postgresql_version

Remark : Does the word bindable should be used or instead should we propose a more user's friendly word that a user will understand ?

[mik-dass]

@cmoulliard Interestingly certain fields are missing in my output like version available,operated by and others

[mrinaldas@localhost Downloads]$ ./svcat get classes dh-postgresql-apb -o yaml
metadata:
  creationTimestamp: 2018-09-14T08:14:20Z
  name: 1dda1477cace09730bd8ed7a6505607e
  resourceVersion: "297"
  selfLink: /apis/servicecatalog.k8s.io/v1beta1/clusterserviceclasses/1dda1477cace09730bd8ed7a6505607e
  uid: 2e66d91d-b7f6-11e8-939e-0242ac110005
spec:
  bindable: true
  bindingRetrievable: false
  clusterServiceBrokerName: openshift-automation-service-broker
  description: SCL PostgreSQL apb implementation
  externalID: 1dda1477cace09730bd8ed7a6505607e
  externalMetadata:
    console.openshift.io/iconClass: icon-postgresql
    dependencies:
    - docker.io/centos/postgresql-95-centos7
    - docker.io/centos/postgresql-96-centos7
    - docker.io/centos/postgresql-10-centos7
    displayName: PostgreSQL (APB)
    documentationUrl: https://www.postgresql.org/docs/
    longDescription: An apb that deploys postgresql 9.5, 9.6 or 10.
    providerDisplayName: Red Hat, Inc.
  externalName: dh-postgresql-apb
  planUpdatable: true
  tags:
  - database
  - postgresql
status:
  removedFromBrokerCatalog: false

[cmoulliard]

I have renamed some of the svcat fields to make them more readable e;-)

[mik-dass]

@cmoulliard Can you please provide the mapping details? I mean which variable got renamed to which, it's confusing me :)

[cmoulliard]

For sure

Service info

odo field	service/plan field	Example
Name	spec.Externalname	dh-postgresql-apb
Bind	spec.bindable	true
Operated by the broker	spec.clusterServiceBrokerName	ansible-service-broker
Description	spec.description	SCL PostgreSQL apb implementation
Long Description	spec.externalMetadata.longDescription	An apb that deploys postgresql 9.5, 9.6 or 10.
Versions available	spec.externalMetadata.dependencies	- docker.io/centos/postgresql-95-centos7, ....
Tags	spec.tags	- database, - postgresql

Plan info

odo field	service/plan field	Example
Plans
Name	spec.externalName	dev
Display Name	spec.externalMetadata.displayName	Development
Description	spec.externalMetadata.longdescription	This plan provides a single non-HA PostgreSQL server without persistent storage
Parameters	spec.instanceCreateParameterSchema.properties	- postgresqldatabase: default: admin pattern: ^[a-zA-Z][a-zA-Z0-9_]*$ title: PostgreSQL Database Name type: string
Required	spec.instanceCreateParameterSchema.required	- postgresql_database, - postgresql_user - postgresql_password - postgresql_version

[mik-dass]

@cmoulliard Thanks a ton! This is really helpful :+1: