<div dir="ltr">Thanks for the input. :) The discussion and response is much appreciated. I certainly wasn't trying to tackle this from an architectural standpoint; I don't have any claim to authority (or even insight, at this point) on the subject of Juju's architecture, which I think is the real issue for me here and now.<div>
<br></div><div>CCing James Harshaw to make sure he is tuned into this thread. I believe he's down today with the flu.<br></div><div><br></div><div>Monday's sprint plan was about trying to get a skeletal sketch of this rolled out by EOW, so we were focused on implementing "do" on the command line just as a starting point -- you might be overestimating how much code clarity we have here. Our path of discovery was focused on /cmd/juju/run.go Main() since it looks like that's the point of entry for implementing new commands. I think that's where our confusion about how to tackle this has been coming from.</div>
<div><br></div><div>I definitely understand that we need to implement Actions in the charm code, but it's not clear how we should proceed to get something-anything out the door in a way that we can start to play with and understand. Obviously, the code base is pretty significant; neither of us have had exposure to Go projects of this magnitude. I (perhaps wrongly?) assumed that therefore our first real foothold here should be the hacking-and-exploring approach where we attempt to create a really, really basic sketch of "do" as a new Command, and then see how other Commands happen (which appears to be the Run method as discussed) and try to do a mockup that way.</div>
<div><br></div><div>I'd like to clarify what I'm understanding here: we are to implement the new commands alongside "deploy" and "set" as verbs belonging to the Charm code. And these commands are implemented separately from the /cmd code tree (I guess the Command and RunCommand interfaces are for the "juju run" code discussed above.)</div>
<div><br></div><div>"That's surprising, FWIW" -- on that side note, one scalable alternative to parallel SSH for remote exec is ZeroMQ, which is really effective in Saltstack. A criticism is that security features are a more recently released feature of zmq and its Go bindings may not be fully mature; however, I think a lot of progress has been made in the last year or two. Also, I thought remote procedures were triggered via Go RPC, not SSH. I guess I have more digging to do. ;) Just some thoughts.</div>
<div><br></div><div>Thanks again for all the discussion!</div><div><br></div><div>Bodie</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 27, 2014 at 9:58 AM, William Reade <span dir="ltr"><<a href="mailto:william.reade@canonical.com" target="_blank">william.reade@canonical.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>We should not be using juju run to implement juju actions; they should be fed to the uniter analogously to hooks.<br>
</div><div class=""><div><br></div><div>On Thu, Mar 27, 2014 at 1:32 PM, Gustavo Niemeyer <span dir="ltr"><<a href="mailto:gustavo@niemeyer.net" target="_blank">gustavo@niemeyer.net</a>></span> wrote:<br>
</div></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class=""><div>
On Thu, Mar 27, 2014 at 6:53 AM, Tim Penhey <<a href="mailto:tim.penhey@canonical.com" target="_blank">tim.penhey@canonical.com</a>> wrote:</div></div><div class=""><div>
> The outline that Gustavo has given has actions fit into this world view.<br>
<br>
</div>Indeed. Because that's the way that sounds reasonable, but I'm open to<br>
arguments about why that's not the case.<div></div></div></blockquote><div><br></div><div>I am entirely on board with your interpretation of this issue. Juju run works that way out of expediency, not conceptual purity or correctness. The ideal implementation of juju actions would probably end up replacing the client-side implementation of juju-run, in favour of storing run commands as (pseudo-)actions themselves.</div>
<div class="">
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">It's the same problem of internal service coordination. A leader must<br>
be elected to take responsibility for procedures on behalf of the<br>
service.</blockquote><div> </div></div><div>Agreed; actions absolutely can and should target services, but it's possible to make progress on unit actions without worrying about that too much. I would expect us to run service actions on the leader unit, probably in a different execution context that could, if necessary, made additional tools available for managing cross-unit coordination. If you're at risk of becoming blocked on in-juju leader election, let us know and we will try to expedite it.</div>
<div><br></div><div>James, I think Gustavo's suggestion that you take a look at the Config is good, because it would be sensible to use the same pathways for configuring actions as we already do for charms. By following the path of that data from `deploy` and `set`, over the API, into state, and back out over the API to the unit agents, you should get a pretty good idea of one half of the task; the other half, of tweaking the Uniter state machine to respond to these new request kinds in a sane way, will probably demand a separate discussion.</div>
<div><br></div><div>Cheers</div><span class=""><font color="#888888"><div>William</div></font></span></div></div></div>
</blockquote></div><br></div></div>