Hi all.
Some thoughts mostly from the view point of scripting/automating actions as part of a pipeline:
a) Very nice to see yaml dicts indexed by user friendly ‘service/n’ keys, rather than internal ‘unit-service-n’ keys, makes life much easier thank you.
b) One issue we’ve had with current actions is difference in yaml format between juju run-action --wait --format yaml and juju show-action-output <id> --format yaml (the latter has an extra dict around it). It seems like this fixes that (in that the yaml output is always in a dict keyed by unit), great!
Some questions:
-
Does
juju run <units> <action>exit with non-zero return code if the action fails on any unit? For me, in an ideal world, in the single unit action case, it would exit with the same exit code that the action exited with. -
Is seems the output on
juju run --format yamlis mixed between client logging, action output and yaml. This would make it very difficult to consume from a script. If I’ve specified --format=yaml, I would expect to be able to feed the output to a yaml parser, but from that examples, it looks like this would break?
Both the above are related to the same use case. I have a deployment pipeline that automates juju orchestration. I want to run an action (e.g. db migration) as part of this, and I want everything to come to halt if this fails. Right now, doing this is awkward, before juju run-action --wait we had to use show-action-output and manually parse the yaml for success/failure. We recently switched to use --wait, but we still need to parse the yaml (which is a different structure than show-action-output). 1) would make this trivial for us, for example.
Also, a more off the beaten path question:
We automate many self authored similar looking charms with the same pipeline. Some of these services have databases, we include a migrate action on those charms, but not others. Because of this, our general purpose deployment pipeline tooling has to check if a migrate action exists before trying to run it. While this is reasonable, it is cumbersome, as involves yet more subprocesses and yaml parsing.
Would a flag like --ignore-missing or --if-exists or similar be an option? Would exit with 0 if the action is not there? I realise this is a bit of a niche case, but again, it’s coming from the automation perspective rather than the manual operation perspective.