juju show-application is missing details

@Richard Harding,

It's certainly possible to show all the charm related information in the output of 'show-application' command. Although all this information is available elsewhere.

Relation data needs to be added.

My biggest interest was to add not a static information that can be discovered via other means or commands (constraints, config, etc fall into this category) but more dynamic information, for example, running actions, etc.

I'll add a list of everything we can output here as well as a list of what I think we *should* output. Your input will be greatly appreciated :D

This is a list of all the data that 'show-application' can display - https://pastebin.ubuntu.com/p/fdFHTJnrNz/.

Since an application most often has units, it seems logical to display some unit details here too. I would have preferred to not see much of the machine details except for machine id. 'show-machine' is the command to display machine details and if it's missing something that we want from this list there, we can track it separately.

(cut-and-pasting here in hope the formatting will come through... if it's unreadable, use pastebin link above)

APPLICATION-LEVEL:

    --- current 'show-application'

    * endpoint bindings;
    * is exposed;
    * is principal;
    * is remote;
    * name;
    * series;
    * constraints (but is already shown via 'juju get-constraints');
    * charm name;
    * channel;

    --- additional details that 'show-application' can display

    * endpoints;
    * life;
    * application status;
    * how many times application charm was modified;
    * device constraints;
    * application leader settings;
    * metrics credential;
    * relations;
    * application status history (although is accessible via other juju commands like, 'show-status-log');
    * storage constraints (although is shown via other juju commands, like 'show-storage');
    * minimum unit count allowed;
    * charm URL;
    * charm config (but is already shown via 'juju config' as default values);
    * application config (but is already shown via 'juju config');
    * charm details [1];
    * units [2];
    * deployed machines [3];

    // additionally, for applications on CAAS models

    * scale;
    * application placement directive;
    * cloud service info;

    // additionally, for remote application

    * source model;
    * is consumer proxy (whether this application was created from a registration operation by a consuming model);
    * offer UUID;
    * application URL;
    * available actions;

[1] CHARM DETAILS (probably discoverable via other means like charm store):
    * name;
    * summary;
    * description;
    * is subordinate;
    * what relations this charm provides;
    * what relations this charm requires;
    * what peer relations this charm can have;
    * extra bindings;
    * categories;
    * supported series;
    * storage requirements;
    * devices requirements;
    * supported payload classes;
    * resources;
    * terms;
    * minimum juju version required for this charm;
    * charm config;
    * metrics;
    * available actions;
    * current charm revision;

[2] UNIT DETAILS (for each unit):
    * name;
    * is principal - whether the unit is deployed in its own container and can have subordinate applications deployed alongside it;
    * names of any subordinate units;
    * life;
    * assigned machine;
    * availability zone of the unit's machine;
    * workload version;
    * running actions;
    * pending actions;
    * completed actions;
    * constraints;
    * series;
    * unit agent;
    * agent history;
    * relations that the unit joined;
    * storage constraints;
    * charm URL;
    * upgrade series status of the machine that unit is assigned to;
    * if the unit is on a CAAS...

Part of the goal is to put into one pane some of the things that's spread out that folks have to assemble data for. Personally, I'd like to include things like storage/resources details we can in this as a single overview.

Looking through your list I think these would be great to have:

    * relations;
    * storage constraints (although is shown via other juju commands, like 'show-storage');
    * charm URL;
    * units [2];
    * deployed machines [3];

    // additionally, for applications on CAAS models

    * scale;
    * application placement directive;

    // additionally, for remote application

    * application URL;

[2] UNIT DETAILS (for each unit):
    * name;
    * workload version;
    * unit agent;
    * charm URL;

Removing from a milestone as this work will not be done in 2.6 series.

Due to current priorities, I am not currently working on this bug, so I am un-assigning myself from it.

This bug has not been updated in 2 years, so we're marking it Low importance. If you believe this is incorrect, please update the importance.