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
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
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.netwrote:
On Thu, Mar 27, 2014 at 6:53 AM, Tim Penhey tim.pen...@canonical.com
wrote:
The outline that Gustavo
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
On Thu, Mar 27, 2014 at 12:05 PM, James Solomon binary...@gmail.com wrote:
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
What's the difference between Actions and Set? If I do juju set mysql
admins=nate,bill the mysql charm sees the updated admins, and performs
some action (updating permissions in this case). How is that different
from something like juju do setadmins mysql nate,bill ?
On Thu, Mar 27, 2014 at
