Unfortunate that it's AGPL. But this is looks really great!
There's nothing unfortunate about the AGPLv3. Everything that it doesn't let you do is stuff that you shouldn't be doing anyway.
Grafana releases OnCall open source project
21–30 of 134 posts
Re: Grafana releases OnCall open source project
#22[deleted]
Re: Grafana releases OnCall open source project
#23A bit disappointed by the architecture -- it's a Django stack with MySQL, Redis, RabbitMQ, and Celery -- for what is effectively AlertManager (a single golang binary) with a nicer web frontend + Grafana integration + etc.
I'm curious why/if this architecture was chosen. I get that it started as a standalone product (Amixr), but in the current state it is hard to rationalize deploying this next to Grafana in my current containerless setting.
Re: Grafana releases OnCall open source project
#24Looking forward to trying this out. I've always felt that PagerDuty was absurdly expensive for the feature set they were offering. It costs something at least $250 per user for organization larger than 5 person - even if you're not an engineer who is ever directly on call. At my previous company, IT had to regularly send surveys to employees to assess if they really needed to have a PagerDuty account. Alerts are a ke…
> I've always felt that PagerDuty was absurdly expensive for the feature set they were offering
For anyone out there in the same spot, I'll say that I switched my last company to Atlassian's OpsGenie and it was a 10x cost savings for the same feature set.
Re: Grafana releases OnCall open source project
#25Hello HN! Matvey Kukuy, ex-CEO of Amixr and a head of the OnCall project here. We've been working hard for a few months to make this OSS release happen. I believe it should make incident response features (on-call rotations, escalations, multi-channel notifications) and best practices more accessible to the wider audience of SRE and DevOps engineers. Hope someone will be able to finally sleep well at night being sure…
Being on-call has never made me sleep better at night!
Re: Grafana releases OnCall open source project
#26Hello HN! Matvey Kukuy, ex-CEO of Amixr and a head of the OnCall project here. We've been working hard for a few months to make this OSS release happen. I believe it should make incident response features (on-call rotations, escalations, multi-channel notifications) and best practices more accessible to the wider audience of SRE and DevOps engineers. Hope someone will be able to finally sleep well at night being sure…
The docs link [1] is 404. Seems like the /main is the culprit. [1] https://grafana.com/docs/oncall/main/ .
Re: Grafana releases OnCall open source project
#27Unfortunate that it's AGPL. But this is looks really great!
Re: Grafana releases OnCall open source project
#28I think it would be great if it was easier to mix and match Grafana SaaS and self-hosted products.
For example, we need to run Loki ourselves, for security / privacy reasons, but wouldn't mind using hosted versions of Tempo, Prometheus and OnCall.
Right now it isn't super-easy to link e.g. self-hosted loki search queries with SaaS-Prometheus.
Re: Grafana releases OnCall open source project
#29Earlier quoted context omitted.
Why is that unfortunate? Unless you're looking to make proprietary changes to Grafana Oncall and host it as a SAAS, it's the same as running any other GPL software.
GPL and its variants are a no go where I work.
To distribute I understand, but even just to use? Almost any desktop OS you run has GPL code somewhere in it
Re: Grafana releases OnCall open source project
#30Earlier quoted context omitted.
GPL and its variants are a no go where I work.
Is Linux verboten at work?
Probably not.
Linux usually gets a pass, because most times you're just deploying it and not mucking with source code.
But a lot of places (I've worked at more that do than don't) will have rules about GPL/AGPL for libraries/infra as a whole though. Often evaluated case-by-case, but it's rare I've seen a AGPL stuff get approved for usage.
I think some of it is not wanting to deal with the cost of vigilance; i.e. you can make sure that someone is using %thing% in a way that doesn't run afoul of AGPL right now, but does legal and upper management have confidence in that being true forever and always? Engineers are still human, and corporate management + legal teams tend to hate licensing folk tromping around.
This results in refusals ranging from "This is internal for now but we will open it up later" (a fair concern) to "Somebody is worried that exposing it over the VPN to contractors would count as making it public" (IDK, I'm not a lawyer.)