Do not include UUID in get class|plan output

[carolynvs]

The --uuid flag is still there, but to save space and make room for displaying broker and namespace, hide this ugly (mostly ignored) column.

$ svcat get classes
               NAME                         DESCRIPTION
+--------------------------------+--------------------------------+
  azure-postgresql-database        Azure Database for
                                   PostgreSQL-- database only
                                   (preview)
  azure-sql-database               Azure SQL-- database only
                                   (preview)

$ svcat get plans
              NAME                           CLASS                         DESCRIPTION
+------------------------------+--------------------------------+--------------------------------+
  database                       azure-postgresql-database        A new database added to an
                                                                  existing DBMS
  premium-p2                     azure-sql-database               PremiumP2 Tier, 250 DTUs,
                                                                  500GB, 35 days point-in-time
                                                                  restore

[MHBauer]

at what point do we add a COLUMNS specifier rather than a flag for individual things I want to see?

I think in kube there's -o template and json and json path support.

[carolynvs]

at what point do we add a COLUMNS specifier rather than a flag for individual things I want to see?

Just thinking about going down that path makes me want to go back to what I had originally suggested, just not showing uuid in the get output (while continuing to support the uuid filter).

I don't want to get in the business of supporting kubectl's entire design/framework... 😝

One sec, just the thought of that has made me 💩 my pants. Update incoming...

[jboyd01]

I kind of feel like we should have a flag that causes the output to include the UUID, but tbh, I hate the UUID and would like to never see it again. So I guess the fallback if you really must have UUID is to use native kubectl get clusterserviceclasses/clusterserviceplans. And generally if dealing with UUID you already know the UUID and you want details on the object. So... LGTM.

[carolynvs]

To be clear, you can always use --uuid with both get and describe and describe's output includes the uuid. But yeah it's awful, and I don't want to encourage us to jump through hoops or take on a crap ton of work that's already in kubectl to support something that hopefully won't live on much longer (see pauls stuff on human readable names).

[MHBauer]

LGTM