Hi i have developed two charms server charm and application charm.I need to add relation between them and and want to get server IP address for application charm.I have added relation-joined and relation-changed hook files for both server charm and application charm.Then i can build relationships between them.Now i have problem my relation-joined and relation-changed hook files are not running.Only running config-changed,install and start hooks files.This is the way i followed.(How do I add a relationship between two charms to pass information between them? anyone tell me why these relation hooks are not running.and how the flow working for relation hooks. Thanks Sajith
The thing to keep in mind about juju relations is that we dont bind to any official spec. We're not forcing you to implement an RFC to exchange information between the services.
With that said, lets dissect your particular question here.
In terms of Server and Application, lets use gitlab-ci and gitlab-ci-runner as our server/application model. With gitlab-ci being the server, and gitlab-ci-runner as the application. our deployment model is a one to many, with 1 server, and many applications. (we can have many servers, but i want to keep the example concise)
We first define the relationship in the gitlab-ci metadata.
This single statement tells juju that we have a ci-job relation, using the ci-worker interface. With this relationship definition, we have 4 possible states that we can consume to make changes.
ci-job-joined, ci-job-changed, ci-job-broken, ci-job-departed
The convention for this, is relation-name-event - so moving forward, we have those 4 possible event hooks attached to a relation name. They execute in the following sequence:
Joined is for "pre-work" and is a place for you to do any work necessary to prep the service to receive the relationship (backing up an existing local SQLite database, for example).
Changed is executed any time a change is detected in the relationship. This sometimes gets triggered when the remote charm has a config update, and may not necessarily reflect a required change on your service - so be 100% sure its idempotent.
Broken is executed when you first break the relationship. This is when you would want to do any data-backups, and reconfiguration to remove the remote configuration.
Departed is any final wrap-up work for removing the relationship. Such as re-instating the SQLite backup for operation and writing the proper configuration.
The opposite end service is going to have a very similar story to the service listed above, but instead of provides, we will be using a requires statement to make the relationship. This is very much a Tab A, Slot B configuration - you define what can talk to what with these definitions.
And our hooks will look basically the same: ci-job-joined, ci-job-changed, ci-job-broken, ci-job-departed
The contents of the hook code are entirely up to you.
Sending the IP of the unit
There are conventions shipped with juju - depending on the language that you are using to write the charm. Be sure that you read the docs about relation-get, relation-set, and unit-get
I hope this helps!