Closed nishant-dash closed 6 months ago
wanted to add that at this point landscape (that uses pgsql) is done with server errors.
unsetting the config options gets the postgresql charm into a "working" state again, but landscape is still down after this fiasco
after a while landscape seems to be ok
I'm unable to reproduce locally with latest 14/edge
(rev. 378) on Juju 2.9.46. Please recheck.
hi @dragomirp what about revision 351
?
Hi, @nishant-dash. No, I'm unable to replicate locally for either 351 or 363 (latest 14/stable
). What I'm deploying is the landscape-scalable bundle against a 3 unit deployment of the charm with the config options set (memory_shared_buffers=3128 memory_max_prepared_transactions=500
)
I think the error happens transiently, when the charm is checking for configurations against the database (request_time_zone
, instance_default_text_search_config
and request_time_zone
). If the charm cannot connect at the time to the DB. We should most probably not check if the values are the default (currently the charm checks for None, but the defaults would be set) and defer if the database is not available.
Latest 14/edge
(Rev. 380) should check configs against the database only on config change and defer if the database is not available.
Steps to reproduce
Heres the bundle I used (attached the yaml as a txt file): landscape-bundle.txt
Expected behavior
For things to work
Actual behavior
the charms seems to completely break down
units are stuck executing hooks like so longer trace: landscape-trace.txt
Versions
Operating system: DISTRIB_ID=Ubuntu DISTRIB_RELEASE=22.04 DISTRIB_CODENAME=jammy DISTRIB_DESCRIPTION="Ubuntu 22.04.3 LTS"
Juju CLI: 2.9.46
Juju agent: 2.9.46
Charm revision: 351
LXD:
Log output
Juju debug log:
Additional context