Implementing Juju Actions

[John Meinel]

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.)

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).

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

John
=:->



On Thu, Mar 27, 2014 at 6:40 AM, Gustavo Niemeyer <
gustavo.niemeyer at canonical.com> wrote:

> Hey Bodie,
>
> On Wed, Mar 26, 2014 at 9:22 PM, James Solomon <binary132 at gmail.com>
> wrote:
> > Gustavo said we should start with charm/config.go, but as I'm looking
> > through /cmd/juju/run.go, it looks almost like Actions should be
> implemented
> > there.  I asked about this in freenode #juju-dev and dimitern confirmed
> what
> > I was thinking (but again, I'm new to the project) -- this almost seems
> like
> > it should be an API feature.
> (...)
> > Gustavo's indication was that we should be implementing this through
> hooks,
> > so I'm at a loss here.  I agree with him that this is probably the best
> > place to start.  Any input is welcome.  :)
>
> From a high-level perspective, the plan we discussed is:
>
> 1) Charm is designed with support for actions schema
> 2) Command is run: juju do <action> <parameters>
> 3) Client talks to the server, and enqueues actions
> 4) Unit agent take notice, pulls the first action from the queue
> 5) Unit agent runs hook, reports back
> 6) Client gets told outcome
>
> I honestly don't even know what "using juju run" would mean in this
> context, let alone why it would make more sense.
>
> Can someone that understands the alternative please provide some
> insight and reasoning comparing them?
>
>
> gustavo @ http://niemeyer.net
>
> --
> Juju-dev mailing list
> Juju-dev at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20140327/5ffded37/attachment.html>