Defining a new interface

[Clint Byrum]

Excerpts from Torsten Schlabach's message of 2012-11-06 07:38:29 -0800:
> Hi Bruno!
> 
> Thanks for the clarifications.
> 
> Just I think there is one puzzle piece missing yet.
> 
> So I will write two charms:
> 
> openldap:
> 
> provides:
>   directory:
>     interface: ldapv3
> 
> 
> adressbookapp:
> 
> requires:
>   directory:
>     interface: ldapv3
> 
> 
> I assume there has to be some magic hidden in the Juju harness which would then go ahead and upon creation of a directory-ldap relationship create a user in the LDAP server for me (maybe also add schemas, but this is different piece of cake) and provide the ldap server host, port and credentials in some variables in my addressbookapp add-relation hook?
> 
> To continue the MySQL analogy, I am looking at Wordpress:
> 
> http://bazaar.launchpad.net/~charmers/charms/precise/wordpress/trunk/view/head:/hooks/db-relation-changed
> 
> Lines 15-18 are:
> 
> database=`relation-get database`
> user=`relation-get user`
> password=`relation-get password`
> host=`relation-get private-address`
> 
> So in my adressbookapp charm I guess I would write a hook called directory-relation-changed which reads
> 
> ldaptreeroot=`relation-get ldaptreeroot`
> userDN=`relation-get userDN`
> password=`relation-get password`
> host=`relation-get private-address`
> 
> Can I just write into my directory-relation-joined hook in my openldap charm:
> 
> relation-set userDN=cn=admin,o=world
> ...
> 
> and that's it?
> 
> Looking at the actual mysql charm, I still have the problem that I can spot where the password is generated, where the hostname comes from but not how the name of the user and the database is generated. The values of user and database_name variables seem to be defined outside that hook script. Just as a side question ...
> 

Hi Torsten, you're almost there I think.

The user is created starting here:

http://bazaar.launchpad.net/~charmers/charms/precise/mysql/trunk/view/head:/hooks/db-relation-joined#L37

Some of the logic for determining user and password is in common.py so
that the other hooks that need it can share.

There's some simplification of the mysql charm in the pipeline right
now, and I would actually suggest that you avoid using mysql's hooks
as a model until those changes land. The mysql charm was basically the
second charm ever to be written, and as such, it has some very old ways
of doing things.

Usually the pattern is to key most things off of $JUJU_RELATION_ID. This
makes it easier to clean up upon a broken relationship. So for your
LDAP charm you might want to generate credentials, put them in the
ldap server, and store them in a file private to the charm whose name
is based off of $JUJU_RELATION_ID. You then relation-set the values,
which exposes them to the other service units.

This way on the next joined hook, you just check for the private file
based on $JUJU_RELATION_ID, and you actually don't have to do anything
more.  because you've already dealt with enabling that remote service,
and the remote service will automatically run the -changed hook, and
upon seeing the credentials, use them. If this seems a little confusing,
it can be.  But basically, for any unit in a relationship, that unit
only has one relation-set bucket of data to share with all of the remote
units in said relationship. So, for instance, you can't make a unique
username/password per remote unit, but you can restrict access to the
individual remote addresses.

Thanks for working on this Torsten, Its good to see somebody working
on LDAP, as I can see it being useful for a lot of different things
in the charm ecosystem.