First customer pain point pull request - default-hook

[Marco Ceppi]

This might be a true problem when you don't map what event should fire what
code in the hook. The majority, if not all, of charms that currently
implement this pattern do so by either using charm-helpers or by having a
giant if/else case statement at the bottom of the hook which maps which
code should execute with each hook that has invoked the symlink'd file. I
can take a survey of current charms which use symlinks to see if any don't
fit this pattern.


On Sun, Aug 17, 2014 at 6:28 AM, John Meinel <john at arbash-meinel.com> wrote:

> The main problem with having a hook that just fires instead of the others
> is that you end up firing a hook a whole bunch of times where it
> essentially "does nothing" because it is still waiting for some other hook
> for it to actually be ready. The "something-changed" proposal essentially
> colapses the 10 calls to various hooks into a single firing.
>
> William has thought much more about it, so I'd like him to fill in any
> details I've missed.
>
> John
> =:->
>
>
>
> On Sun, Aug 17, 2014 at 1:59 PM, Nate Finch <nate.finch at canonical.com>
> wrote:
>
>> That's an interesting document, but I feel like it doesn't really explain
>> the problem it's trying to solve.
>>
>> Why does a single entry point cause a lot of boilerplate (I presume he
>> means code boilerplate)? Isn't it just a switch on the name of the hook?
>>  What does it mean "when a new hook is introduced"?  Doesn't the charm
>> define what hooks it has?  And wouldn't the aforementioned switch mean that
>> any new hook (whatever that means) would be ignored the same way it would
>> if the hook file wasn't there?
>>
>> Can someone explain to me what exactly the problem is?
>>
>>
>> On Sun, Aug 17, 2014 at 1:30 AM, John Meinel <john at 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.bentley at 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 at lists.ubuntu.com
>>>> Modify settings or unsubscribe at:
>>>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>>>>
>>>
>>>
>>> --
>>> Juju-dev mailing list
>>> Juju-dev at lists.ubuntu.com
>>> Modify settings or unsubscribe at:
>>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>>>
>>>
>>
>
> --
> Juju-dev mailing list
> Juju-dev at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20140817/fd1f1bc2/attachment.html>