Allow one charm to provide either a primary or a subordinate service
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| juju-core |
Won't Fix
|
Low
|
Unassigned | ||
| pyjuju |
Triaged
|
Wishlist
|
Unassigned | ||
Bug Description
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-
juju add-relation hadoop-
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.
| summary: |
- Allow one charm to be either a primary or a subordinate service + Allow one charm to provide either a primary or a subordinate service |
| description: | updated |
| Clint Byrum (clint-fewbar) wrote | #1 |
| description: | updated |
| description: | updated |
| Changed in juju: | |
| importance: | Undecided → Wishlist |
| Changed in juju: | |
| status: | New → Triaged |
| tags: | added: canonical-is |
| Aaron Bentley (abentley) wrote | #2 |
| Changed in juju-core: | |
| status: | New → Triaged |
| importance: | Undecided → Low |
| tags: | added: charms |
| Changed in juju-core: | |
| status: | Triaged → Won't Fix |
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.