[DPE-4416] URI exists while re-creating secret with modified label

[juditnovak]

Issue

Bug reported in Jira ticket https://warthogs.atlassian.net/browse/DPE-4416

The root cause was identified as an issue within the logic implemented for rolling upgades. In particular on an occasion where the (peer) secret label may change (as it happened in v34).

Since Juju is not supporting label changes, whenever we need to change a label for a secret, we need to create a new secret (using the previous content) and associate this new secret with the new label.

(The underlying logic is more complicated than it sounds, as we need to maintain backwards compatibility as well, until the first write operation.)

This logic had a bug, revealing on this particular use case:

• charm upgrade from libs < v34 to libs > v34
• peer secret changes
• peer secret changes for a second time, within the same event handler

At this point internal logic following the label switch was not maintained correctly. Namely the CachedSecret object was still associated with the label that --in reality-- we already have deteached from.

Solution

1. Cleaning up the corresponding internal field.

(Also, in a mid-term: refactor and cleanup of the data_interfaces module.)

2. data_interfaces had tests to verify that any new version is compatible with a charm using databag. However we were missing to have a test module that verifies rolling upgrades from previous versions.

A new test module was added, that simulating upgrades from an arbitraty version. This test is executed in 4 different pipelines, going back from the latest version of the lib down to latest - 4 simulating an upgrade from that version both for peer and cross-charm relations.

[juditnovak]

@taurus-forever to answer your question.

We have a new test module, that performs a simulated rolling upgrade on test charms.

The initial PR (to deliver a quick yet reliable solution) took a local copy of older versions of the lib, and "rotated" them to a static location for the the test module to pick up.

As I got the opportunity to clean up the "brute-force" approach, now the tests are dynamically fetching corresponding latest - N versions from git on each run of the corresponding, new pipelines.