On 22 August 2014 10:43, Marco Ceppi marco.ce...@canonical.com wrote:
So there is already a JUJU_HOOK_NAME environment variable. So that is easy
enough. I'm not sure what the issue is with having a default-hook file that
is executed when juju can't find that hook name.
I don't want to make it
On Wed, Aug 20, 2014 at 12:29 AM, Kapil Thangavelu
kapil.thangav...@canonical.com wrote:
hmm.. there's three distinct threads here.
default-hook - charms that do so symlink 0-100% - to one hook.. in
practice everything, sometimes minus install (as the hook infrastructure
needs pkgs).. and
I'm not attempting to cause trouble here - I just want to make sure I
understand the feature - and what effects it might have.
It sounds like any implementation of the default-hook would need to start
with something like: (pseudo-bash)
if JUJU_HOOK_NAME == start
//run start
else if
On Wed, Aug 20, 2014 at 10:46 AM, Matthew Williams
matthew.willi...@canonical.com wrote:
Any default-hook that deviated from this pattern could find itself being
run multiple times in succession - I wonder if that might be confusing/
unexpected to a charm author?
It'll run multiple times in
On Wed, Aug 20, 2014 at 5:46 AM, Matthew Williams
matthew.willi...@canonical.com wrote:
if JUJU_HOOK_NAME == start
//run start
else if JUJU_HOOK_NAME == config-changed
//run config-changed
else if JUJU_HOOK_NAME == stop
//run stop
else
//unknown hook
exit 1
fi
I'd expect the else
On Wed, Aug 20, 2014 at 11:08 AM, William Reade
william.re...@canonical.com wrote:
On Wed, Aug 20, 2014 at 10:46 AM, Matthew Williams
matthew.willi...@canonical.com wrote:
Gustavo's observation about hooks that the charm might no know about yet
means that the else clause is absolutely
On Wed, Aug 20, 2014 at 11:16 AM, Nate Finch nate.fi...@canonical.com wrote:
Anyone who has ever written a switch statement should be used to putting in
a default clause for something I don't expect... I don't think it should
be a big deal.
Some charms mentioned in this thread miss the switch
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 14-08-20 10:50 AM, Nate Finch wrote:
If the special hook file is called default-hook, it makes those
single-script charms seem like less of a hack than if the single
file is called missing-hook. It would also makes more sense to a
new charm
On Wed, Aug 20, 2014 at 11:46 AM, Gustavo Niemeyer gust...@niemeyer.net
wrote:
People must be aware that there
is a multitude of events dispatched to that one executable,
potentially with events they do not expect, and they must be aware
that by creating a different hook they will prevent
On Wed, Aug 20, 2014 at 3:45 PM, Nate Finch nate.fi...@canonical.com wrote:
Here's a proposal that is much simpler: we add a flag to the charm metadata,
called something like single_hook. When single_hook is true, all hook
events run a file called default-hook (or whatever we want to call it,
On Wed, Aug 20, 2014 at 5:05 PM, Nate Finch nate.fi...@canonical.com wrote:
I think to answer most of these questions, we need more information about
what the existing charms do, and input from the charmers themselves.
Here's the info from Marco: http://pastebin.ubuntu.com/8100649/
Thanks.
On 21/08/14 02:50, Nate Finch wrote:
I would expect a lot of people will implement their charms as a single
script (especially given the number of charms we've seen implemented
that way even with minimal support for it). If the special hook file is
called default-hook, it makes those
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
On Tue, Aug 19, 2014 at 9:07 AM, William Reade
william.re...@canonical.com wrote:
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 14-08-19 10:36 AM, Gustavo Niemeyer wrote:
On Tue, Aug 19, 2014 at 11:00 AM, Aaron Bentley
aaron.bent...@canonical.com wrote:
On 14-08-19 09:42 AM, Gustavo Niemeyer wrote:
I have never seen myself a single charm that completely
ignores all
On Tue, Aug 19, 2014 at 4:00 PM, Aaron Bentley aaron.bent...@canonical.com
wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 14-08-19 09:42 AM, Gustavo Niemeyer wrote:
I have never seen myself a single charm that completely ignores
all the action cues to simply re-read the whole
On Tue, Aug 19, 2014 at 4:59 PM, Aaron Bentley aaron.bent...@canonical.com
wrote:
True, I didn't call out the exceptions for the charmworld charm. For
completeness, the exceptions in charmworld are:
install
nrpe-external-master-relation-changed
restart
(this isn't actually a hook?)
On Tue, Aug 19, 2014 at 12:41 PM, William Reade
william.re...@canonical.com wrote:
(out of interest, if started/stopped state were communicated to you any
other way, would you still need these?)
If you communicate events in a different way, you obviously won't need
your previous way of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 14-08-19 11:41 AM, William Reade wrote:
On Tue, Aug 19, 2014 at 4:59 PM, Aaron Bentley
aaron.bent...@canonical.com mailto:aaron.bent...@canonical.com
wrote:
reverseproxy-relation-joined start stop
(out of interest, if started/stopped
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 14-08-19 11:41 AM, Gustavo Niemeyer wrote:
On Tue, Aug 19, 2014 at 11:59 AM, Aaron Bentley
aaron.bent...@canonical.com wrote:
At the same time, the strictness of redoing everything all the time
is not necessary, and a good example is still
On Tue, Aug 19, 2014 at 1:10 PM, Aaron Bentley
aaron.bent...@canonical.com wrote:
True. At that point, the pattern is not a win, but it's not much of a
loss. Changing the web site relation is extremely uncommon, but
operations which do require server restarts are quite common. So
making an
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 14-08-19 12:46 PM, Gustavo Niemeyer wrote:
On Tue, Aug 19, 2014 at 1:10 PM, Aaron Bentley
aaron.bent...@canonical.com wrote:
True. At that point, the pattern is not a win, but it's not much
of a loss. Changing the web site relation is
Something to be mindful of is that we will shortly be implementing a new
hook for metering (likely called collect-metrics). This hook differs
slightly to the others in that it will be called periodically (e.g. once
every hour) with the intention of sending metrics for that unit to the
state
On Tue, Aug 19, 2014 at 6:58 PM, Matthew Williams
matthew.willi...@canonical.com wrote:
Something to be mindful of is that we will shortly be implementing a new
hook for metering (likely called collect-metrics). This hook differs
slightly to the others in that it will be called periodically
hmm.. there's three distinct threads here.
default-hook - charms that do so symlink 0-100% - to one hook.. in
practice everything, sometimes minus install (as the hook infrastructure
needs pkgs).. and most typically implemented via dispatch table.
something-changed - completely orthogonal to
On Wed, Aug 20, 2014 at 3:07 AM, Aaron Bentley
aaron.bent...@canonical.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 14-08-19 12:46 PM, Gustavo Niemeyer wrote:
On Tue, Aug 19, 2014 at 1:10 PM, Aaron Bentley
aaron.bent...@canonical.com wrote:
True. At that point, the pattern
On Fri, Aug 15, 2014 at 4:36 PM, Nate Finch nate.fi...@canonical.com 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]).
I
Rather than passing it as the first argument, I suggest introducing an
environment variable: $JUJU_HOOK_NAME. This would be set irrespective
of how the hook is being called, so that the same hook can be used
both as a symlink and as a default-hook, unchanged. It also means further
spawned
That doc implies a completely different style of authoring ie. rewrite then
of most extant (95%) charms using symlinks to a single implementation.
There are a minority that do indeed reconsider all current state from juju
each hook invocation, in which case this level of optimization is useful,
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,
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
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
-BEGIN PGP MESSAGE-
Charset: windows-1252
Version: GnuPG v1
hQIMA233D38ktbXXAQ//W+ymYmuIbjOlDOtOTwJ494ZP5dB0K4ITftBo8ESeZDjM
m+av246NKJlXsH+iyFJNOUC3ouaNF/W/1NuBCJXa/IJNKX//TyMCVF3yh5m5R77h
CWbcTwguameiDsA0pmcuf1ezZgtFA3SeSf9Tuhu5CkGbRVXkSunQOTwP7nAUcYsC
WTH happened there?
/me tries to remember what he wrote.
Tim
--
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju-dev
-BEGIN PGP MESSAGE-
Charset: windows-1252
Version: GnuPG v1
hQIMA233D38ktbXXAQ/+OxwEOmqX/SS+lyJGh7WBYOZge3P8G9+bdu0u8v/sGioD
xbPcpRAp4D3GaCyaMS231JTdvWjMgegw9f6AnnaeLiEdcmFi3YBEzvnDCR5+Lfpb
KNMZFUsL9CYtsBy+tWBFkowsFwiKy66UiOQDRGW6G6V+5v/L2v4TUoDN+LE74/h2
Nope, still not receiving you clearly
On Mon, Aug 18, 2014 at 7:20 AM, Tim Penhey tim.pen...@canonical.com wrote:
-BEGIN PGP MESSAGE-
Charset: windows-1252
Version: GnuPG v1
hQIMA233D38ktbXXAQ/+OxwEOmqX/SS+lyJGh7WBYOZge3P8G9+bdu0u8v/sGioD
On 18/08/14 09:11, Tim Penhey wrote:
WTH happened there?
/me tries to remember what he wrote.
Tim
Some encryption settings have been changed somewhere.
Again, what I was saying was that my concerns seem to be moot after
reading the code.
As long as the script can be told which hook is
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:
Just wanted to let people know that Moonstone is ramping up on the customer
pain points, even ahead of the full spec and prioritization. I had talked
to Jorge and Marco about what they thought was important, and they pointed
out a couple of low hanging fruit. This was one of them.
Many charms
-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
40 matches
Mail list logo
