I am about to try adding in redis support for the nextcloud charm that I am porting to the operator framework.
I’m in the deep water here, so reaching out for help and advice in this process.
Just a quick note: there’s active discussion going on about the best way to do this in the Operator framework here: Kubernetes Service Interface with Operator Framework
Interfaces and relations are designed to be lightweight and flexible. The advantage is that they can adapt to many situations. The disadvantage is that it can be hard to nail down best practices. We welcome your feedback here or in the discussion linked above!
I would love to discuss this with a few examples where possible with the clear intent of getting casual developers to be able to produce working charms with relations.
@jamesbeedy and @Dmitrii has provided some support in this context for me to take my first steps. But I am convinced that I am not doing it neither good, nor as a best practice.
ops-lib-pgsql for PostgreSQL is my best attempt at best practice. Redis could follow a similar pattern, but simpler (fewer events). The pattern works well for both simple charms that need to deal with a single relation, and complex charms needing to manage several. Rather than the charm attach an Endpoint object and call an API it provides, the charm attaches an Endpoint object and handles the events it raises, and the events provide the API. The usage example at that URL has been used pretty much verbatim with several charms.
We have implemented the redis functionality but didn’t yet put this into a package/module. How is the view from your end on libraries forming up on popular interfaces?
Is there any traction or is it scarse?
Where can we find them libs?
Hey @erik-lonroth, I’d be definitely interested. I have started not long ago with a redis charm for k8s. If you still have the code somewhere we could integrate it on this charm, at least give it a try to see how it looks. I encourage you publish the library and I can take a look to integrate it. Let me know.
I’m glad you are interested but we didn’t wrap our code into a lib but rather made the code integrate hard to our charm…
Maybe @joakimnyman got some thoughts here…
If your interface code is embedded into your charm, you might find that Creating and using charm libraries - charmcraft - Charmhub meets your needs for publishing the interface part to the charmhub in a way that others can consume. I haven’t used that mechanism though, as I find standard Python packages much easier to consume fitting in with existing dev and testing tools and workflows.
I’ve tried to use the k8 lib for redis and found an issue
Traceback (most recent call last):
File "./src/charm.py", line 78, in <module>
main(RedisVmCharm)
File "/var/lib/juju/agents/unit-redis-vm-0/charm/venv/ops/main.py", line 438, in main
_emit_charm_event(charm, dispatcher.event_name)
File "/var/lib/juju/agents/unit-redis-vm-0/charm/venv/ops/main.py", line 150, in _emit_charm_event
event_to_emit.emit(*args, **kwargs)
File "/var/lib/juju/agents/unit-redis-vm-0/charm/venv/ops/framework.py", line 355, in emit
framework._emit(event) # noqa
File "/var/lib/juju/agents/unit-redis-vm-0/charm/venv/ops/framework.py", line 856, in _emit
self._reemit(event_path)
File "/var/lib/juju/agents/unit-redis-vm-0/charm/venv/ops/framework.py", line 931, in _reemit
custom_handler(event)
File "/var/lib/juju/agents/unit-redis-vm-0/charm/lib/charms/redis_k8s/v0/redis.py", line 103, in _on_relation_changed
event.relation.data[self.model.unit]['hostname'] = self._get_master_ip()
File "/var/lib/juju/agents/unit-redis-vm-0/charm/lib/charms/redis_k8s/v0/redis.py", line 119, in _get_master_ip
return socket.gethostbyname(self._charm.current_master)
AttributeError: 'RedisVmCharm' object has no attribute 'current_master'
unit-redis-vm-0: 19:08:58 ERROR juju.worker.uniter.operation hook "redis-relation-changed" (via hook dispatching script: dispatch) failed: exit status 1
Where can I file a bug for the interface ? Deploy Redis using Charmhub - The Open Operator Collection
https://github.com/nextcloud-charmers/redis-vm/
Here is is. Its copied some code from redis-k8 and I think it should be fairly straight forward to copy most of the functionality.
Hi Erik! I took a look at your code, and I saw that you figured out the issue.
The Redis k8s charm deploys with an extra container for Sentinel to provide high availability. The current_master property on the charm is used to track the replication leader, and it’s updated on relation events (peer relations or charm relations) and other events.
If at the moment you plan on having a single instance of redis, using socket.gethostname() should work fine.
Not really. I would be more keen to have a 1:1 mapping to the redis-k8 charm so to be able to collaborate with perhaps the persons that develop that charm. The code you see at the moment is what I need to be able to replace the current redis charm for vm:s which currently is only supported on"trusty". This in turn blocks me from upgrading to juju 3.0. So, this was a blocker for many reasons. I would also rather try to get this code into a repo where more people could collaborate on this. It makes little sense to have this in the current nextcloud charm. But, at the moment - it was the only sensible option.