<div dir="ltr"><div>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).<br>
<br></div>I don't know that all those questions need to be answered in a first draft.<br><br>John<br>=:-><br><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Mar 27, 2014 at 1:53 PM, Tim Penhey <span dir="ltr"><<a href="mailto:tim.penhey@canonical.com" target="_blank">tim.penhey@canonical.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On 27/03/14 20:47, John Meinel wrote:<br>
> Juju run is currently a way to execute arbitrary shell code on machines<br>
> inside of a hook context. Actions are running charm-defined shell code<br>
> inside a hook context. There is a certain amount of overlap between the two.<br>
><br>
> As I understand it, juju-run actually works by having the juju client<br>
> talk to the API server and request some actions, which the API server<br>
> then spawns an SSH connection to each machine and runs those commands<br>
> synchronously. (I'm not sure if it runs them all in parallel, but the<br>
> client sits waiting for the API server to return from the original<br>
> request with the results of the SSH sessions.)<br>
<br>
</div>The api-server component of juju run does indeed ssh to the units or<br>
machines to run the commands.  This is done in parallel, and has a max<br>
timeout value that is configurable.<br>
<br>
The actual execution of the commands is done in a hook context if the<br>
target is a unit, and as the ubuntu user in the /home/ubuntu directory<br>
if the target is a machine.  The machine execution is also serialized on<br>
the machine by grabbing the hook execution lock.<br>
<div class=""><br>
> I'm personally a bigger fan of modeling Actions as being run directly by<br>
> the Uniter agent (instead of as spawned from SSH from the API server).<br>
<br>
</div>This line of thinking was thought about when we implemented juju run.<br>
<br>
The concepts behind juju in general is that we record the state of the<br>
world as we'd like it to be, and then the provisioner makes machines,<br>
and the machine agents and unit agents make the machines install and run<br>
what fits with this world view.<br>
<div class=""><br>
> I think Gustavo's outline fits well with that, and is a reason to *not*<br>
> use the juju-run mechanism.<br>
<br>
</div>The outline that Gustavo has given has actions fit into this world view.<br>
A key missing bit here is who is the target of the action?<br>
<br>
Is it a service? Or a unit of the service?<br>
<br>
If we are looking at actions like "backup database", then I'd guess that<br>
the target is the service, but do we care which unit does the actual<br>
backing up?  What about when an action requires synchronisation across<br>
different services?  Where does the action live?<br>
<span class="HOEnZb"><font color="#888888"><br>
Tim<br>
</font></span></blockquote></div><br></div>