Fix SANs list

[marceloneppel]

Issue

• Jira issue: DPE-844
• The k8s services that are created by the charm to redirect traffic to the primary and the replicas were not part of the certificate signing request sent to the TLS certificates operator.
• With that, in the first test run on a fresh microk8s installation the charm got stuck trying to call the Patroni REST API without success, as the hostname doesn’t match with the ones from the certificate. This was not happening in other test runs, but could happen in other situations. to the charm sending a certificate signing request (CSR) with it's IP address as a DNS name instead of an IP address.

Solution

• Update the code to add those services in the certificate signing request.

Context

• You can FOCUS on the following files when reviewing:

  • lib/charms/postgresql_k8s/v0/postgresql_tls.py: it contains the fix for the IP address issue in the VM charm and also a way to provide additional DNS names for the certificate signing request.

  • src/charm.py: it sends the k8s service names to the PostgreSQL TLS library.

• Other files and what has changed on them:

  • lib/charms/tls_certificates_interface/v1/tls_certificates.py: this is a patched version of the library that is used to solve the IP address issue. It was copied from https://github.com/canonical/opensearch-operator/blob/main/lib/charms/tls_certificates_interface/v1/tls_certificates.py (that patch will be pushed to the right repo in some weeks). Thanks @Mehdi-Bendriss!

  • tox.ini: the version of the Juju Python library was pinned due to ImportError: No supported version for facade: ModelConfigFacade errors when deploying the charm.

• In a future PR those k8s services probably should be replaced by the pods endpoints.

Testing

• It's very complicated to add a test to prevent this issue again in this repo because it happens (at least is what we could check) only with charm coming from Charmhub (we imagine that it's because they take some time to be downloaded to the model, so the events from it and the TLS certificates operator take a different order in the first deployment, but in the second and in the later deployment the charm is already there, so the order is different).
• The test that will check the issue is fixed is the one from https://github.com/canonical/postgresql-k8s-bundle/blob/6444a12423eacf45447debe82e2ab9c1f443c98a/tests/integration/bundle/test_tls_bundle.py (it fails every time on Giithub because every CI run uses a fresh microk8s installation).
• This fix was manually tested by publishing it in a different channel of Charmhub and using it to run the above test.

Release Notes

• Add the k8s services as DNS names on the certificate signing request.
• Update the PostgreSQL k8s library to handle this situation and also IP address issues in the VM charm.

[MiaAltieri]

LATM (looks amazing to me)

[marceloneppel]

Thanks for the reviews, @MiaAltieri, @WRFitch and @Mehdi-Bendriss!