Coordinating actions in a service

[John Weldon]

Actions are not hooks, but they are run in a similar fashion as hooks.  I
don't know of any restriction keeping actions from communicating with peers
before the action completes, but that would be something we'd need to
address for Actions 2.0 certainly.

I like the concept of metering actions out to units of a service; I would
expect that to happen when targeting an action to the service instead of
specific units which would require the leader to decide how to fan out the
actions.

The implementation details for Actions 2.0 are still very conceptual; I'll
certainly be calling on you for opinions this go around as we're
implementing them :)

Cheers,


--
John Weldon

On Fri, May 8, 2015 at 6:35 AM, Gustavo Niemeyer <gustavo at niemeyer.net>
wrote:

>
>
> On Fri, May 8, 2015 at 10:24 AM, John Weldon <johnweldon4 at gmail.com>
> wrote:
>
>> Hi Stuart;
>>
>> I think this is addressed in the proposed work for Actions 2.0
>>
>> In the current model you'd have to manage all of this yourself.  Actions
>> can only be targeted to specific units in the current implementation, so
>> you'd have to manage the distribution outside of actions (or else, as you
>> suggest, some sort of generalised semaphore service, and a way to find all
>> units of a service and queue up actions for all of them and have the
>> actions individually manage themselves whether to run or not)
>>
>> The plan is to allow actions to be targeted at 1) specific units in a
>> service, 2) leaders only, 3) all units in a service, or 4) a subset of
>> units in a service.  This would still be a little tricky for your use case,
>> but you could at least manage all the logic in an action targeted at only
>> the leader for example.
>>
>
> None of these seem to fix the issue, though. The requirement is to execute
> on all units, but not at the same time. Also, the leader has no way to
> communicate with peer units without the hook terminating, right? There
> should be a way to postpone the result of an action to a moment past the
> end of the hook, but I actually think the proper way to fix this is to
> avoid the avalanche in the first place, by default: when dispatching an
> action to all units of a service, roll out in a sane way rather than doing
> all at once.
>
>
> gustavo @ http://niemeyer.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20150508/b7371fc1/attachment.html>