<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Aug 18, 2014 at 9:33 PM, Gustavo Niemeyer <span dir="ltr"><<a href="mailto:gustavo@niemeyer.net" target="_blank">gustavo@niemeyer.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I don't think I fully understand the proposal there. To have such a<br>
"something-changed" hook, we ought to have a better mechanism to tell<br>
*what* actually changed. In other words, we have a number of hooks<br>
that imply a state transition or a specific notification ("install",<br>
"start", "config-changed", "leader-elected" coming, etc). Simply<br>
calling out the charm saying "stuff changed" feels like a bad<br>
interface, both in performance terms (we *know* what changed) and in<br>
user experience (how do people use that!?).<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I understand the underlying problem William is trying to solve but the<br>
current proposal doesn't seem like a complete solution on its own, and<br>
it also seems to change the existing understanding of the model<br>
completely. The proposed default-hooks is a trivial change to the<br>
existing well known workflow.<br></blockquote><div><br></div><div>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:</div>
<div><br></div><div> * 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; </div><div>
* 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).</div><div><br>
</div><div>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.</div>
<div><br></div><div>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)</div>
<div><br></div><div>Cheers</div><div>William</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im HOEnZb">
On Sun, Aug 17, 2014 at 2:30 AM, John Meinel <<a href="mailto:john@arbash-meinel.com">john@arbash-meinel.com</a>> wrote:<br>
</div><div class="HOEnZb"><div class="h5">> I'd just like to point out that William has thought long and hard about this<br>
> problem, and what semantics make the most sense (does it get called for any<br>
> hook, does it always get called, does it only get called when the hook<br>
> doesn't exist, etc).<br>
> I feel like had some really good decisions on it:<br>
> <a href="https://docs.google.com/a/canonical.com/document/d/1V5G6v6WgSoNupCYcRmkPrFKvbfTGjd4DCUZkyUIpLcs/edit#" target="_blank">https://docs.google.com/a/canonical.com/document/d/1V5G6v6WgSoNupCYcRmkPrFKvbfTGjd4DCUZkyUIpLcs/edit#</a><br>
><br>
> default-hook sounds (IMO) like it may run into problems where we do logic<br>
> based on whether a hook exists or not. There are hooks being designed like<br>
> leader-election and address-changed that might have side effects, and<br>
> default-hook should (probably?) not get called for those.<br>
><br>
> I'd just like us to make sure that we actually think about (and document)<br>
> what hooks will fall into this, and make sure that it always makes sense to<br>
> rebuild the world on every possible hook (which is how charm writers will be<br>
> implementing default-hook, IMO).<br>
><br>
> John<br>
> =:-><br>
><br>
><br>
><br>
> On Sat, Aug 16, 2014 at 1:02 AM, Aaron Bentley <<a href="mailto:aaron.bentley@canonical.com">aaron.bentley@canonical.com</a>><br>
> wrote:<br>
>><br>
>> -----BEGIN PGP SIGNED MESSAGE-----<br>
>> Hash: SHA1<br>
>><br>
>> On 14-08-15 04:36 PM, Nate Finch wrote:<br>
>> > There's new hook in town: default-hook. If it exists and a hook<br>
>> > gets called that doesn't have a corresponding hook file,<br>
>> > default-hook gets called with the name of the original hook as its<br>
>> > first argument (arg[1]).<br>
>> ><br>
>> > That's it.<br>
>><br>
>> Nice! Thank you.<br>
>><br>
>> Aaron<br>
>> -----BEGIN PGP SIGNATURE-----<br>
>> Version: GnuPG v1<br>
>><br>
>> iQEcBAEBAgAGBQJT7nVvAAoJEK84cMOcf+9h90UH/RMVabfJp4Ynkueh5XQiS6mD<br>
>> TPWwY0FVHfpAWEIbnQTQpnmkhMzSOKIFy0fkkXkEx4jSUt6I+iNYXdu8T77mA38G<br>
>> 7IZ7HAi+dAzRCrGTIZHsextrs5VpxhdzFJYOxL+TN5VUWYt+U+awSPFn0MlUZfAC<br>
>> 5aUuV3p3KjlHByLNT7ob3eMzR2mwylP+AS/9UgiojbUOahlff/9y83dYqkCDYzih<br>
>> C2rlwf0Wal12svu70ifggGKWcnF/eiwSm4TQjJsfMdCfw0gSg4ICgmIbWQ78OytJ<br>
>> AM4UBk1/Ue94dUm3YP+lcgAqJCC9GW5HksCFN74Qr+4xcnuqYoCJJxpU5fBOTls=<br>
>> =5YwW<br>
>> -----END PGP SIGNATURE-----<br>
>><br>
>> --<br>
>> Juju-dev mailing list<br>
>> <a href="mailto:Juju-dev@lists.ubuntu.com">Juju-dev@lists.ubuntu.com</a><br>
>> Modify settings or unsubscribe at:<br>
>> <a href="https://lists.ubuntu.com/mailman/listinfo/juju-dev" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju-dev</a><br>
><br>
><br>
><br>
> --<br>
> Juju-dev mailing list<br>
> <a href="mailto:Juju-dev@lists.ubuntu.com">Juju-dev@lists.ubuntu.com</a><br>
> Modify settings or unsubscribe at:<br>
> <a href="https://lists.ubuntu.com/mailman/listinfo/juju-dev" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju-dev</a><br>
><br>
<br>
<br>
<br>
</div></div><div class="im HOEnZb">--<br>
<br>
gustavo @ <a href="http://niemeyer.net" target="_blank">http://niemeyer.net</a><br>
<br>
</div><div class="HOEnZb"><div class="h5">--<br>
Juju-dev mailing list<br>
<a href="mailto:Juju-dev@lists.ubuntu.com">Juju-dev@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju-dev" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju-dev</a><br>
</div></div></blockquote></div><br></div></div>