Charm derivation

Gustavo Niemeyer gustavo.niemeyer at
Tue Jan 17 14:44:41 UTC 2012

> The same 15 - 20 lines of shell over and over gave rise to a need to stop
> cargo culting this and have a place for snippets of well tested, well
> written shell script that can be shared between charms and improved upon
> as a whole. Its easier to suggest to people that they use things like:
> ch_get_file "http://foo/bar.tgz" "aasdfasdfasdfasd8fasfd8as9d"

If you find this logic so important, lets have that in Ubuntu itself as a tool!

Maybe even wget itself:

    wget --check-sha1 $SUM $URL

> These get cargo culted like mad, and sometimes we spot something that
> needs fixing in one charm, but then have to go search all the other
> charms for the same mistake.  So using a library for this makes sense.

I agree. I just don't think these problems should all be solved within
juju itself.

> Formal leader election is, in fact, quite hard. However, given that we

s/Formal/Correct/ :-)

> have some guarantees in the way unit ids are numbered, we can actually
> do it very effectively in peer hooks. Because an id is never reused.. we
> can always say that we are, or are not, the leader, though pinpointing
> who is the leader, when you are not, is actually not reliable because
> we can't guarantee the atomicity of relation-list throughout a hook's
> execution. So this is not pure leader election of the usual kind, but
> it does allow us to say "if I am the leader, do X".

Huh? You just described why, actually, it doesn't allow you to say that.

What you are really saying is "It is broken, but I'm doing it
anyway.". That's fine for proof of concepts, but please be aware that
this will eat your lunch.

> This has proven useful in a few instances, such as with ceph, in picking a
> node to initialize the filesystem.  Because this only ever happens once,
> we can just say "if I am the leader, do the initialization", and then
> even if another node later on thinks it is the leader, it will not do

That's fine, but please let's not call that leader election then. By
definition, if you have two leaders working in parallel, there's no
leader election.

> anything because the filesystem is already initialized. Another example
> is when a shared key must be generated and disseminated to all units,
> this works to just pick one to be the generator and the others to wait
> for a key to arrive. It works because even if the generator dies between
> generating and setting, the others will receive a departed event and
> have another chance to check if they are the leader and generate the key.

You can also end up with multiple keys.

> I'm open to suggestions on how to get things into juju faster, but

Me too. :-)

> I figure doing them in charm-tools first has the added benefit of us
> charmers actually having tried something before asking for yet another
> feature. We've talked about *all* of these things in the past, and agreed
> they should be in juju (like a file downloader, and leader election). But
> time is limited, and this will suffice for most needs in the short term.

I understand, and appreciate a lot the fact you've been pushing things
forward. The point I'm raising is that you're recommending an approach
that actually isn't so great for what the name implies.

Gustavo Niemeyer

-- I'm not absolutely sure of anything.

More information about the Juju mailing list