cncf

🖥️ CNCF/k8s-ai-conformance A standardized approach to running #AI/#ML workloads on #Kubernetes cncf/k8s-ai-conformance

Another episode of: hyperscaler complains that volunteers don't gift (more) free labor to them lol toc#2338 (Or maybe it's just a single engineer complaining, but from the outside it looks quite bad)

@Aaronontheweb Something like this sandbox#523 ?

Tracking CNCF Projects: A Beginner's Guide to Contribution & Velocity Metrics The Cloud Native Computing Foundation (CNCF) hosts 100+ projects. Whether you're evaluating where to contribute, benchmarking your project's health, or just curious about the ecosystem, this guide shows you where to look and how to run the tools yourself. 1. DevStats — The Core Tool DevStats (github.com/cncf/devstats) is CNCF's primary tool for analyzing developer contributions. It pulls from GitHub's Archive (GHA), the GitHub API, and git itself to track commits, PRs, issues, and per-developer/per-company stats. > ⚠️ Key requirement: the project must be on a public GitHub repo. Running DevStats Locally (Quick Start) You need Go, PostgreSQL, and a GitHub OAuth token. # 1. Clone the repos mkdir -p ~/dev/go/src/github.com/cncf cd ~/dev/go/src/github.com/cncf git clone https://github.com/cncf/devstats.git git clone https://github.com/cncf/devstatscode.git # 2. Build the binaries cd devstatscode make sudo mkdir -p /etc/gha2db && sudo chmod 777 /etc/gha2db sudo -E make install # 3. Install scripts & config cd ../devstats make install Set up PostgreSQL: # macOS (Homebrew) brew install postgresql brew services start postgresql createdb gha createdb devstats # Create a user with privileges psql gha -c "CREATE USER gha_admin WITH PASSWORD 'your_password'; GRANT ALL PRIVILEGES ON DATABASE gha TO gha_admin; ALTER USER gha_admin CREATEDB;" psql devstats -c "CREATE USER gha_admin WITH PASSWORD 'your_password'; GRANT ALL PRIVILEGES ON DATABASE devstats TO gha_admin;" psql devstats < util_sql/devstats_log_table.sql Sync data: # Requires a GitHub OAuth token export GHA2DB_GITHUB_OAUTH="your_token_here" export PG_PASS="your_password" # Run all CNCF projects GHA2DB_PROJECTS_OVERRIDE="+cncf" devstats # Or target a single project (e.g. Kubernetes) ONLY=kubernetes PG_PASS=... ./devel/reinit.sh > 💡 Tip: schedule it hourly via crontab -e — GHA files are refreshed roughly every hour at :08. Running via Helm on Kubernetes For a full deployment (what CNCF runs in production): # Dry-run to validate helm install --dry-run --debug ./devstats-helm \ --set namespace='devstats-prod',skipSecrets=1,skipPVs=1,skipBackupsPV=1,skipVacuum=1,skipBackups=1,skipBootstrap=1,skipProvisions=1,skipCrons=1,skipAffiliations=1,skipGrafanas=1,skipServices=1,skipPostgres=1,skipIngress=1,skipStatic=1,skipAPI=1,skipNamespaces=1,runTests=1 # Full install helm install devstats-prod ./devstats-helm --set namespace='devstats-prod' You'll need secrets for Postgres credentials, a GitHub OAuth token, and Grafana admin access (see secrets/*.secret.example in the repo). Running Reports Once data is in the database: # List available reports ls sql/ # Contributors for a project in a time range PG_DB=kubernetes PG_PASS=... ./sh/run.sh contributors 2024-01-01 2025-01-01 # Per-company affiliation quality PG_DB=kubernetes PG_PASS=... ./sh/run.sh contributors_affiliations_quality_percent 2024-01-01 2025-01-01 "Google" company_name 2. Velocity — Growth Over Time cncf/velocity (github.com/cncf/velocity) generates the periodic CNCF Projects Velocity reports, charting commit and contributor growth over time. Data flows from BigQuery CSVs into charts. Great for answering "which projects are accelerating?" 3. LFX Insights — Per-Project Health Each project page on cncf.io displays an LFX Insights Health Score (e.g., "Fair (60)") across four dimensions: | Dimension | What it measures | |---|---| | Contributors | Bus factor, new vs. returning | | Development | PR/issue throughput, review time | | Popularity | Stars, forks, watchers trend | | Security | CVE response time, patch cadence | 4. The Landscape — Ecosystem Map The CNCF Cloud Native Landscape (landscape.cncf.io) categorizes every project by maturity and category, surfacing GitHub stars, contributor counts, and commit recency. Community-maintained on GitHub. 5. Maturity Levels — Why the Numbers Matter Projects progress: Sandbox → Incubating → Graduated (or Archived). Promotion requires: - Demonstrated adoption - Healthy rate of change (velocity!) - Committers from multiple organizations - CII Best Practices Badge Contribution metrics aren't vanity numbers — they literally gate a project's status. Quick Reference | Tool | Best For | URL | |---|---|---| | DevStats | Raw contribution & per-company metrics | devstats.cncf.io | | cncf/velocity | Growth/velocity over time | github.com/cncf/velocity | | LFX Insights | Per-project health score | cncf.io project pages | | CNCF Landscape | Ecosystem-wide map | landscape.cncf.io | Looking for projects to contribute to? Pair any of the above with CLOTributor, which aggregates "good first issues" across all CNCF projects in one place. --- Happy tracking! If you found this helpful, leave a ❤️ on dev.to.

CAPA Exam Guide: Argo CD Is Only a Third of It. I Scored 93 > I wrote the longer version, with more on each Argo project and my prep timeline, on my blog. Daily Argo CD use covers about a third of the CAPA exam. You blast through the CD questions, and then Argo Events shows up. I passed the Certified Argo Project Associate on the first attempt with 93 out of 100 (passing is 75). I don't run Rollouts or Events at work, so that score came from noticing early that I was preparing for the wrong exam. Format and weights 60 questions, 90 minutes, all multiple choice. No terminal. If you've done CKA or CKAD, muscle memory won't help here. Argo is four projects, each with its own object model, and you can't reason from one to another. The weights when I took it: | Domain | Weight | |---|---| | Argo Workflows | 36% | | Argo CD | 34% | | Argo Rollouts | 18% | | Argo Events | 12% | Workflows is the biggest domain and the one most people underprepare. Check the official CNCF curriculum before you plan, in case the weights have moved. Workflows (36%) Argo Workflows runs DAGs in pods. Know dag templates versus steps templates cold. In a DAG template you declare dependencies explicitly: task B waits on task A because you wrote dependencies: [build], not because it's listed second. Steps run top to bottom with no dependency graph. The exam gives you a manifest and asks which style it is. Parameters pass values between tasks, artifacts pass files. Run one real workflow and most of this domain comes for free. Argo CD (34%) The one people think they already know. prune: true deletes cluster resources that were removed from Git. selfHeal: true reverts manual changes made directly in the cluster. The exam asks about each separately, and if you've only ever turned on automated sync with both set to true, you've never had to think about which does what. Sync status and health status are separate axes. Synced vs OutOfSync says whether the cluster matches Git. Healthy, Progressing, Degraded or Missing says whether the thing works. An app can be Synced and Degraded at once, and that combination gets tested. Also recognize sync waves and hooks (PreSync, Sync, PostSync; the lowest wave applies first), ApplicationSet (one template plus generators makes many Applications), app-of-apps, and AppProject as the RBAC boundary. Know what each is for. You don't need to write them from memory. Rollouts (18%) Argo Rollouts replaces a Deployment when you need canary or blue/green. - Canary splits live traffic by percentage. Both versions serve users at the same time, and an AnalysisRun gates whether traffic keeps increasing. - Blue/green stands up a full second environment and swaps all traffic at once via activeService and previewService. Rollback is switching the Service back, because the old version is still running. The wrong answer usually blurs "both versions live" with "instant full cutover". Events (12%) Only 12%, but it's where I burned the most prep time, and most of us have never touched anything like it at work. In Argo Events, the EventSource listens to the outside world: a webhook, a file landing in S3, a Kafka message, a schedule. The Sensor subscribes to it and decides what to do. The Trigger is the action, like submitting a Workflow, creating a resource or calling an endpoint. Underneath, the EventBus (backed by NATS) carries events between EventSource and Sensor. EventSource listens, Sensor decides, Trigger acts. I said that chain out loud probably 20 times before it stuck, because under pressure the instinct is to assume the listener is also the decider. Even with the model down, Sensor dependencies and trigger conditions took me longest per question. How I prepared Two weeks: one of study, one of practice tests. For each project, before opening docs, I wrote down the problem it solves and its three main objects. That exposes the gaps that reading lets you nod past. I also deployed all four projects on one cluster. Not production grade, just enough to watch a workflow run and a rollout progress. What didn't work: going deep on Argo CD because I use it daily and skimming Events. About five days in I caught it and moved my time over. The easy points are the OpenGitOps principles, the Workflows template types (container, script, dag, steps), and knowing which Argo project solves which problem. Beyond the official docs, the Linux Foundation has LFS256, DevOps and Workflow Management with Argo, and everything I used for all 15 CNCF certs is in awesome-kubestronaut. Practice test I built a free CAPA practice test around the traps that cost the most points (EventSource/Sensor, selfHeal vs prune, canary vs blue/green, DAG vs steps). Take it a week out and you'll see which domain needs your last few evenings. Other CNCF exams are at yetmike.com. Two weeks was enough. I'm not sure I'd pass the Events section again without a refresher, though. Sensor conditions only stick if you run them, and I don't run Events outside a practice cluster. --- Originally published on yetmike.com.

CNCF declines to pay for a Verify Open Source Maintenance Fee Rationale from CNCF foundation#1547 An interesting wrinkle for the OSMF here, because the OSMF explicitly exempts projects that are also OSS. I've included a screenshot of the original reply. Doing new things, especially new types of licenses and agreements in open source, is hard.

Do you think this was a lack of communication or an explicit org policy @robmen @CloudNativeFdn? Seems misguided to me. foundation#1547