Hi
On Fri, Apr 14, 2017 at 8:19 PM, fengxia <fx...@lenovo.com> wrote:
> I'm learning charm development and confused about state vs. hook.
>
Welcome to charm authoring!
So, as you're probably starting to work out, hooks and states are different
things. I'll try to explain the difference.
Hooks:
At it's simplest, a hook is an executable in the 'hooks' directory of a
charm. The Juju agent that looks after the unit calls the 'hook'
executable at certain points during the lifetime of the charm. i.e. start,
install, config-changed, update-status, etc.
The hook executable can be a bash script, a python script or even (and
don't do this!) a compiled C binary. Anything that can be an executable
can be a hook.
States:
This is a concept that is associated only with the charms.reactive library.
i.e. you can write charms in Python without the charms.reactive library.
It isn't suggested that you do, because charms.reactive really, really
helps to simplify and ease the writing of charms.
Conceptually, I guess these are a bit harder to grab hold of. A state is
an indicator that a charm author (or interface author) sets when some
condition/state has been achieved. i.e. the software under control has
been installed, or a relation (interface in charms.reactive terminology)
has been connected, etc. This state is remembered between invocations of
the charm code.
Putting it together:
For any of the charm code to run (at all), Juju calls a hook executable in
the hooks directory.
For a charms.reactive charm, any of the hooks (usually) results in the same
charm code being loaded. Thus, from the perspective of a charms.reactive
based charm, all hooks are treated the same.
The charms.reactive library does support hooks (using a the @hook
decorator) and these are run before any reactive handlers (@when,
@when_not). The named hook decorator (@hook('update-status')) is run
according to the actual hook executable (in the hooks directory) that Juju
called. Then the conditions described by the reactive handlers (@when...)
are evaluated and any that are 'true' are executed. This continues until
no more handlers' conditions are true.
So, it's important to remember that for a charms.reactive type charm, any
and every hook that Juju calls could result in any of the reactive handlers
being called depending on the states that the charm has previous set (or
its interfaces).
So, on to your questions:
>
> I used @when_not("state.0") to mark the very first function that gets
> executed. In document it also says "install" hook will be the first to
> execute. Tried @hooks.hook("install") but it just failed at charm
> installation.
>
Okay, so with reactive handlers there is no 'first' function. Any handler
that has conditions that evaluate to 'true' will be run, and the ordering
should be considered arbitrary.
The named hook (if a @hook is used) will execute before reactive handlers.
>
> So what is the right way to determine the "entry" point in a charm? I mean
> the first function block that will be executed. I'm thinking to use chained
> state from that point on to guide execution process. Is this the right
> approach?
So the very first time a reactive charm is executed there will be no states
set. It's recommended to avoid using @hook decorators unless absolutely
necessary. Luckily, installation of the underlying software doesn't need
hooks!
The normal way is to to use a @when_not('installed') condition on the
handler that will either do, or at least kick off the installation, and
then set it when the installation is complete. Remember that every
reactive handler should be idempotent for the state conditions that it
handles.
So:
@when_not('installed')
def install_software():
... install the software ...
set_state('installed')
i.e. you are on the right approach!
Hope that this helps.
All the best
Alex.
>
> --
> Feng xia
> Engineer
> Lenovo USA
>
> Phone: 5088011794
> fx...@lenovo.com
>
> Lenovo.com
> Twitter | Facebook | Instagram | Blogs | Forums
>
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
> an/listinfo/juju
>
--
Alex Kavanagh - Software Engineer
Cloud Dev Ops - Solutions & Product Engineering - Canonical Ltd
--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
