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 <[email protected]>wrote: > On Thu, Mar 27, 2014 at 6:53 AM, Tim Penhey <[email protected]> > 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 [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
