meshcloud/collie-cli

Unify the tenant command invocation

Closed this issue · 2 comments

Is your feature request related to a problem? Please describe.
Currently working with tenant-related data poses some problems, it is split into costs and regular tenant listing, its hard to decide what information to display where. What should be done if more information is added gradually like users? Using different invocation commands is confusing.

Impact of the feature request
Hard to use collie

How would a solution look like?
A better approach would be to have a unified structure where the user can decide by himself what information he wants to display. Something like:

collie tenants list --show platform platformTenantName costs tags

if not given only a default set of information is shown (can be equal to the current collie tenant list)

I agree we need to revisit this approach at some time in the future.

There are a few questions that pop up when I see your proposal:

  1. How would I view only a single tenant in this model?
  2. How would we show "everything" in a CLI table, where horizontal space is limited?
  3. How would we facilitate commands that come in from a non-top level angle, such as: "Show me all tenants that user john@example.com has access to"?

There might be a switch for sensible defaults like:
collie tenants list cost -> shows cost information like previously, would be the same effect as "manually" selecting e.g.
collie tenants list --show platform,costs,tags (and some more what is currently displayed in cost view), however, one problem is that this would require lookups otherwise not required, like fetching the cost info in the first place. Or we need the time window that needs to be fetched. This again then is a bit confusing for the user. Currently not 100% sure on what to do about that.

So for point 3 that would mean we probably need another "entry" top level command like so:
collie user --filter email=john@example.com.
Under the hood this would execute either the same tenant lookup and just apply filtering and maybe a different display component or we issue a different cli call. But in general, I would prefer to execute the same and just build our model also for the cache.