[DPE-3705, DPE-3542] Reintroduce fallback keys and fix TLS secrets initialization

[shayancanonical]

Issue

1. We are not correctly initializing some TLS secret keys (e.g. cert instead of certificate, cauth instead of certificate-authority)
2. As part of PR 385, we got rid of the secret fallback keys. However, this is necessary for clients who are upgrading from old versions of the charm (without secrets) to this version of the charm (with secrets)

Solution

1. Correctly initialize the TLS secret keys
2. Re-introduce fallback keys in the framework of the new secrets lib (data_interfaces) (see Jira ticket for link to conversation for more context)

[codecov]

Codecov Report

Attention: Patch coverage is 60.86957% with 9 lines in your changes are missing coverage. Please review.

Project coverage is 66.25%. Comparing base (2bd2bcc) to head (9126174).
Report is 2 commits behind head on main.

Files	Patch %	Lines
lib/charms/mysql/v0/mysql.py	59.09%	5 Missing and 4 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #427      +/-   ##
==========================================
- Coverage   66.39%   66.25%   -0.14%     
==========================================
  Files          17       17              
  Lines        3169     3180      +11     
  Branches      419      424       +5     
==========================================
+ Hits         2104     2107       +3     
- Misses        930      935       +5     
- Partials      135      138       +3     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[paulomach]

It looks correct. Two things:

1. Did you've tests with some older charm revision?
2. The mandatory libpatch bump!

[shayancanonical]

Updated libpatch in 9cddb26

I tried testing upgrades from previous stable versions:

• Rev 151 fails upgrade as the charm does not have pre-upgrade-check action
• Rev 196 already stores the TLS keys in the appropriate secrets (with no chance to test fallback key)
• The revision for when upgrades feature was merged is no longer accessible in CI due to expired logs

[carlcsaposs-canonical]

• The revision for when upgrades feature was merged is no longer accessible in CI due to expired logs

it's available from releases page (e.g. https://github.com/canonical/mysql-operator/releases?q=292&expanded=true)
also available as git tag on that commit

[carlcsaposs-canonical]

question (not sure if this is in scope): when upgrading to this version of the charm, is it safe to rollback to previous version?

[carlcsaposs-canonical]

question: when would this be true on the new charm?

my naive thought is that the new charm would always use the new keys

[shayancanonical]

this would be true when an old charm (running on juju <= 3.1.4 when secrets were not introduced) would upgrade to the new charm. in this case, the value from the old fallback_key should be deleted, and new value should be stored in juju secrets with the new key

this functionality was present in the charm, but was accidentally removed with a refactor

[carlcsaposs-canonical]

does the new charm code ever call set_secret with key=old key name?

like, we're checking the key passed as an argument to see if it's a fallback key—we're not (I think) checking the key in the databag/secret

[shayancanonical]

i believe that the old (pre backups) code called set_secret with keys like (root_password) -> this is incompatible with juju secrets due to the underscore. in the this old code, set_secret set password in peer databag

the logic is as follows:

• if the old/fallback key exists in either the databag (or secret - but cannot exist in secret), then delete it
• update the new key in either the secret or the databag using data_interfaces