scale minikube resources based on system

[BradSwain]

Related #169

This changes the minikube deployment to use more resources, if available.

It also allows the deployment to run on systems with less than the previously hardcoded resources (8cpus, 32g mem).

It warns if resources are below some threshold, and errors if below a minimum threshold.

I took a best guess at what good values would be, but they can be changed/updated.

[ret2libc]

I'm unsure about this for now. The request resources depends heavily on the number of pods you want to spawn, so maybe on lower systems you also want to reduce the number of build-bot, etc and maybe reduce the resource constraints of some of those pods.

[BradSwain]

@claude use docker system info data and get the cpus/memory from there

[claude]

Claude finished @BradSwain's task —— View job

---

Task List

• Read and understand current resource detection implementation
• Research docker system info output format
• Modify script to use Docker system info for CPU/memory detection
• Test the changes locally if possible
• Commit and push changes to PR branch

Changes Made

✅ Replaced OS-specific resource detection with docker system info --format "{{.NCPU}},{{.MemTotal}}"
✅ Added Docker availability check with proper error handling
✅ Updated output message to clarify "Docker-available resources"
✅ Tested parsing logic - works correctly (CPUs: 2, Memory: 7944MB)

Summary

The script now uses docker system info to get Docker-available resources instead of system-wide resources. This ensures minikube gets accurate resource limits, especially important on macOS with Docker Desktop/Colima where Docker resources may be constrained compared to system resources.

Key improvements:

• Consistent cross-platform resource detection
• Uses actual Docker-available resources, not system-wide
• Added error handling for Docker not running
• Clearer output messaging

[ret2libc]

@claude address the review

[claude]

Claude finished @ret2libc's task —— View job

---

Task List

• Read current script to understand existing thresholds
• Update CPU minimum threshold to 5 (per review feedback)
• Update memory minimum threshold to 10GB (per review feedback)
• Test changes and run linting if available
• Commit and push changes

Changes Made

✅ Updated minimum CPU requirement from 2 to 5 cores (deployment/crs-architecture.sh:116)
✅ Updated minimum memory requirement from 16GB to 10GB (deployment/crs-architecture.sh:123)
✅ Fixed shellcheck warnings by adding proper variable quoting
✅ Validated script syntax with bash -n

Summary

Successfully addressed both review comments:

1. CPU threshold: Increased from 2 to 5 CPUs based on reviewer's observation that systems with one build-bot use more than 4 CPUs
2. Memory threshold: Reduced from 16GB to 10GB as reviewer noted that 9-10GB is sufficient for the k8s cluster specifically

The changes ensure that minikube deployments will only proceed on systems that meet the actual resource requirements for running Buttercup effectively.

Commit: 4cc838a - Address review feedback: update minimum resource thresholds
| Branch: brad/scale-minikube-deployment

[reytchison]

The README should document the minimum requirements

[reytchison]

This could also go in the #214 PR

[BradSwain]

Got pulled to some other work, but I plan to make the resources configurable during setup instead of during deployment.

I made env vars to configure minikube resources, pod count, and individual pod resource, and moved the "detect resources" logic to a script that runs during local setup

[BradSwain]

Closed in favor of listing the minimum required resources in #214