Add comprehensive Feature Gates analysis system for Kubernetes
Implement feature gates tracking system to support data-driven decisions about eliminating beta stage for new features, as discussed in sig-architecture.
Components added:
-
Feature gates SQL metric (metrics/kubernetes/feature_gates.sql)
- Tracks feature gates across alpha/beta/GA/deprecated states
- Associates features with SIGs and release milestones
- Uses regex patterns to extract feature gate information from issues/PRs
- Provides multi-dimensional aggregation for visualization
-
Metrics configuration (metrics/kubernetes/metrics.yaml)
- Multi-row single column series configuration
- All time periods supported (d,w,m,q,y)
- Annotations and aggregation enabled
-
Grafana dashboard (grafana/dashboards/kubernetes/feature-gates-by-sig-and-state.json)
- Feature gates by state over time visualization
- Interactive filtering by period and states
- Color-coded state progression (alpha=orange, beta=yellow, GA=green, deprecated=red)
- Template variables for flexible analysis
-
Comprehensive documentation (docs/FEATURE_GATES_ANALYSIS.md)
- System overview and usage patterns
- Decision support framework for sig-architecture
- Implementation details and optimization recommendations
-
Updated DASHBOARDS.md with feature gates dashboard entry
This system enables analysis of:
- Beta feature distribution and bottlenecks across SIGs
- Feature maturity progression patterns over time
- Release readiness assessment based on feature states
- Impact analysis for potential beta stage elimination
Supports: Kubernetes sig-architecture beta elimination discussion
Please make sure that you follow instructions from CONTRIBUTING
Specially:
- Check if all tests pass, see TESTING for deatils.
- Make sure you've added test coverage for new features/metrics.
- Make sure you have updated documentation.
- If you added a new metric, please make sure you have been following instructions about adding new metric.
This looks like a very nice feature - I would have to pull that branch and execute on the database to confirm it works correctly, then I need to import new dashboards on test and see how they look and how much time metric calculation takes for all projects, only then I can merge it (and backfill this data for all projects) - I can't do this ATM, will do on my next CNCF working. day after the more urgent migration task, so this is added to my backlog.
Understood. Thanks for outlining the steps — pulling the branch, validating the DB changes, testing dashboards, and checking performance all make sense. Just let me know when you start working on it; I’ll be available if you need any support or adjustments.