Skip to content

Support juju 4 in integration tests - #596

Open
Thanhphan1147 wants to merge 12 commits into
mainfrom
migrate-integration-tests-juju4
Open

Support juju 4 in integration tests#596
Thanhphan1147 wants to merge 12 commits into
mainfrom
migrate-integration-tests-juju4

Conversation

@Thanhphan1147

Copy link
Copy Markdown
Collaborator

What this PR does

Replaces all juju.ssh(unit, cmd) / cli("ssh", ...) calls that read files on units with juju.exec(cmd, unit=...).stdout.

Why

On Juju 4, juju ssh fails immediately after deploy with:

Permission denied (publickey)

This is due to changed SSH key provisioning/propagation timing in Juju 4. juju exec routes through the Juju agent and requires no SSH keypair, making it reliable regardless of timing.

Affected files

  • haproxy-operator/tests/integration/test_haproxy_route.py — read haproxy.cfg
  • haproxy-operator/tests/integration/test_haproxy_route_tcp.py — 4 reads of haproxy.cfg
  • tests/integration/test_haproxy_ddos.py — was lxd_juju.cli("ssh", ...), now lxd_juju.exec(...)
  • haproxy-operator/tests/integration/helper.py — apache2 access-log grep

Part of

Juju 4 integration test migration tracked in #577.

juju ssh fails on Juju 4 with 'Permission denied (publickey)' due to
changed SSH key provisioning timing. Replace all ssh calls that read
files on units with juju.exec(..., unit=...).stdout, which routes
through the Juju agent and requires no SSH keypair.

Affected tests: test_haproxy_route, test_haproxy_route_tcp (x4),
test_haproxy_ddos, and the apache2 log helper.
@Thanhphan1147
Thanhphan1147 requested a review from a team as a code owner July 2, 2026 13:18
@Thanhphan1147 Thanhphan1147 changed the title test: replace juju ssh with juju exec to fix Juju 4 SSH key auth failures Support juju 4 in integration tests Jul 2, 2026
Dependency charms (postgresql 16/edge, postgresql-k8s 14/edge, hydra,
kratos, traefik-k8s, identity-platform-login-ui-operator,
self-signed-certificates) declare 'assumes: juju < 4.0.0' (or < 3.5.0),
blocking deployment on Juju 4.

Juju 4's deploy validator skips assumes checks when --force is passed.
Add force=True to all external charm deploys in test fixtures so
the assumes gate is bypassed without changing the charm revisions.

Affected fixtures: postgresql_fixture, deploy_iam_bundle_fixture,
certificate_provider_application_fixture (both top-level and
haproxy-operator conftest).
…ility

Juju 4 injects additionalProperties: false into all action schemas at
charm load time (domain/deployment/charm/actions.go). Any param not
declared in actions.yaml is now rejected with a validation error.

The rpc action on any-charm only declares method, args, and kwargs.
The call at line 158 was passing protocols as a top-level param, which
Juju 3 silently accepted but Juju 4 rejects.

Move protocols into the kwargs JSON string so it is correctly
dispatched to start_ssl_server as a Python keyword argument.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Libraries: Out of sync no-release-note This PR does not require a change artifact

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant