Implementing redis interface for operator

#1

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?
#2

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
#3

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.

#4

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