Application Level Relation Data Questions

juju
1

Continuing the discussion from Juju 2.7.0: creating a new usability standard for infrastructure automation:

Wanted to make sure I have this right.

So if I understand correctly, normally, relations are with other units. So if I have a charm “WebApp” with 2 units and another charm “PostgreSQL” with 2 units and they are related to each-other you will have the relations:

  • webapp:db/1 <-> postresql:db/1
  • webapp:db/1 <-> postresql:db/2
  • webapp:db/2 <-> postresql:db/1
  • webapp:db/2 <-> postresql:db/2

So if I’m in the db-relation-changed hook on webapp/1 and I do a relation-get it will get the value from the specific postresql unit on which the relation changed. On the other hand if I do a relation-get --app it will get a value that is unspecific to the unit and general to the whole PostgreSQL charm that I am related to.

That means that, if I were the author of the PostgreSQL charm, and I wanted clients to the db relation to get the same values regardless of which unit they are connected to, I should be setting values using relation-set --app.

Furthermore, on the same relation, the values set with relation-set and the values set with relation-set --app don’t conflict with each-other and are completely separate.

On another note, if I wanted to create a charm key-value store that all of my charm units could share to coordinate with each-other, I could create a peer relation and then use relation-set --app and relation-get --app to make that key-value store available to any unit in the charm.

2

Hi @zicklag -
We generally talk about the relations being between the applications, but yes, that list is how the units would actually talk to each other.

Everything else you’re saying is right, I think.

One caveat is that only the leader unit for the application can run relation-set --app, so your kv-store will only be able to have one writer.

1 Like
3

OK, that’s important. Thanks for the clarification.

I’m trying to work out how I might be able to use the new feature in Lucky. I think it’s a great addition. :+1:

1 Like
4

Our thinking is that it makes sense for things like application-wide passwords, where the provider application will generate it once.

Until now that would be handled by having the leader provider unit generate the password for the related application and leader-set it. But since leader data isn’t relation-specific it needs to be manually namespaced so that it’s distinct from passwords for other related applications (eg, lots of different apps all related to postgresql). Then the units would need to leader-get it and send it to the units of the right requirer application. So it’s pretty fiddly.

The new way of just having the leader do relation-set --app and have the units of the related application be able to see it should be much simpler.

1 Like