New modified hook semantic
clint at ubuntu.com
Mon Mar 21 17:55:30 UTC 2011
Apologies for replying to James' message instead of the original, but my
subscription to the ensemble list was in limbo when it was sent, so this
is the simplest way. Reply below.
On Sun, 2011-03-20 at 10:33 -0400, James Westby wrote:
> On Fri, 18 Mar 2011 17:15:30 -0300, Gustavo Niemeyer <gustavo.niemeyer at canonical.com> wrote:
> > == Proposal ==
> > To address these problems, I propose we change the mechanism of change
> > notification in the following way:
> > 1) Split relation-changed into three hooks: relation-joined,
> > relation-changed, and relation-departed
I do not like splitting them. The shared code is *very* useful and it
makes the hooks easier to write. Most hooks can be 20 - 30 lines of
shell script now (even once we fix them to actually respect
Most formulas will have some things shared between the 3 conditions.
Paths, restarting services, whatever. Splitting the hooks means also
creating a hooks-common.sh that has to be sourced, or something like
that. 1 hook for each relation's joined/modified/departed is still
> > 2) relation-joined and relation-departed map exactly to the respective
> > events which used to happen with relation-changed.
> > 3) The new relation-changed hook is called *unconditionally* right
> > after relation-joined, and then any time data changes since the last
> > execution (with the current behavior related to caching preserved).
I do like this idea. One is to tell you to setup for the relation, feed
any data you have implicitly into the relation, etc. The other is to
tell you to consume.
But really, the mistake that I made and others made was that we believed
the two-way communication between nodes was half-duplex, requiring one
side to kick off the communication in joined, and then the modifieds
would start bouncing back and forth. This was mostly due to limiting
beliefs, not reality.
I actually would suggest that nothing be changed except the examples. It
should be commented very well in the examples and shown that the data
must be checked on joined *and* modified. By doing it this way, we get
the tightest execution loop possible in a loaded scenario.
The examples I started out with did not make that clear, even though
they did handle the situation appropriately. I think if we just fix
principia, and the example formulas, people won't repeat the mistake,
and the formulas will remain very simple.
More information about the Ensemble