Relation ordering: Does it matter?

Gustavo Niemeyer gustavo.niemeyer at canonical.com
Tue Feb 7 18:01:18 UTC 2012


On Tue, Feb 7, 2012 at 14:56, Adam Gandelman <adamg at canonical.com> wrote:
> Hi Guys-
>
> Sorry for being late.  A couple of things.
>
> The issue with keystone is not that the service is not functional without a
> database--it can.  But, when initially deployed, its default is to use a
> local sqlite database.  If the ordering is not taken into account during
> deployment, you can end up with something like the following.  Each relation
> to another service adds an entry into keystones API/service catalog:
>
> deploy keystone
> relation glance->keystone
> relation dashboard -> keystone
> relation mysql -> keystone
> relation nova -> keystone
>
> When the mysql relation hits, keystone is using a fresh database. By the end
> of the deployment, the glance+dashboard entries are missing and the cloud as
> a whole is broken.  Someone in the past has suggested this should be
> accounted for in the charm, that is, the database relations should contain
> some hooks to migrate data from one backend to another.  This sounds like a
> nightmare, especially in production.

Yeah, this is quite an interesting example, and it's unlike what I had
in mind. Thanks for bringing it up.

In this scenario, ordering doesn't help, and required relations also
do not help, because neither of those options will account for the
fact that this single charm can work in a standalone mode, and may
also work with a mysql relation being added shortly after the other
relations were established. I also agree that migrating the data feels
fragile, even more considering that the mysql relation could be added
a long time after the service has been running standalone.

To be honest, I'm tempted to suggest that they should really be two
separate charms: one that has a mysql relation, and only works against
mysql, and one that doesn't have a mysql relation, and works
standalone only. They'll of course share a lot of data, and likely be
just different branches of the same Bazaar repository, but it feels
like this would yield the most pleasant user experience, and make the
other choices trivial on the charm development side.

What do you think?

> I like Gustavo's idea of being able to trigger a replay of relation hooks
> after certain events occur.  In this case, being able to exec relation-set
> any time a new database is introduced and request a replay of hooks starting
> from *-joined would be valuable.

Just to be clear, it's not a replay. It's a normal relation-set, which
will cause remote units to get their -changed hooks called because
there's new data in the relation. Nothing magical there.

-- 
Gustavo Niemeyer
http://niemeyer.net
http://niemeyer.net/plus
http://niemeyer.net/twitter
http://niemeyer.net/blog

-- I'm not absolutely sure of anything.



More information about the Juju mailing list