@jameinel possibly I can expand a bit more where I’m getting tripped up.
Take the example of relating two applications on a common interface where one application defines the
provides side and the other defines the
What are the concepts, components and processes involved in facilitating the exchange of information over the interface via constructs in the operator framework?
For example, is it to be assumed that the providing charm must first set data on
.joined so that the data is available for the requiring side of the relation to get on
Are there any conventions or constraints on how this can or can’t/should or shouldn’t be done?
Maybe this example can help explain what I’ve gathered this far, and what I’m missing.
Given two operator charms, provide information from one application to another application using a common interface.
Step 1 - Define relation endpoints
Each charm must define an interface in the
metadata.yaml for the side of the relation that it is responsible for; provides or requires.
Step 2 - Facilitate exchange of information from provider to requirer
Both charms need to implement code to facilitate either the sending or receiving of information via the respective provides and requires interfaces. This is accomplished by (where I get lost):
Both charms define a class that inherits from
Object in which the desired relation events are observed and mapped to the hander code.
Are there any constraints on how/where/when this can be done?
- Can both charms observe
.joined and communicate information over the relation event for
- What does the charm author need to be conscious of in respect to the lifecycle of the relation hooks when sending/receiving information via
The providing charm’s handler code executes when the desired relation hook event is observed. The data is set by the provider on the
event using its own application object as a parent key in
event.relation.data for it to store data in that it wants to send to the requiring charm on the other end of the relation.
The requiring charm accesses the data set by the providing charm via
event.relation when the event is observed and subsequently the handler mapped to the event execute. The handler code of the providing charm can access the event data for the unit or application you are making the relation to by using
event.app. This allows to index into
event.relation.data to get the data set by the unit or application on the other side (provides) of the relation.
Am I on the right track here? Is there anything you might add/take away?