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

Bug #1015637 reported by Mark Mims on 2012-06-20
28
This bug affects 5 people
Affects Status Importance Assigned to Milestone
juju-core
Low
Unassigned
pyjuju
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-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.

Mark Mims (mark-mims) on 2012-06-20
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 :

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.

description: updated
description: updated
Changed in juju:
importance: Undecided → Wishlist
Curtis Hovey (sinzui) on 2013-10-12
Changed in juju:
status: New → Triaged
Tom Haddon (mthaddon) on 2014-03-04
tags: added: canonical-is
Aaron Bentley (abentley) wrote :

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.

Changed in juju-core:
status: New → Triaged
importance: Undecided → Low
Curtis Hovey (sinzui) on 2014-11-12
tags: added: charms
Changed in juju-core:
status: Triaged → Won't Fix
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers