Closed surajnarwade closed 5 years ago
Why do you place the verb describe
after catalog
and not instead after service
-> odo catalog describe service <service_name>
?
we followed this earlier,
* odo catalog search service <service_name>
Similarly,
* odo catalog describe service <service_name>
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
agreed @cmoulliard , thanks for nice explanation :)
Can we document such decision globally to make sure that we will adopt/follow same convention for all the odo commands ? @kadel @jorgemoralespou @surajnarwade
@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.
@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?
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 ?
@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
I have renamed some of the svcat fields to make them more readable e;-)
@cmoulliard Can you please provide the mapping details? I mean which variable got renamed to which, it's confusing me :)
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 |
@cmoulliard Thanks a ton! This is really helpful :+1:
odo catalog describe service <service_name>
should print information about given service, for example,