search

canonical / sdcore-nms-k8s-operator

A charmed operator for SD-Core NMS
https://charmhub.io/sdcore-nms-k8s
Apache License 2.0
2 stars 1 forks source link

Config files are not properly updated after relation broken event. #27

Closed patriciareinoso closed 4 months ago

patriciareinoso commented 9 months ago

Describe the bug

When the fiveg_gnb_identity between the GNB and the NMS is removed, the GNB config file inside the container is not updated. The relation broken event for this event is not observed for this relation and even if it was, there is a known juju issue in which the databag of a broken relation is not empty. ( https://github.com/canonical/operator/issues/888)

This https://github.com/canonical/sdcore-nms-operator/pull/24 was an attempt of a workaround to handle the issue in our charm. However, it is flawed. This situation can be properly handled once https://github.com/canonical/operator/issues/940 is addressed, which should allow us to easily identify the broken relations.

At the moment the charm is working at a best effort basis: once the relation is removed, the content inside the file will be updated over the next event that triggers the charm config method... I have seen the kubernetes patch event to be triggered from time to time, for example.

The same behavior happens with the fiveg_n4 relation between the NMS and the UPF.

To Reproduce

Deploy Charmed 5G including the NMS

Add the fiveg_gnb_identity relation between gnbsim and the NMS

Check that the NMS contains the /nms/config/gnb_config.json file or check on the GUI.

Remove the the fiveg_gnb_identity and relation

The /nms/config/gnb_config.json file still contains the gnb information or check on the GUI.

Expected behavior

Once the relation is removed, gnb_config.json should contain the up to day information.

Environment

markbeierl commented 4 months ago

This bug is still valid, but the configs get updated on juju status refresh event, so it eventually gets updated.