RFE: Add feature for listing relations together with charm options
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Canonical Juju |
Triaged
|
Wishlist
|
Unassigned |
Bug Description
This is a RFE (Request for Enhancement) for Juju.
Charm relations could be allowed to go along with a charm definition instead of all together in the end of the bundle. The bundle would be much better organized.
Like the "bindings:", "options:", "to:", there could be a "relations:" entry relating that charm to some other (it would also make it WAY easier to comment a charm out for testing for example).
Even the format definition could be simplified, since you don't need to specify the complete left side anymore (could be optional). Of course relations are two way, but generally one application wants something from the other so the charm that needs something would be defined later and the relation would go there.
So, for example, for openstack, you start with mysql, then keystone, then go on with other charms that always use the ones before (just for logic and readability, they could still be two way no matter where they are defined — you just pick one of them to define the relation on).
I guess this feature is not complicated to implement bug would make one's life much easier when making large changes to a juju bundle. Specially in the Field Engineering Team and Solutions Q&A Team where we have to play with lots of variations of bundles while testing stuff.
Changed in juju: | |
status: | New → Triaged |
importance: | Undecided → Wishlist |
tags: | added: bundles usability |
Examples:
Instead of:
applications: buffer- pool-size: 256M binlogs: True ce-schema: True connections: *mysql-connections password: openstack -origin: *openstack-origin -api-version: 3 provider: 'fernet' multiplier: *worker-multiplier shared- db", "mysql:shared-db" ]
mysql:
charm: cs:percona-cluster
bindings:
"": *oam-space
cluster: *internal-space
shared-db: *internal-space
ha: *internal-space
db: *internal-space
db-admin: *internal-space
options:
innodb-
enable-
performan
max-
tuning-level: *mysql-tuning-level
source: *openstack-origin
num_units: 1
to:
- lxd:0
keystone:
charm: cs:keystone
bindings:
"": *oam-space
public: *public-space
admin: *admin-space
internal: *internal-space
shared-db: *internal-space
options:
vip: *keystone-vip
admin-
openstack
preferred
region: *openstack-region
token-
worker-
num_units: 3
to:
- lxd:6
- lxd:7
- lxd:8
relations:
- [ "keystone:
You could use something like:
applications: buffer- pool-size: 256M binlogs: True ce-schema: True connections: *mysql-connections password: openstack -origin: *openstack-origin -api-version: 3 provider: 'fernet' multiplier: *worker-multiplier db/mysql: shared- db
mysql:
charm: cs:percona-cluster
bindings:
"": *oam-space
cluster: *internal-space
shared-db: *internal-space
ha: *internal-space
db: *internal-space
db-admin: *internal-space
options:
innodb-
enable-
performan
max-
tuning-level: *mysql-tuning-level
source: *openstack-origin
num_units: 1
to:
- lxd:0
keystone:
charm: cs:keystone
bindings:
"": *oam-space
public: *public-space
admin: *admin-space
internal: *internal-space
shared-db: *internal-space
options:
vip: *keystone-vip
admin-
openstack
preferred
region: *openstack-region
token-
worker-
num_units: 3
to:
- lxd:6
- lxd:7
- lxd:8
relations:
- shared-
This may seem like a small change but would greatly simplify copying parts of bundles around.