Ask Ubuntu is a question and answer site for Ubuntu users and developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I see a lot of charms with both a relation-changed and a relation-joined hook for their relations. Sometimes the two hooks are even the same file, with one being a symlink to the other. However, the juju docs say that both the relation-joined and relation-changed hooks run when a relation is joined.

Should my charm include only one hook or the other, not both?

share|improve this question
up vote 5 down vote accepted

This depends on the use case for the charm. Here's a good way to think of what each relation hook does and when it's executed:


This is always the first hook to be executed, it's also only executed once during the lifespan of that specific service to service relation. There's now guarantee on which of the two services hook will fire first, but it will always be the first of the set of relation hooks to fire off. A lot of charms don't need this, but some charms this is very important. If you have any set-up details you need to execute first, then this is where they will happen. Take a database server for example: Most database server charms use the relation-joined hook to create the database, user, password, and other details that the other service will be waiting on. It could do this during the relation-changed hook, but it would add more complexity to make sure it didn't recreate the database and user over and over again (more on why that would happen in a second).


This gets run once right after a successful relation-joined execution. Then every time data is sent on the wire between the services this hook is executed again. As such, it really needs to be idempotent as it will likely be executed more than once. So a lot of charms will gather the expected relation-get data and make sure it exists before continuing. As to why both the relation-joined AND relation-changed hooks fire one after the other on the joined event is likely to allow for ease of use and not require a relation-joined hook explicitly.

As to what should your charm include, that's entirely up to you and the use case for your charm. Not every charm has a relation-joined, in fact few do considering the size of the store. It's really only used when there's an explicit need to do something only once during the lifecycle of that relation. Just so we're clear, when I mean "only once", I'm speaking about executing of the juju add-relation. If you add another relation to another service the relation-joined hook and the whole lifecycle starts over again. (since you can theoretically connect multiple services to one relation on one service)

share|improve this answer
Nice answer, thanks! So would you consider the case where both hooks exist and are exactly the same (i.e. symlinked) to be a bug? Sounds like in such cases one hook or the other should be deleted, depending on whether the hook is idempotent or not. – mars Apr 9 '13 at 23:50
@mars I wouldn't consider it a bug, the hook would have to be idempotent, if it didn't it wouldn't be deployable and shouldn't be in the store. By symlinking the two hooks you get the results you want just a little faster. Also, I believe earlier charms have this because it was a requirement as part of the charm policy (to have all four hooks for each relation). That policy has since laxed and now you really only need either a joined or changed hook for a relation to be valid (so long as that's all you actually need). – Marco Ceppi Apr 10 '13 at 1:40

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.