Implementing Juju Actions

[Tim Penhey]

On 27/03/14 20:47, John Meinel wrote:
> Juju run is currently a way to execute arbitrary shell code on machines
> inside of a hook context. Actions are running charm-defined shell code
> inside a hook context. There is a certain amount of overlap between the two.
> 
> As I understand it, juju-run actually works by having the juju client
> talk to the API server and request some actions, which the API server
> then spawns an SSH connection to each machine and runs those commands
> synchronously. (I'm not sure if it runs them all in parallel, but the
> client sits waiting for the API server to return from the original
> request with the results of the SSH sessions.)

The api-server component of juju run does indeed ssh to the units or
machines to run the commands.  This is done in parallel, and has a max
timeout value that is configurable.

The actual execution of the commands is done in a hook context if the
target is a unit, and as the ubuntu user in the /home/ubuntu directory
if the target is a machine.  The machine execution is also serialized on
the machine by grabbing the hook execution lock.

> I'm personally a bigger fan of modeling Actions as being run directly by
> the Uniter agent (instead of as spawned from SSH from the API server).

This line of thinking was thought about when we implemented juju run.

The concepts behind juju in general is that we record the state of the
world as we'd like it to be, and then the provisioner makes machines,
and the machine agents and unit agents make the machines install and run
what fits with this world view.

> I think Gustavo's outline fits well with that, and is a reason to *not*
> use the juju-run mechanism.

The outline that Gustavo has given has actions fit into this world view.
A key missing bit here is who is the target of the action?

Is it a service? Or a unit of the service?

If we are looking at actions like "backup database", then I'd guess that
the target is the service, but do we care which unit does the actual
backing up?  What about when an action requires synchronisation across
different services?  Where does the action live?

Tim