[Output Formats] Default Table Format Doesn't Work/Works Poorly With Storage Module

[tjprescott]

The default table format does not work at all with the data plane list commands in the storage module because they all return results in the following format:

{
  "items": [
     {...},
     {...}
  ],
  "nextMarker": ""
}

Even if they were to work, the fact that the default table format only extracts top-level properties would result in only displaying a name.

[derekbekoe]

Callables would have to be defined for these particular commands to generate appropriate tables.

[mayurid]

Travis Prescott (@tjprescott) : Assigning to you for Sprint 3

[johanste]

I am a bit concerned about the fact that the new output format potentially requires updates to existing commands. It will increase the friction when trying to add new commands to the CLI

• Contributors have to know that they need to test their command with the table output
• This is very much a domain specific feature in that one wouldn't know about this based on previous experience from other projects.

Ideally, the philosophy should be that we start with as few domain specific requirements as possible (basically any python method can be exposed in the CLI as long as you use scalar argument types) and things will work.

You can then optionally attach additional metadata to the command to get a better experience.

In this case, you have to attach additional metadata in order to make things work.

[mayurid]

Travis Prescott (@tjprescott) and Johan Stenberg (ex-msft) (@johanste) : Is it commandlet change or simply defining a callable to have the right format?

[tjprescott]

Mayuri Diwan (@mayurid) you define a callable that transforms the output to the right format and then you have to attach it to the command registration. If it runs the table auto-gen on something that has a result and the resulting table is empty, that's why you get that error.

[tjprescott]

Derek Bekoe (@derekbekoe), Johan Stenberg (ex-msft) (@johanste) I think we could leverage our existing VCR tests to identify which commands would break with a default table output. We could essentially run our tests appending -o table to each command and see if any throw that error. It would not validate whether a table that was auto-genned was any good (most things in storage have only name as a top level field) but it would identify those which would error out (assuming it's covered by tests).