Allow one charm to provide either a primary or a subordinate service

[Mark Mims]

We have several services where one charm can be either a standalone or a subordinate service. It's silly to fork these if the only difference is `subordinate: true` in metadata.

Also, most charms can (should?) be written so that they are not split into separate standalone `-server` and subordinate `-client` charms... with even the potential for a third charm for a standalone-client.

We've seen a trend to combine separate client/server charms into a single charm that takes its behavior depending on the relations that are set. A great example of this is hadoop... oneiric had multiple charms: hadoop-master, hadoop-slave, hadoop-mapreduce
and now precise has just one charm:

     juju deploy hadoop hadoop-master
     juju deploy -n12 hadoop hadoop-slavecluster
     juju add-relation hadoop-master:namenode hadoop-slavecluster:datanode
     juju add-relation hadoop-master:jobtracker hadoop-slavecluster:tasktracker

Now, We'd like to do the same sort of thing with subs... perhaps something like:

    juju deploy nfs uploadstore
    juju deploy mediawiki mywiki
    juju deploy nfs upload-client --in mywiki (implicit juju-info relation added here)
    juju add-relation upload-client uploadstore

or maybe even simpler without the subordinate service name

    juju deploy nfs uploadstore
    juju deploy mediawiki mywiki
    juju deploy nfs --in mywiki (implicit juju-info relation added here)
    juju add-relation mywiki uploadstore

the latter would be somewhat more expected by a user.

[Clint Byrum (clint-fewbar)]

IMO we should just drop the 'subordinate' tag from metadata.yaml, and make this a runtime decision, with the default being to deploy a primary, and only subordinate things with one uses the --in or --with flags.

That was how we conceived of the idea originally, and I see it as a more straight forward way to deal with subordinate services.

[Aaron Bentley (abentley)]

So given the examples, it seems like nfs is not really a subordinate, because it has no concept of wikis, and vice versa. This is more a question of "placement policy". You want to colocate two services and not have to manage the individual instances, but the two services do not actually depend on each other. Deploying a new instance of "mywiki" shoould automatically drop "nfs" into it. You could do this manually with --to today, but it would be awkward to maintain.