Refactor project structure to follow Go monorepo standards

[Ronkahn21]

Issue: Refactor project structure to follow Go monorepo standards

Motivation

Current multi-module structure (operator/, scheduler/, cli-plugin/ etc.) creates maintenance overhead and deviates from Kubernetes ecosystem norms. Experienced developers expect unified cmd/ layouts as seen in kubernetes/kubernetes, istio/istio, and cilium/cilium.

Current Problems

Multiple Go modules:

• Three separate go.mod files require coordinated versioning
• Cross-module imports create dependency complexity
• Code duplication across modules

Non-standard layout:

• Fragmented cmd/ directories instead of unified root-level structure
• Missing standard pkg/ and internal/ organization

Industry Standard

All major K8s projects use single-module, unified command structure:

# Kubernetes
cmd/kube-apiserver/ cmd/kube-controller-manager/ cmd/kube-scheduler/

# Istio  
cmd/pilot-discovery/ cmd/pilot-agent/ cmd/istioctl/

# Cilium
cmd/cilium-agent/ cmd/cilium-operator/ cmd/hubble-relay/

Proposed Structure

grove/
├── go.mod                    
├── cmd/                      
│   ├── grove-operator/       
│   ├── grove-scheduler/      
│   ├── grove-initc/          
│   └── kubectl-grove/        
├── pkg/                      
│   ├── apis/                 # API definitions by domain
│   │   ├── core/v1alpha1/   # Shared types, constants, and base structs
│   │   ├── operator/v1alpha1/# Operator-specific APIs and config
│   │   └── scheduler/v1alpha1/# Scheduler-specific APIs (PodGang)
├── internal/                 # Domain-specific private packages
│   ├── operator/             # Operator-only internal packages
│   │   ├── controller/
│   │   ├── webhook/
│   │   └── validation/
│   ├── scheduler/            # Scheduler-only internal packages
│   │   ├── plugins/
│   │   └── framework/ 
│   └── <domain-spefic-logic>/         # Resource management domain logic
└── charts/                   

Benefits

• Single dependency graph: Eliminates version coordination overhead
• Domain separation: Clear API boundaries between components
• Standard imports: Clean paths like github.com/NVIDIA/grove/pkg/apis/core/v1alpha1
• Unified tooling: Single build pipeline instead of three
• Functional domains: Logic organized by domain expertise rather than component
• Developer familiarity: Matches ecosystem expectations

Migration Plan

1. Create new structure alongside existing code
2. Separate APIs by domain into pkg/apis/{types,core,operator,scheduler}/
3. Extract binaries to unified cmd/ layout
4. Organize internal packages by functional domains
5. Update imports and remove old modules

References

• kubernetes/kubernetes, istio/istio, cilium/cilium project structures
• Go module layout docs
• golang-standards/project-layout

This aligns Grove with proven patterns from the Kubernetes ecosystem while maintaining clear functional boundaries and eliminating current development friction.