-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[DPE-3184] Secrets #178
[DPE-3184] Secrets #178
Conversation
34422ce
to
e6250e3
Compare
src/charm.py
Outdated
"monitoring-password", | ||
"operator-password", | ||
"replication-password", | ||
"rewind-password", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this operator have all these passwords?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not really. Will check tomorrow what needs to be kept and what doesn't.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pgbouncer needs arbitrary secret names, which are currently not supported by the lib. The PR will have to wait until there is a way to do this or when we know we need to change this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
List should be up to date now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Please clean unnecessary secret requests as reported by Marcelo.
Nice work!
b5a3f3e
to
3f11a4a
Compare
* Remove username secret * Only the leader blocks * Bump libs * Borked test * Unit tests
if not (password := self.charm.get_secret(APP_SCOPE, user)): | ||
password = pgb.generate_password() | ||
self.charm.peers.add_user(user, password) | ||
else: | ||
password = self.charm.get_secret(APP_SCOPE, user) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@delgod suggested removing the arbitrary secrets. The charm seems to function mostly the same (see this comment).
await ops_test.model.wait_for_idle(apps=[PGB], status="blocked", timeout=1000) | ||
assert ( | ||
ops_test.model.applications[PGB].units[0].workload_status_message | ||
== EXTENSIONS_BLOCKING_MESSAGE | ||
leader_unit = await get_leader_unit(ops_test, PGB) | ||
await ops_test.model.block_until( | ||
lambda: leader_unit.workload_status_message == EXTENSIONS_BLOCKING_MESSAGE, timeout=1000 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the main divergence I found from the previous behaviour. Since only the leader evaluates the the legacy _on_relation_joined()
now, only the leader will block.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tnx!
Issue
PGB peer secrets implementation lagged behind the common implementation in other charms.
Solution
Updated the shared secrets to be in line with the Postgresql VM charm.