canonical/microcloud

Allow microcloud to output tables in the CLI as json and csv

Closed this issue · 5 comments

Just like lxc can output information in different formats with the -f flag, this would be needed for the microcloud CLI as well.
The motivation behind this originates from the microcloud charm development. Indeed some actions like a node removal (when a charm is scaled down) require to check for the node ROLE before it actually calls microcloud cluster remove <node_name> .. A removal when the role is still in PENDING state leads to error during the removal (e.g, Failed to run "['microcloud', 'cluster', 'remove', 'metal-3']": Error: remove /var/snap/microcloud/common/state/truststore/metal-1.yaml: file does not exist . the certificate was probably not generated yet)

Having a json output format would allow the charm developer to easily track these ROLE states and eventually enqueue an action for later if such a state like PENDING is detected.

@simondeziel does the lxd charm use the LXD API directly? Is this something that the microcloud should be doing with the microcloud API?

This should be straightforward. I can look into it shortly.

@simondeziel does the lxd charm use the LXD API directly? Is this something that the microcloud should be doing with the microcloud API?

@tomponline as far as I am aware the charms tend to run the CLI as a subprocess. E.g. https://github.com/canonical/charm-lxd/blob/46d20c87fe94110830404f7837da6aa45bcb9de3/src/charm.py#L1549-L1570

@markylaing true, although I also see use of pyLXD:

https://github.com/canonical/charm-lxd/blob/46d20c87fe94110830404f7837da6aa45bcb9de3/src/charm.py#L1637

Now there's no pyMicroCloud currently, although it would be interesting to hear from @simondeziel around why there are different methods used in the LXD charm.

@tomponline there is indeed a mix of pylxd and shell'ing out to lxc. The long term plan is to convert most/all to pylxd (canonical/charm-lxd#3) as it grows support for more.