This charm is set up to make use of an external Redis server, as well as a Cross-model Relation to a PostgreSQL database. File uploads are currently stored in S3 to avoid the need for local storage. It is made to run with one or more pods for scale out usage and handles version updates and database schema updates automatically, upon being deployed with an updated image.
This charm has unit tests that verify functionality and I have also deployed it both with microk8s and in a production k8s environment running on top of OpenStack.
We would be interested in any feedback on the code or the charm itself. Please feel free to file bugs against the project on Launchpad at Bugs : charm-k8s-discourse with any issues that you find, or if you’ve got questions about the charm just let me know.
We don’t have any plans to write an IaaS version currently. In fact, one of the specific reasons Jay wrote this as a k8s charm is that there isn’t a good IaaS version of a discourse charm, and discourse itself seems much better suited to running in a containerised environment (that’s how upstream chooses to run it). You could certainly take some of the code from here and adapt it to an operator framework IaaS discourse charm, but there’d be quite a lot of changes needed to adapt it from this version to move the image creation steps into an IaaS setting.
A PostgreSQL for k8s Charm is working and testable now, with code on Launchpad. It should have its own thread up here today or Monday for wider feedback.
Looks like it does offer the pgsql interface which is super. Have tried it on MicroK8s with both discourse and mattermost, but it’s clearly not quite ready for prime time will try again Monday!
I’m trying it out on my end here with my nextcloud charm and I get this…
2020-11-01 18:22:44 ERROR juju-log db:3: Uncaught exception while in charm code:
Traceback (most recent call last):
File "./src/charm.py", line 375, in <module>
File "/var/lib/juju/agents/unit-nextcloud-7/charm/venv/ops/main.py", line 399, in main
framework.reemit()
File "/var/lib/juju/agents/unit-nextcloud-7/charm/venv/ops/framework.py", line 688, in reemit
self._reemit()
File "/var/lib/juju/agents/unit-nextcloud-7/charm/venv/ops/framework.py", line 723, in _reemit
custom_handler(event)
File "./src/charm.py", line 95, in _on_install
File "./src/charm.py", line 331, in _init_nextcloud
AttributeError: __enter__
2020-11-01 18:22:44 ERROR juju.worker.uniter.operation runhook.go:136 hook "db-relation-changed" (via hook dispatching script: dispatch) failed: exit status 1
[Update: #1] I found my error, which was not related at all to the interface… Making progress porting my nextcloud charm to operator… I’ll probably give it a go with k8 down the road.
Yes, the postgresql-k8s charm is a drop-in replacement, talking the same relation protocols. PostgreSQL k8s Charm has the details. A few relation setup race conditions have been squashed, which I could only reproduce with k8s client applications (egress-subnets and remote unit name not available during initial relation setup).
@stub not having much luck with mattermost (cs:~mattermost-charmers/mattermost) and the current revision of your postgresql-k8s charm on Juju 2.9rc2. Could you take that combo for a spin on MicroK8s 1.19.2?
Looks like Juju 2.9 has changed how DNS resolution is working in the pods, and the pod setup is hanging because the k8s service names no longer resolve. Fix is looking like requiring Juju 2.9 (the new feature that I suspect broke things looks like it makes the failing code unnecessary, if I make use of it). I’ll follow up in the PostgreSQL k8s Charm topic to avoid derailing this one further.
will try again Monday!