Implementing Juju Actions

[John Meinel]

Right, there was certainly the idea of Bundle level Actions. Which as you
point out, needs a place to actually run. But I think that comes in as we
sort out the modeling for it. Some actions are multi-service (Appservers go
into Readonly mode, dump the DB, bring the appsevers back up).

I don't know that all those questions need to be answered in a first draft.

John
=:->



On Thu, Mar 27, 2014 at 1:53 PM, Tim Penhey <tim.penhey at canonical.com>wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20140327/f05cb8a7/attachment.html>