-
Notifications
You must be signed in to change notification settings - Fork 18
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-1781] Configuration support #239
Conversation
Codecov Report
@@ Coverage Diff @@
## main #239 +/- ##
==========================================
- Coverage 79.41% 78.92% -0.50%
==========================================
Files 10 10
Lines 1987 2149 +162
Branches 327 349 +22
==========================================
+ Hits 1578 1696 +118
- Misses 356 383 +27
- Partials 53 70 +17
|
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.
JFMI, why don't we set defaults in config.yaml?
No specific reason. I think it's a good idea to put them. I'll update the code. |
I added the default values and the feedback from the K8S charm PR to efc7c8f. |
* Add missing parameters and add configuration support * Use fixed snap * Fix parameters validation * Add validations * Update library * Revert changes on charm.py * Add configuration logic and tests * PR feedback (including the feedback from canonical/postgresql-k8s-operator#281) * Fix TLS tests * Increase timeout
Issue
There is no way to provide custom configurations to the workload (PostgreSQL database).
Solution
Add to
patroni.yaml
the requested configurations with their default values.Expose the allowed configurations through charm config options (and add validators based on the allowed values).
max_connections
andmax_prepared_transactions
can be changed only through the Patroni API, so they are changed in the charm code differently from the other configurations.Also, added a call to
time.sleep(10)
to give some time to Patroni to reload the configurations before it's possible to know which ones need a database restart. Previously, sometimes a change inshared_buffers
wouldn't trigger a restart.