| 2012-06-20 15:35:45 |
Mark Mims |
bug |
|
|
added bug |
| 2012-06-20 15:36:27 |
Mark Mims |
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 |
|
| 2012-06-20 16:19:09 |
Clint Byrum |
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 depoy nfs upload-client --with 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 depoy nfs --with mywiki (implicit juju-info relation added here)
juju add-relation mywiki uploadstore
the latter would be somewhat more expected by a user. |
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 --with 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 depoy nfs --with mywiki (implicit juju-info relation added here)
juju add-relation mywiki uploadstore
the latter would be somewhat more expected by a user. |
|
| 2012-06-20 16:26:43 |
Clint Byrum |
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 --with 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 depoy nfs --with mywiki (implicit juju-info relation added here)
juju add-relation mywiki uploadstore
the latter would be somewhat more expected by a user. |
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 depoy nfs --in mywiki (implicit juju-info relation added here)
juju add-relation mywiki uploadstore
the latter would be somewhat more expected by a user. |
|
| 2012-06-20 16:27:00 |
Clint Byrum |
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 depoy nfs --in mywiki (implicit juju-info relation added here)
juju add-relation mywiki uploadstore
the latter would be somewhat more expected by a user. |
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. |
|
| 2012-06-23 19:42:04 |
Kapil Thangavelu |
juju: importance |
Undecided |
Wishlist |
|
| 2013-02-26 12:34:25 |
Marius B. Kotsbak |
bug |
|
|
added subscriber Marius B. Kotsbak |
| 2013-10-12 03:37:55 |
Curtis Hovey |
juju: status |
New |
Triaged |
|
| 2014-03-04 11:27:52 |
Tom Haddon |
tags |
|
canonical-is |
|
| 2014-03-04 11:28:02 |
Tom Haddon |
bug |
|
|
added subscriber The Canonical Sysadmins |
| 2014-11-12 09:32:28 |
Tom Haddon |
bug task added |
|
juju-core |
|
| 2014-11-12 14:29:17 |
Aaron Bentley |
juju-core: status |
New |
Triaged |
|
| 2014-11-12 14:29:21 |
Aaron Bentley |
juju-core: importance |
Undecided |
Low |
|
| 2014-11-12 14:32:19 |
Curtis Hovey |
tags |
canonical-is |
canonical-is charms |
|
| 2014-11-17 00:41:32 |
Haw Loeung |
bug |
|
|
added subscriber Canonical WebOps |
| 2016-10-17 13:03:57 |
Anastasia |
juju-core: status |
Triaged |
Won't Fix |
|
