Implementing redis interface for operator

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.

  • How would I approach that challenge?
  • Is there some code example I can look at?
  • Any advice on implementation strategy?
  • Has this already been implemented?

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!

1 Like

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.

1 Like

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.

1 Like

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.

1 Like