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 know that all those questions need to be answered in a first draft. John =:-> On Thu, Mar 27, 2014 at 1:53 PM, Tim Penhey <[email protected]>wrote: > 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 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.) > > 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. > > The actual execution of the commands is done in a hook context if the > target is a unit, and as the ubuntu user in the /home/ubuntu directory > if the target is a machine. The machine execution is also serialized on > the machine by grabbing the hook execution lock. > > > 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). > > This line of thinking was thought about when we implemented juju run. > > The concepts behind juju in general is that we record the state of the > world as we'd like it to be, and then the provisioner makes machines, > and the machine agents and unit agents make the machines install and run > what fits with this world view. > > > I think Gustavo's outline fits well with that, and is a reason to *not* > > use the juju-run mechanism. > > The outline that Gustavo has given has actions fit into this world view. > A key missing bit here is who is the target of the action? > > Is it a service? Or a unit of the service? > > If we are looking at actions like "backup database", then I'd guess that > the target is the service, but do we care which unit does the actual > backing up? What about when an action requires synchronisation across > different services? Where does the action live? > > Tim >
-- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
