On Thu, Mar 27, 2014 at 12:34 PM, Nate Finch wrote:
> 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 "
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 a
On Thu, Mar 27, 2014 at 12:05 PM, James Solomon 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 (I
> guess the
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
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 wrote:
> On Thu, Mar 27, 2014 at 6:53 AM, Tim Penhey
> wrote:
> > The outline that Gustavo has given has actions fit into this world
On Thu, Mar 27, 2014 at 6:53 AM, Tim Penhey wrote:
> The api-server component of juju run does indeed ssh to the units or
> machines to run the commands. This is done in parallel, and has a max
> timeout value that is configurable.
That's surprising, FWIW. But that's a separate issue.
> The ou
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 kno
On 27/03/14 20:47, John Meinel wrote:
> 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 a
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
Hey Bodie,
On Wed, Mar 26, 2014 at 9:22 PM, James Solomon 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
>
Hi guys,
I'm Bodie Solomon, an outsider on contract -- I've spoken to a few of you
in IRC. Gustavo suggested I email this list to clear up some difficulties
with our progress on implementing Actions.
Our job is to implement some new functionality to trigger execution of
"actions" on units and se
11 matches
Mail list logo
