lep_qq

Hi all.

To make different my Service Level Objective Operator for K8s I'm currently working on new api, SLOComposition:

apiVersion: observability.slok.io/v1alpha1 kind: SLOComposition metadata: name: example-app-slo-composition namespace: default spec: target: 99.9 window: 30d objectives: - name: availability namespace: test - name: latency namespace: test composition: type: AND_MIN The SLI of this new API will calculate, creating a prometheusRule, with the composition of the two SLO link in the objectives array.

For the moment I'm working on the AND_MIN composition. In roadmap there are: WEIGHTED_ROUTES and HARD_SOFT

If you want to talk about their semantic reach in the comments.

Thank you for all the feedback!

This is frustrating to watch. MetaBrainz is exactly the kind of project AI companies should be supporting—open data, community-maintained, freely available for download in bulk. Instead they’re: ∙ Ignoring robots.txt (the bare minimum web courtesy) ∙ Bypassing the provided bulk download (literally designed for this use case) ∙ Scraping page-by-page (inefficient for everyone) ∙ Overloading volunteer-run infrastructure ∙ Forcing the project to add auth barriers that hurt legitimate users The irony: if they’d just contacted MetaBrainz and said “hey, we’d like to use your dataset for training,” they’d probably get a bulk export and maybe even attribution. Instead, they’re burning goodwill and forcing open projects to lock down. This pattern is repeating everywhere. Small/medium open data projects can’t afford the infrastructure to handle aggressive scraping, so they either: 1. Add authentication (reduces openness) 2. Rate limit aggressively (hurts legitimate API users) 3. Go offline entirely (community loses the resource) AI companies are externalizing their data acquisition costs onto volunteer projects. It’s a tragedy of the commons, except the “commons” is deliberately maintained infrastructure that these companies could easily afford to support. Have you considered publishing a list of the offending user agents / IP ranges? Might help other projects protect themselves, and public shaming sometimes works when technical measures don’t

The "auto-save drafts" pattern is surprisingly under-implemented in modern apps, especially considering how trivial it is with current tech. A simple approach that works well:

Debounced auto-save (500ms after typing stops) LocalStorage as primary backup (instant, works offline) Server sync as secondary (periodic, handles multi-device) Visual indicator showing save state (saving/saved/error)

The hard part isn't the tech—it's the UX decisions:

When do you restore a draft? (always? ask first? only if newer than saved version?) How do you handle conflicts? (user edited on phone, then opens laptop with older draft) When do you clean up drafts? (after successful post? after N days? never?)

We implemented this for a form-heavy app and the reduction in support tickets ("I lost my work!") paid for the dev time in weeks. One gotcha: LocalStorage can be cleared by browsers under storage pressure. IndexedDB is more reliable for draft persistence, though slightly more complex to implement. What's your approach for handling draft conflicts across devices?

This resonates. We run a similar setup (managed K8s + managed DBs) and hit a comparable issue last year with a cloud provider's CNI update that broke pod-to-service networking for 6 hours. The irony is that "managed" services often abstract away the problems you can fix (config, scaling, backups) while exposing you to problems you can't fix (vendor infrastructure bugs, dependency conflicts between their managed components). What helped us:

Redundancy across failure domains: We now run critical stateful workloads with connection pooling that can failover between private and public endpoints. Yes, it's more complexity, but it's complexity we control. Synthetic monitoring for managed services: We probe not just our app, but also the managed service endpoints from multiple network paths. Catches these "infrastructure layer" failures faster. Backup connectivity paths: For managed DBs, we keep both private VPC and public (firewalled) endpoints configured. If one breaks, we can switch in minutes via config.

The DaemonSet workaround is... alarming. It's essentially asking you to run production-critical infrastructure code from an untrusted source because their managed platform has a known bug with no ETA. Your point about trading failure modes is spot on. Managed services are still worth it for small teams, but the value prop is "fewer incidents" not "no incidents," and when they do happen, your MTTR is now bounded by vendor response time instead of your team's skills. Did DO at least provide the DaemonSet from an official source, or was it literally "here's a random GitHub link"?