pmady/keda-gpu-scaler

Evaluate the contributor onboarding experience: Finding the project Understanding how to contribute Setting up the development environment Finding a first issue Opening a first PR Getting feedback and merging Deliverable A contributor journey map with: Each step documented Pain points identified Recommendations for improvement Quick wins vs long-term improvements Acceptance Criteria Covers full contributor journey Identifies top 3 friction points Provides actionable recommendations Prioritizes improvements

We need a "fresh eyes" evaluation of the keda-gpu-scaler onboarding experience from a new user's perspective. This will help us identify friction points, missing documentation, and confusing workflows. Scope Evaluate the following user journey: Landing on the README for the first time Understanding what the project does and why it exists Following the Quick Start guide Reading CONTRIBUTING.md and finding a first issue Opening a first PR Deliverable A GitHub issue or document capturing: Where you got stuck or confused What information was missing What assumptions the docs made that weren't clear Suggestions for improvement Acceptance Criteria Document covers the full onboarding journey Includes specific examples of confusing sections Provides actionable recommendations

Summary The ADOPTERS.md file exists but is empty. For HPSF/CNCF submission, we need at least a few real-world adopter entries to demonstrate production usage. How to help If you are using keda-gpu-scaler in any environment (production, staging, development, research), please add yourself to ADOPTERS.md via a PR. Format | Organization | Use Case | Environment | |-------------|----------|-------------| | Example Corp | vLLM inference autoscaling on EKS | Production | Why this matters Foundation submissions (HPSF, CNCF) require evidence of real-world adoption beyond the maintainers. Even development/research usage counts. Difficulty: Beginner — markdown edit

Summary When GPU utilization fluctuates around the scaling threshold, the scaler can trigger rapid scale-up/scale-down cycles (flapping). Add a configurable cooldown period to prevent this. Requirements New metadata field cooldownSeconds (default: 60) After a scale-down decision, suppress further scale-down for the cooldown period Scale-up should not be affected by cooldown (always react immediately) Log when cooldown is active Implementation hints Track the last scale-down timestamp per ScaledObject in the ExternalScaler server In GetMetrics, if within cooldown window, return the previous metric value instead of the current one Add metadata parsing and validation in parseMetadata Acceptance criteria cooldownSeconds metadata field supported Scale-down suppressed during cooldown Scale-up unaffected Table-driven tests covering cooldown behavior README updated with new metadata field Difficulty: Intermediate-Advanced

Summary The keda-gpu-scaler gRPC server doesn't expose a health check endpoint. Kubernetes liveness and readiness probes currently rely on TCP socket checks, but a proper gRPC health check would be more reliable. Requirements Implement the gRPC Health Checking Protocol Register the health service on the existing gRPC server Report SERVING when NVML is initialized and responding Report NOT_SERVING if NVML calls fail Implementation hints Use google.golang.org/grpc/health and google.golang.org/grpc/health/grpc_health_v1 Add a periodic NVML health check (e.g. call Count() every 30s) Update the Helm chart to use grpc liveness/readiness probes instead of TCP Acceptance criteria gRPC health service registered Health status reflects NVML availability Helm chart updated with gRPC probes Unit test for health transitions Difficulty: Intermediate