Mastodon codified in ArgoCD: maybe out of date but a good way to see a complicated system with lots of moving parts
Common Argo CD templates we use for self hosted cloud stuff. We're still working towards full stability, but feel free to take things or ask questions :) - open-engineering-nl/argocd-apps
The Art of #ArgoCD ApplicationSet Generators with #Kubernetes
https://piotrminkowski.com/2025/03/20/the-art-of-argo-cd-applicationset-generators-with-kubernetes/
Sometimes I have to use Kubernetes.
Everyone hates Kubernetes because you have to write so much YAML, and using Kubernetes is also very complicated.
The good news: You don't have to write YAML anymore. https://github.com/xchangeee/claudernetes/ will put Claude Code right where it belongs: An ArgoCD config management plugin.
Fed up with helm charts? Don't feel like writing YAMLs anymore? Just put a markdown file in your git repo and you're good to go!
#kubernetes #cloudnative #argocd #AI #SRE
Attached: 1 image
Too Long, Didn't Apply: Server-Side Apply for Oversized CRDs in Argo CD ApplicationSets
TemplatePatch is one of Argo CD's lesser-known features. It is also the cleanest way to enable server-side apply for exactly one generated Application - and to stop oversized CRDs from failing to sync.
https://christianhuth.de/too-long-didnt-apply-server-side-apply-for-oversized-crds-in-argo-cd-applicationsets/
#argocd,#kubernetes
A practical guide to AI data retention for business owners and ops leads: how consumer and business tiers differ on the same product, why disabling training does not stop retention, where embeddings, logs, and traces keep copies you forgot about, and what deletion means once a model has been fine-tuned.
Metric cardinality limits in OpenTelemetry: a practical guide
OpenTelemetry metrics are designed to be safe to use in production. One part of that safety is the cardinality limit in the metrics SDK. The limit protects your process from unbounded memory growth when a metric receives too many unique attribute combinations.
That protection is useful, but it has a consequence many users do not expect: when a metric stream overflows, the total value remains correct, while queries that filter or group by attributes can undercount. This can affect dashboards, service-level objectives (SLOs), and alerts that looked correct before overflow started.
What if #OpenSearch could natively ingest #OpenTelemetry data without a collector/agent?
I'm really happy to see this PoC by #SAP for 𝚘𝚙𝚎𝚗𝚜𝚎𝚊𝚛𝚌𝚑-𝚘𝚝𝚕𝚙-𝚛𝚎𝚌𝚎𝚒𝚟𝚎𝚛 plugin for a native OTLP endpoint to ingest into OpenSearch cluster
https://github.com/SAP/opensearch-otlp-receiver
@OpenSearchProject @opentelemetry
#OpenSearchAmbassador #observability #devops #ingestion #otlp #otel
Agents will make your telemetry explode. You are not ready. – shipping bytes
I have operated systems at scale long enough to know that the scariest failures are not the ones that blow up immediately. They are the ones that accumulate quietly, in the background, until the night you realize you cannot see what is happening anymore. Agents are going to do that to your observability stack. Vercel […]
Compare Pythons standard logging module structlog and Loguru with real benchmarks OpenTelemetry integration paths and frameworkspecific guidance for Django FastAPI and Flask
BetaFold3/tfstate-audit: Terraform state history indexer for audits: local SQLite + search/diff across S3, GCS, Azure Blob, and HCP Terraform (with secret redaction).
Terraform state history indexer for audits: local SQLite + search/diff across S3, GCS, Azure Blob, and HCP Terraform (with secret redaction). - BetaFold3/tfstate-audit
Dependabot security alerts have terrible signal-to-noise ratio, especially for Go vulnerabilities. That hurts security!
Just turn it off and set up a pair of scheduled GitHub Actions, one running govulncheck, and the other running CI against the latest version of your dependencies.
Less work, less risk, better results!
https://words.filippo.io/dependabot/?source=Mastodon
Attached: 4 images
PSA: Did you know that it’s **unsafe** to put code diffs into your commit messages?
Like https://github.com/i3/i3/pull/6564 for example
Such diffs will be applied by patch(1) (also git-am(1)) as part of the code change!
This is how a sleep(1) made it into i3 4.25-2 in Debian unstable.