vault-k8s:vault-pki/tls-certificates/vault-k8s:tls-certificates-access` test fails - Is the bundle configuration valid?

[motjuste]

Bug Description

Filed on behalf of @canonical/solutions-qa

In our Charm endpoint integration testing, we generated the bundle as described below based on the metadata for vault-k8s from Charmhub. But the bundle's deployment never completes because neighbor vault remains stuck Waiting for CA certificate to be accessible in the charm. This has been observed even with different channels and revisions of vault-k8s.

See one relevant run in Test Observer here. See more such runs here

Are we missing something in the bundle? Or, is the metadata for the charm in Charmhub somehow incomplete?

To Reproduce

juju deploy the following bundle:

applications:
  neighbor:
    base: ubuntu@22.04
    channel: 1.16/stable
    charm: vault-k8s
    options: {}
    revision: 502
    scale: 1
    trust: true
  self-signed-certificates:
    base: ubuntu@24.04
    channel: 1/stable
    charm: self-signed-certificates
    options: {}
    revision: 317
    scale: 1
    trust: true
  target:
    base: ubuntu@24.04
    channel: 1.18/stable
    charm: vault-k8s
    options:
      pki_ca_common_name: charmqa
    revision: 446
    scale: 1
    trust: true
bundle: kubernetes
relations:
- - neighbor:tls-certificates-access
  - target:vault-pki
- - self-signed-certificates:certificates
  - target:tls-certificates-pki

neigbhor charm will stay stuck in waiting status for at least 15 minutes.

Environment

Juju 3/stable and Canonical K8s

Relevant log output

2026-02-21T07:39:53.968Z WARNING juju-log vault-peers:0: Secret self-signed-vault-ca-certificate not found: 
2026-02-21T07:39:53.990Z WARNING juju-log vault-peers:0: No relations found for tls-certificates-pki
2026-02-21T07:39:54.043Z DEBUG juju-log vault-peers:0: Adding unit status WaitingStatus('Waiting for CA certificate to be accessible in the charm')

Additional context

The target does show that it successfully created CA certificate:

2026-02-21T07:40:57.817Z WARNING unit.target/0.juju-log Secret self-signed-vault-ca-certificate not found: 
2026-02-21T07:40:57.821Z INFO unit.target/0.juju-log Secret self-signed-vault-ca-certificate added to application

[canonical-vultaire]

Note: this comment was added with AI assistance (GitHub Copilot) based on automated log analysis and triage.

Filed by @canonical/solutions-qa

We found another occurrence of this same defect (unrelated relation/status message, same root cause) in a charm-integration-testing CMR test run:

• Test plan: integration/vault-k8s:vault-pki/tls-certificates/pgbouncer-k8s:certificates
• Test Observer run: https://test-observer.canonical.com/#/charms/409648?testExecutionId=668705&testResultId=12679533
• Logs index: https://charm.logs.test-observer.canonical.com/production/668705/index.html
• Log source: tarball juju-controller-charmqa-30764638904-10922202.tar.gz from that index, file charmqa-30764638904-92339134/debug-log.txt (unit vault-k8s/0, lines ~8324/8330)

The vault-k8s unit (target) never saw its own tls-certificates-pki relation to self-signed-certificates, so it never obtained a CA certificate — the exact same two log lines quoted in this issue's description:

unit-vault-k8s-0: 2026-08-02 20:16:30 WARNING unit.vault-k8s/0.juju-log tls-certificates-access:37: No relations found for tls-certificates-pki
unit-vault-k8s-0: 2026-08-02 20:16:30 ERROR unit.vault-k8s/0.juju-log tls-certificates-access:37: [vault_client] Error while checking Vault health status: HTTPSConnectionPool(host='vault-k8s-0.vault-k8s-endpoints...', port=8200): Max retries exceeded with url: /v1/sys/health (Caused by NewConnectionError(...: Failed to establish a new connection: [Errno 111] Connection refused))

("Secret self-signed-vault-ca-certificate not found" also appears immediately before, same as this issue's original report — see the same debug-log.txt, just before line 8324.)

This recurrence surfaced with a different terminal status message than the original report (Waiting for vault to be available instead of Waiting for CA certificate to be accessible), which is why it wasn't caught by the existing Test Observer attachment rule for this issue. We're attaching this result to this issue directly in Test Observer.