Inconsistency with relation names?

[Clint Byrum]

Excerpts from Marco Ceppi's message of 2012-08-17 21:13:23 -0700:
> Hey everyone,
> 
> I was going through the different charms, their relations, and 
> ultimately the interfaces they provide/consume. One thing I noticed was 
> an inconsistency of relation names (or what I think is called the 
> "relation name"). I know there was chatter of eventually solidifying 
> interface specs and names, but would that include (what I've been 
> referring to as) relation names?
> 

I believe "relation name" is correct. See this from 'juju add-relation
--help':

usage: juju add-relation [-h] [--environment ENVIRONMENT] [--verbose VERBOSE]
                         <service name>[:<relation name>] <service
                         name>[:<relation name>]

positional arguments:
  <service name>[:<relation name>]
                        Define the relation endpoints to be joined.


> Here's a few examples:
> 
> We have a rockin' MySQL[1] charm which at it's core provides a db 
> relation using the mysql interface (db being the relation name). There's 
> another sweet charm, MongoDB[2], which provides a database relation 
> using the mongodb interface. I'm under the impression that the relation 
> names for these two charms _should_ be the same, right?
> 
> If so, there are some other common "relation names" that I think should 
> be fixed or considered. I would assume that these would be bugs opened 
> for each charm it affects but another example would be the nfs[3] charm 
> which provides both an nfs relation and interface. This causes a bit of 
> a conflict with a few of the up-and-coming shared filesystems (which nfs 
> falls under that category). Those other charms are using a shared-fs[4] 
> relation name and either nfs, mount, or another interface name.
> 

Thanks for thinking about this Marco. We should probably put this down
in the set of "aspirations" that we will be defining for official charms
soon, as it may be hard to enforce relation naming.

I tend to try to name the relation so that add-relation reads like
english if you put the "provider" first and "as" in the middle:

juju add-relation mysql:db wordpress:db

is

juju add-relation mysql:db as wordpress:db

This is already broken with haproxy tho:

juju add-relation myblog:website as haproxy:reverseproxy

It would be better if I had named it 'target' or 'backend':

juju add-relation myblog:website as haproxy:backend

It might even make sense to make the 'as' keyword optional to remind
users of this distinction.

> UDS will probably be the best place to open discussions about how to 
> handle this (if this is indeed an issue) but I wanted to start poking to 
> see if what I'm thinking makes sense and how to handle this.
> 

UDS is really for making hard decisions and hashing out unclear plans. I
think we can probably get a lot of this done here on the mailing list and
leave the session for any sticky bits that we can't get around here.