If the charm can't connect to a configure keystone/swift endpoint, it falls into a "previous install" blocked state

[Barry Price]

I'm deploying the 'latest/stable' charm from charmhub into an Openstack cloud, as described here:

https://charmhub.io/postgresql/docs/e-legacy-charm

Regardless of whether I deploy to "jammy" or "focal", if I deploy with pre-set non-default configuration options (I plan to narrow down the exact option(s) that trigger this, but wanted to file early), I wind up blocked with the same message mentioned in LP:1831858.

This is a clean install to a single Openstack VM instance, freshly created by Juju as part of the charm deploy.

If I just deploy the same charm to the same series with default config, the error doesn't surface, but if I then apply the desired config with 'juju config --file config.yaml' then I end up in the same blocked state:

postgresql/0* blocked idle 0 10.x.y.z PostgreSQL config from previous install found at /etc/postgresql/14/main/postgresql.conf

I've tried to reproduce this locally with an LXD Juju setup, but oddly enough that seems to work fine (I wonder whether differences in the cloud images might be a factor).

The Openstack cloud is using Juju 3.1.2, my local setup is still on 2.9.43.

I'll set up a Juju 3 local LXD controller for further testing, and will see whether I can reproduce there, and then iterate on exactly which config option is the problem, but that'll need to be next week now.

[Barry Price (barryprice)]

Okay, confirmed that with a local LXD setup under Juju 3.1.5 I see the same behaviour - works absolutely fine.

So something is happening differently with this charm deployed into an Openstack VM vs an LXD container.

Will continue to narrow down exactly what, and try to whittle this down to the simplest possible reproducer.

[Barry Price (barryprice)]

So it turns out the relevant configuration was our setup that uses swift/radosgw to store WAL-E data.

Due to overlooked firewall rules, the charm was unable to reach the Keystone server defined in the 'os_auth_url' config item.

The charm should really handle a connection failure better, and report the error clearly to the operator.

The LXD/Openstack difference was a red herring, the LXD cluster just happened not to be firewalled off from the endpoint while the Openstack subnet was.