Discourse charm for k8s

charm
#1

Hello!

I have been working on a k8s charm for the Discourse discussion forum, and I have a version that is ready for review.

I’ve prepared a merge proposal that shows changes to src/charm.py and unit tests, which is available at Merge into master : charmcraft-review2 : lp:~jk0ne/charm-k8s-discourse/+git/charm-k8s-discourse : Git : Code : charm-k8s-discourse - any feedback on this would be very much appreciated.

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.

The charm is published to the charmstore at discourse | Juju.

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.

Thanks in advance for your time and attention!

Jay Kuri

5 Likes
A discourse bundle, anyone?
#2

This is awesome. Any chance for a IaaS version? :wink:

#3

Hi Erik,

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.

Thanks, Tom

2 Likes
#4

Got it. Thanks anyway.

#5

Now I really wish we had redis and postgres on K8s too, because it’s so fast to bootstrap and deploy on MicroK8s!

1 Like
#6

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.

1 Like
#7

Nice! is it compatible with the current pg interface? Is it a drop-in replacement?

#8

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 :slight_smile: will try again Monday!

#9

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

I’m not sure what goes on here, but here is my code going wrong: https://github.com/erik78se/nextcloud-charms/blob/master/charm-nextcloud/src/charm.py#L310

[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.

#10

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).

#11

@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?

#12

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.