Run-action should have a --application flag to trigger the action to run on all units of an application

A good suggestion from @afreiberger appeared as a bug report, that I’m reposting here for increased visibility:

Some charms, such as cs:telegraf require running actions to complete charm/software upgrades.
for instance, going from telegraf-28 to telegraf-29 provides a juju status which notes:

Install filebeat-6.8.0 with the ‘reinstall’ action.

On each unit.

As a standard openstack cloud has ~50+ such units, I’d rather not have
to write an awk-based loop to iterate through these units, but rather
juju run-action should have an [–application | -a] flag or an
application/all argument to trigger the action to run on all units of
the application.

There are of course workarounds…

juju status --format=short \
  | cut -d' ' -f2 \
  | cut -d':' -f1 -s \
  | grep ^<application> \
  | xargs -I@ juju run-action  @ <action>

…but they’re hardly elegant.

1 Like

Thanks for your support, Tim. I’ve had plenty of years of flying fingers rattling of such pipe-chains, and it’s kind of become a habit, but I have definitely well appreciated the development efforts that went into prior cli improvements such as the juju run -a|-u|-m flags, and my RSI is quite thankful for the improvements.

I definitely appreciate that there is risk in providing such a powerful tool on the CLI for something the original intent of which was to specifically allow for serial, rather than parallel, execution. See Openstack Series Upgrades with HA Pause and Resume as a good example of this in practice.

Perhaps some sort of non-repudiation/force flag to enable the feature to be overridden may mitigate this risk.

I noticed that /leader was added as an option, which is very handy. It may be handy for those who want a more parallelized operations experience to want an /all-notleader or simplified /notleaders type option as a knock on request to the /all extension.

Thanks for any thoughts you all might have.