test(ldap): port the LDAP integration test from the K8s charm - #1936
Draft
marceloneppel wants to merge 11 commits into
Draft
test(ldap): port the LDAP integration test from the K8s charm#1936marceloneppel wants to merge 11 commits into
marceloneppel wants to merge 11 commits into
Conversation
github-actions
Bot
added
the
Libraries: Out of sync
marceloneppel
force-pushed
the
dpe-ldap-vm-charm-migration
branch
from
September 2, 2026 15:14
2da8af3 to
41ce8b3
Compare
marceloneppel
force-pushed
the
dpe-ldap-vm-integration-test
branch
2 times, most recently
from
September 2, 2026 15:25
08111e9 to
2cb3137
Compare
marceloneppel
force-pushed
the
dpe-ldap-vm-charm-migration
branch
3 times, most recently
from
September 2, 2026 17:41
65cb61c to
7a479e6
Compare
marceloneppel
force-pushed
the
dpe-ldap-vm-integration-test
branch
from
September 2, 2026 17:54
2cb3137 to
a84cb07
Compare
marceloneppel
force-pushed
the
dpe-ldap-vm-charm-migration
branch
from
September 2, 2026 18:20
7a479e6 to
afa933e
Compare
marceloneppel
force-pushed
the
dpe-ldap-vm-integration-test
branch
from
September 2, 2026 18:20
a84cb07 to
d1de587
Compare
marceloneppel
force-pushed
the
dpe-ldap-vm-charm-migration
branch
from
September 2, 2026 18:47
afa933e to
b0b6d64
Compare
marceloneppel
force-pushed
the
dpe-ldap-vm-integration-test
branch
from
September 2, 2026 18:48
d1de587 to
dfa36f7
Compare
marceloneppel
force-pushed
the
dpe-ldap-vm-charm-migration
branch
from
September 2, 2026 19:32
b0b6d64 to
718ac09
Compare
marceloneppel
force-pushed
the
dpe-ldap-vm-integration-test
branch
8 times, most recently
from
September 3, 2026 21:18
dd82e75 to
7169345
Compare
Ports the K8s charm's LDAP integration test to the VM charm, adapted for the cross-controller topology: the glauth-k8s stack (glauth, its PostgreSQL backend, self-signed-certificates, traefik) runs on a Canonical K8s controller prepared by concierge, and the LDAP and send-ca-cert endpoints are wired to the VM charm via cross-controller offer/consume relations. The test validates two things end to end: - the operator user can still access the instance after LDAP enablement (the hba 'ldap' line must not break local auth), and - a real LDAP user created through glauth-utils authenticates through the hba 'ldap' line once the ldap-sync sidecar materialises its role from the ldap-map group mapping. The dual-provider concierge config (LXD for the charm, Canonical K8s for the glauth stack) is inlined in the spread task's execute step so no other integration job pays for the K8s bootstrap. The test fails loudly when the concierge-k8s controller is unavailable instead of silently skipping, so a missing bootstrap is never mistaken for a pass. Signed-off-by: Marcelo Henrique Neppel <marcelo.neppel@canonical.com>
marceloneppel
force-pushed
the
dpe-ldap-vm-integration-test
branch
from
September 3, 2026 21:19
7169345 to
23a54da
Compare
The trailing escaped quote closes the psql -tAc argument opened earlier in the same command; removing it left an unbalanced shell quote that crashed every diagnostic exec with 'unexpected EOF' before the auth poll could run. Signed-off-by: Marcelo Henrique Neppel <marcelo.neppel@canonical.com>
GLAuth's bind compares the sha256 hexdigest of the presented password against the stored passsha256; the earlier base64 form never matched, so every LDAP bind failed with invalid credentials. Signed-off-by: Marcelo Henrique Neppel <marcelo.neppel@canonical.com>
The charm validates the ldap-map psql groups against pg_roles on config-changed and blocks without deferring when one is missing, so the role must exist before the mapping is set. Signed-off-by: Marcelo Henrique Neppel <marcelo.neppel@canonical.com>
The charmed-postgresql snap's psql wrapper is a Perl script that needs POSIX.pm, which is unavailable in the juju exec environment on arm64 runners, crashing the diagnostics with 'Can't locate POSIX.pm'. Use psycopg2 from the runner instead, matching how the operator validation query works. Signed-off-by: Marcelo Henrique Neppel <marcelo.neppel@canonical.com>
The retry loop passed four positional arguments to execute_query_on_unit, whose signature is (address, password, query, database): the LDAP username landed in the password slot, the password became the query, and 'SELECT 1;' became the database name — while the DSN still hardcoded user='operator'. Every attempt therefore authenticated as operator with the LDAP user's password and failed with 'password authentication failed for user "operator"'. Add a username parameter (default operator) to execute_query_on_unit and pass the LDAP user explicitly, and drop a duplicated log line. Signed-off-by: Marcelo Henrique Neppel <marcelo.neppel@canonical.com>
The juju snap reads /tmp and /var/tmp through a private namespace, so a transfer sourced from either directory cannot see the local file: the scp fails outright from /tmp and lands an empty file on the unit from /var/tmp. apply-ldif then succeeds vacuously on an empty LDIF, the sync has nothing to synchronise, and the auth poll never sees the role. Source the transfer from HOME, which the snap can read. Signed-off-by: Marcelo Henrique Neppel <marcelo.neppel@canonical.com>
get_unit_address and the journal diagnostic hardcoded postgresql/0, but re-runs on a reused model keep incrementing the unit counter after remove-application, so the app's first unit may be /1 or higher. Resolve the first unit of the application from the status instead. Signed-off-by: Marcelo Henrique Neppel <marcelo.neppel@canonical.com>
The charm creates the identity_access access group (NOLOGIN) but never grants it CONNECT on the postgres database, so every hba-matched LDAP bind fails with 'permission denied for database postgres'. Grant it in the test until the charm-side grant lands. Signed-off-by: Marcelo Henrique Neppel <marcelo.neppel@canonical.com>
Signed-off-by: Marcelo Henrique Neppel <marcelo.neppel@canonical.com>
The CONNECT-grant commit accidentally repeated the CREATE ROLE statement from the block above it, so every run fails with DuplicateObject: role "superheros" already exists. Keep only the GRANT CONNECT statement there. Signed-off-by: Marcelo Henrique Neppel <marcelo.neppel@canonical.com>
2 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Issue
Follows the LDAP module migration into the single kernel library (postgresql-single-kernel-library #235, #236). Stacks on #1935.
Solution
Ports the K8s charm's
test_ldap.pyto the VM charm: deploys the glauth-k8s stack (glauth as the LDAP server with ldaps enabled, a PostgreSQL K8s charm as its auth backend,self-signed-certificates, andtraefik-k8sexposing the ldaps ingress) and validates that theoperatoruser can still runSELECT VERSION()once theldapandsend-ca-certrelations are in place.The test then exercises the full LDAP user flow: the
ldap-mapconfig maps the LDAP group to a PostgreSQL group (the mapped role is created first, beforeldap-mapis set), the LDAP user and group are created in glauth through theglauth-utilscharm'sapply-ldifaction, and the test polls for the ldap-sync sidecar to materialise the user's role before authenticating as that LDAP user through the hbaldapline. Two pending charm-side gaps are worked around in the test until the charm covers them: theidentity_accessgroup does not yet have CONNECT on thepostgresdatabase (granted here so the auth poll can complete), and the juju snap cannot read/tmpor/var/tmp, so the LDIF is sourced from$HOMEunder a unique name before thescp.Because glauth-k8s is a Kubernetes charm and this charm runs on machines, the stack runs on a separate Kubernetes Juju controller and the relations are wired as cross-controller offer/consume pairs, following the VM LDAP how-to. The test is written with jubilant directly (matching the current integration test style) and fails when the Kubernetes controller is unavailable. A spread task wraps it like the other integration tests, and the task's execute step bootstraps the Kubernetes controller through a task-scoped concierge config so no other integration job pays for it.
The only shared-code change is in the test helpers:
execute_query_on_unitgains ausernameparameter (defaulting tooperator) so the auth poll can connect as the LDAP user. No charm code changes.Checklist