| 2016-06-29 05:06:13 |
Stuart Bishop |
description |
Using relation-set, a unit can retrieve relation settings from peer units.
For example, in the PostgreSQL charm standby units cannot create users or generate passwords to pass to the 'db' client relation. Instead, they need to iterate over their peers and copy the credentials from the master's 'db' client relation.
This works very well, normally. Unfortunately, we have discovered it fails when the client service is a subordinate. While pg/1 can retrieve the db:1 relation settings of pg/0 if db:1 is a relation to a standard service, relation-get fails if db:1 is a relation to a subordinate service.
Note that relations to services and subordinate services look identical from the pov of the charm, so you can't change behaviour depending on what type of service it is being related to.
This asymmetry breaks our telegraf subordinate when it is added to a multi-unit PostgreSQL service.
The workarounds seem to be:
- Document that relations to subordinates will not work
- Never retrieve relation settings from peer units. Instead, pass the relevant data for all relations as a big encoded json blob on the peer relation or in leadership settings (for PostgreSQL, this needs to be the peer relation) |
Using relation-get, a unit can retrieve relation settings from peer units.
For example, in the PostgreSQL charm standby units cannot create users or generate passwords to pass to the 'db' client relation. Instead, they need to iterate over their peers and copy the credentials from the master's 'db' client relation.
This works very well, normally. Unfortunately, we have discovered it fails when the client service is a subordinate. While pg/1 can retrieve the db:1 relation settings of pg/0 if db:1 is a relation to a standard service, relation-get fails if db:1 is a relation to a subordinate service.
Note that relations to services and subordinate services look identical from the pov of the charm, so you can't change behaviour depending on what type of service it is being related to.
This asymmetry breaks our telegraf subordinate when it is added to a multi-unit PostgreSQL service.
The workarounds seem to be:
- Document that relations to subordinates will not work
- Never retrieve relation settings from peer units. Instead, pass the relevant data for all relations as a big encoded json blob on the peer relation or in leadership settings (for PostgreSQL, this needs to be the peer relation) |
|
