Is this project alive ?

[primeroz]

Just want to make sure it is before i start to rely on it too much.

Thanks!

[K-Phoen]

@slok do you still maintain this project? (great work by the way 💙)

If not, have you considered adding collaborators to this repository?

[slok]

Hi there!

First of all sorry about not being able to handle this project, I have too many OSS projects and I try my best, I know this is no excuse :)

Some context: I'm no longer part of this company (@spotahome) since a long time ago (almost 2 years). Since that time, I have experimented with other approaches and better ways of handling SLOs and I changed my mind regarding some design decisions we made some time ago with this project:

• The operator doesn't create alerts.
• The operator centralizes the SLOS and calculates it internally.
• Only for Kubernetes.

In my previous company (@cabify), I changed the approach and took other decisions, that after some time, it demonstrated that worked better:

• Not coupled to Kubernetes.
• Use Prometheus rules to generate the metrics.
• Includes optional multiwindow-multiburn alerting.
• Gitops in mind (CI, validation, CLI options...).

Having this in mind. I took a final approach here and make a mix of these solutions in a new project (that I just released today 🎉) as OSS and that I maintain personally 🦥: https://github.com/slok/sloth

Basically, Sloth gives you more features regarding SLOs:

• Multiwindow-multiburn alerts.
• Gitops support.
• Simpler spec.
• Use Prometheus rules to create the metrics and alerts.
• Not coupled to Kubernetes (but also supports Kubernetes as CRD and translates to prometheus-operator CRDs).
• Better dashboard.
• Better SLO discoverability in prometheus.

One thing that I have to say regarding Sloth and the Kubernetes support is that the operator/controller mode is in the works (v0.2.0), the CRD is already there but at this moment only works as a CLI mode generator (Sloth CRD -> CLI -> prometheus operator CRD).

The migration between specs (service-level-operator -> sloth) should be simple enough (if you are interested, I could make a script to migrate the CRDs from one spec to the other automatically).

Having said this, I'll not maintain this project anymore because I prefer to focus on Sloth, also, I think people would benefit more by using Sloth than the service-level-operator, during this time I learned and gained more experience in this regard and I think that the design is better.

Regarding the maintainers thing, I can't respond to that, because I don't own this repository, but you can always create a fork, however, I would suggest at least taking a look at Sloth in case it covers your use cases)

Thanks for having an interest in this operator :)

[slok]

In case anyone is interested I'll leave this here: https://github.com/slok/service-level-operator-sloth-migrator

Is a script to migrate CRs from service-level-operator to sloth.