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.
CCing James Harshaw to make sure he is tuned into this thread. I believe he's down today with the flu. 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. 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. 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.) "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. Thanks again for all the discussion! Bodie On Thu, Mar 27, 2014 at 9:58 AM, William Reade <william.re...@canonical.com>wrote: > We should not be using juju run to implement juju actions; they should be > fed to the uniter analogously to hooks. > > On Thu, Mar 27, 2014 at 1:32 PM, Gustavo Niemeyer <gust...@niemeyer.net>wrote: > >> On Thu, Mar 27, 2014 at 6:53 AM, Tim Penhey <tim.pen...@canonical.com> >> wrote: >> > The outline that Gustavo has given has actions fit into this world view. >> >> Indeed. Because that's the way that sounds reasonable, but I'm open to >> arguments about why that's not the case. >> > > 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. > > >> It's the same problem of internal service coordination. A leader must >> be elected to take responsibility for procedures on behalf of the >> service. > > > 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. > > 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. > > Cheers > William >
-- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
