Non-federated kube support

[JeremyLARDENOIS]

Hello, first, thank you a lot for this project! I used it for my apps and it works very well.

However, I feel like I use it in a strange way... Because I'm using it on a non-federated kube, I forked the repository and made some changes to make it works. The problem is that each time that I want to get the latest release of redis-operator, it's very difficult because there are lots of changes (and that's normal).

I want to change the way that I use the operator by using it as a lib. This is in order to keep my logical needs outside. But I feel like the code isn't intended for this usage. I'd like to know if you're open to this type of usage and your general thoughts about it. I would be happy to suggest some PRs, with no breaking changed and just add interfaces. IMO, it will be a good first step for this kind of usage.

Do you have any other thoughts about it?

Thanks!

Jeremy

[JeremyLARDENOIS]

Bump 😄

My question is, in order to have a non-federated kubernetes support, do you prefer to have more interfaces in order to people be able to integrate their logic into redis-operator or do you prefer to have the full support of non-federated kubernetes ?

Thanks for considering my request !

[drivebyer]

I’m a bit curious, what exactly is ‘non-federated Kubernetes’? I haven’t learned about it before.

[JeremyLARDENOIS]

Hello, in a short way, it's several cluster kubernetes different and with no federation between. It refers directly to kubernetes federation. Federation is a better option when you have redondancy and different zone to handle but it requires more maintenance. My use case is so on non-federated kubernetes (several differents kubernetes) where I need to have redis interconnection between them. That's because I'm not admin on these clusters