On Mon, Aug 18, 2014 at 9:33 PM, Gustavo Niemeyer <gust...@niemeyer.net>
wrote:
> I don't think I fully understand the proposal there. To have such a
> "something-changed" hook, we ought to have a better mechanism to tell
> *what* actually changed. In other words, we have a number of hooks
> that imply a state transition or a specific notification ("install",
> "start", "config-changed", "leader-elected" coming, etc). Simply
> calling out the charm saying "stuff changed" feels like a bad
> interface, both in performance terms (we *know* what changed) and in
> user experience (how do people use that!?).
>
The issue is that as charms increase in sophistication, they seem to find
it harder and harder to meaningfully map specific changes onto specific
actions. Whether or not to react to a change in one relation depends on the
values of a bunch of other units in other relations, to the extent that any
individual relation change can have arbitrarily far-reaching consequences,
and it ends up being easier to simply write something that maps directly
from complete-available-state to desired-config.
This situation seems to be leading more people to actually write (or depend
on) frameworks similar to the one Ben presented in Nuremberg (to, I
thought, a positive reception). Not all charms necessarily want or need to
be written this way -- perhaps the bulk of them shouldn't -- but those that
already *are* end up with really yucky execution patterns: they run the
same code *again and again*, potentially hundreds of times, quite probably
repeatedly bouncing the service -- and ofc spamming the state server with
flushes for every hook executed, and probably spamming other units with
multiple relation changes; and in general taking much longer to arrive at
the ideal state.
This style of charm evidently *works* right now, it's true, but it's both
yucky and unnecessary to run so many hooks to no purpose. And if some
reasonable subset of charmers are tending that way anyway, let's make sure
juju can take advantage of the situation and use those charms to full
effect.
I understand the underlying problem William is trying to solve but the
> current proposal doesn't seem like a complete solution on its own, and
> it also seems to change the existing understanding of the model
> completely. The proposed default-hooks is a trivial change to the
> existing well known workflow.
>
It's not *quite* so trivial when you consider unknown future hooks: we need
to be careful that we don't run it in situations where the charm may not be
prepared to deal with the specific features of the hook context. Off the
top of my head:
* relation-config-changed will have something that looks very much like a
normal relation context, but lacking JUJU_REMOTE_UNIT; the only other
context looking like that is relation-broken;
* leader-deposed will completely lack hook tools: we can't run a
default-hook there unless we know for sure that the implementation doesn't
depend on any hook tools (in general, this is unlikely).
But if the default substitution only happens for scheduled hooks (it does,
thanks Nate) and if we're careful not to expose new features to charms that
don't know them (which we shall have to be anyway, lest unpredictably ugly
consequences), then we'll be fine.
And FWIW, +100 to $JUJU_HOOK_NAME. The argv stuff is deeply opaque -- sure,
argv[0] is obvious, but argv[1] is not; and it won't even be there when
people invoke it directly via debug-hooks or run, so a clearly-named env
var is surely the right way to go. (Apart from anything else, the
environment is where we put most of the other data pertaining to a
particular context: $JUJU_RELATION_ID, $JUJU_REMOTE_UNIT, etc etc)
Cheers
William
On Sun, Aug 17, 2014 at 2:30 AM, John Meinel <j...@arbash-meinel.com> wrote:
> > I'd just like to point out that William has thought long and hard about
> this
> > problem, and what semantics make the most sense (does it get called for
> any
> > hook, does it always get called, does it only get called when the hook
> > doesn't exist, etc).
> > I feel like had some really good decisions on it:
> >
> https://docs.google.com/a/canonical.com/document/d/1V5G6v6WgSoNupCYcRmkPrFKvbfTGjd4DCUZkyUIpLcs/edit#
> >
> > default-hook sounds (IMO) like it may run into problems where we do logic
> > based on whether a hook exists or not. There are hooks being designed
> like
> > leader-election and address-changed that might have side effects, and
> > default-hook should (probably?) not get called for those.
> >
> > I'd just like us to make sure that we actually think about (and document)
> > what hooks will fall into this, and make sure that it always makes sense
> to
> > rebuild the world on every possible hook (which is how charm writers
> will be
> > implementing default-hook, IMO).
> >
> > John
> > =:->
> >
> >
> >
> > On Sat, Aug 16, 2014 at 1:02 AM, Aaron Bentley <
> aaron.bent...@canonical.com>
> > wrote:
> >>
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >> On 14-08-15 04:36 PM, Nate Finch wrote:
> >> > There's new hook in town: default-hook. If it exists and a hook
> >> > gets called that doesn't have a corresponding hook file,
> >> > default-hook gets called with the name of the original hook as its
> >> > first argument (arg[1]).
> >> >
> >> > That's it.
> >>
> >> Nice! Thank you.
> >>
> >> Aaron
> >> -----BEGIN PGP SIGNATURE-----
> >> Version: GnuPG v1
> >>
> >> iQEcBAEBAgAGBQJT7nVvAAoJEK84cMOcf+9h90UH/RMVabfJp4Ynkueh5XQiS6mD
> >> TPWwY0FVHfpAWEIbnQTQpnmkhMzSOKIFy0fkkXkEx4jSUt6I+iNYXdu8T77mA38G
> >> 7IZ7HAi+dAzRCrGTIZHsextrs5VpxhdzFJYOxL+TN5VUWYt+U+awSPFn0MlUZfAC
> >> 5aUuV3p3KjlHByLNT7ob3eMzR2mwylP+AS/9UgiojbUOahlff/9y83dYqkCDYzih
> >> C2rlwf0Wal12svu70ifggGKWcnF/eiwSm4TQjJsfMdCfw0gSg4ICgmIbWQ78OytJ
> >> AM4UBk1/Ue94dUm3YP+lcgAqJCC9GW5HksCFN74Qr+4xcnuqYoCJJxpU5fBOTls=
> >> =5YwW
> >> -----END PGP SIGNATURE-----
> >>
> >> --
> >> Juju-dev mailing list
> >> Juju-dev@lists.ubuntu.com
> >> Modify settings or unsubscribe at:
> >> https://lists.ubuntu.com/mailman/listinfo/juju-dev
> >
> >
> >
> > --
> > Juju-dev mailing list
> > Juju-dev@lists.ubuntu.com
> > Modify settings or unsubscribe at:
> > https://lists.ubuntu.com/mailman/listinfo/juju-dev
> >
>
>
>
> --
>
> gustavo @ http://niemeyer.net
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
--
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju-dev
