Multi-object table display

[LCVcode]

Jockey should be able to display combinations of Juju objects in a table when prompted by the user. For example, a user may be using Jockey to filter a subset of units, but may want to see both unit names and their corresponding IPs and whether they are principal/leaders or not.

Sub-tasks:

• Decide what CLI flag is best suitable for this functionality. One option might look like jockey unit ... -o unit,ip
• Add table display functionality, where columns are aligned and an arbitrary number of rows can be requested

[johnlettman]

How is something like this?

[LCVcode]

That's pretty close to what I had in mind. However, I want it to be easy to only show certain fields. I see how this is working with dot notation, but my original conception was something like this:

juju-jockey -f tests/samples/k8s-core-juju-status.json u -o i,h,a
+----------+-----------------+
| <unit 1> | <ip-address 1>  |
|          | <hostname 1>    |
|          | <application 1> |
+----------+-----------------+
| <unit 2> | <ip-address 2>  |
|          | <hostname 2>    |
|          | <application 2> |
+----------+-----------------+
| <unit 3> | <ip-address 3>  |
|          | <hostname 3>    |
|          | <application 3> |
+----------+-----------------+

-o is completely arbitrary and it can be replaced with something else. If there is a more elegant way to represent this idea in the CLI, I am open to it.

I envisioned this as a human-readable output that basically won't ever be redirected to anything else.

If you think there may be a simply better way to implement this flavor of functionality, do let me know.

[johnlettman]

Oh! I understand now. Output multiple user-selected fields (instead of or in addition to the ability to do all).

I have been baking up a change that adds output formatting classes; e.g., you could do -O json for valid JSON output or -O yaml for YAML, etc. etc.

So, essentially this paired with that would give numerous options to manipulate the output of objects.

[LCVcode]

Interesting idea. Let's explore this more.

What are the details on the contents of -o json and -o yaml outputs? Is that snippets of juju status --format json, or is it a simple mapping analogous to the table I posted above? I bring this up because my table idea incorporates both a specified output format and some related objects (i,h,a). Setting the output to json or yaml format does not require those related objects. Perhaps there is a way to marry these ideas.

Just spit-balling from here on out:

I am choosing a plausible command as a starting point for the discussion: juju-jockey -f tests/samples/k8s-core-juju-status.json u -o table i,h,a. Note that I added table, compared my prior version of this command. I would expect this to return the table I shared above. So that begs the question: what would juju-jockey -f tests/samples/k8s-core-juju-status.json u -o json i,h,a and juju-jockey -f tests/samples/k8s-core-juju-status.json u -o yaml i,h,a return?

Even if the answer is not obvious, I am biased in favor of feature compatibility (perhaps not parity) here. That is, if -o table <list of juju object types> is a thing, then it should also be a thing for -o yaml and -o json, even if that list of objects is used differently in each case.

[LCVcode]

Another option may be to introduce new syntax to change how <object> is parsed (relevant README.md line).

Consider the following command: juju-jockey u,m,i a~nova-compute That u,m,i may be read as "get a mapping of units to their machines and ip-addresses." Putting it all together, this would return a mapping of each nova-compute unit to its machine number and IP address.

Simply defaulting to a table format in these cases may be the solution here; it would remove the need for -o table and eliminate the heterogeneity with <list of juju object types>.

To explore how this syntax would interact with the other -o values, I need to return to my initial question: what will -o json and -o yaml return in a normal context? Beyond that, what would be the most useful behavior in each case?

I could see us dumping extra information into the json and yaml outputs, such as model, controller, datetime, executed query, etc. None of that information makes sense in the table output, but would essentially be free in the other formats.

Summary:

juju-jockey u a~nova-compute                # Normal list of names

juju-jockey u,m,i a~nova-compute            # Table format

juju-jockey u a~nova-compute -o yaml        # ?

juju-jockey u,m,i a~nova-compute -o yaml    # YAML with unit->machine,IP mappings plus extra info

juju-jockey u a~nova-compute -o json        # ?

juju-jockey u,m,i a~nova-compute -o json    # JSON with unit->machine,IP mappings plus extra info

Maybe I am way over-thinking it. Please do scrutinize.

[johnlettman]

The object method is more intuitive and feasible in the code since it can traverse the virtual fields. We would need to expand those virtual fields to accommodate the object shorthand.

It reads like this:

I want to analyze units, filtering these fields to these values, outputting the unit fields @machine and @application

This provides the added benefit of reaching into those related objects for their fields.

---

We hit a wrinkle with the @ notation for the virtual and existing fields in Juju. I recall there being a machine field on Units. Placing a virtual field to get the related Machine object on machine would shadow the value there. This is not necessarily bad since that value can now be retrieved via @machine.name. It's a matter of your personal preference.

It may be more natural to drop the @ where it relates to an object relationship. I feel @ is appropriate where the actual value doesn't necessarily exist anywhere in the status but as something we calculated.

---

As a result of my interpretation, the final implementation would look like this:

juju-jockey unit,unit.machine,unit.ip