-`pvc.yaml` — PVC `dynamo-pvc` for storing profiler results and configurations
-`pvc.yaml` — PVC `dynamo-pvc` for storing profiler results and configurations
-`pvc-access-pod.yaml` — short‑lived pod for copying profiler results from the PVC
-`pvc-access-pod.yaml` — short‑lived pod for copying profiler results from the PVC
-`kubernetes.py` — helper used by tooling to apply/read resources (e.g., access pod for PVC downloads)
-`kubernetes.py` — helper used by tooling to apply/read resources (e.g., access pod for PVC access)
-`inject_manifest.py` — utility for injecting deployment configurations into the PVC for profiling
-`download_pvc_results.py` — utility for downloading benchmark/profiling results from the PVC
-`dynamo_deployment.py` — utilities for working with DynamoGraphDeployment resources
-`dynamo_deployment.py` — utilities for working with DynamoGraphDeployment resources
-`requirements.txt` — Python dependencies for benchmarking utilities
-`requirements.txt` — Python dependencies for benchmarking utilities
...
@@ -70,37 +68,44 @@ After running the setup script, verify the resources by checking:
...
@@ -70,37 +68,44 @@ After running the setup script, verify the resources by checking:
kubectl get pvc dynamo-pvc -n$NAMESPACE
kubectl get pvc dynamo-pvc -n$NAMESPACE
```
```
### PVC Manipulation Scripts
### Working with the PVC
These scripts interact with the Persistent Volume Claim (PVC) that stores configuration files and benchmark/profiling results. They're essential for the Dynamo benchmarking and profiling workflows.
The Persistent Volume Claim (PVC) stores configuration files and benchmark/profiling results. Use `kubectl cp` to copy files to and from the PVC.
#### Why These Scripts Are Needed
#### Setting Up PVC Access
1.**For Pre-Deployment Profiling**: The profiling job needs access to your Dynamo deployment configurations (DGD manifests) to test different parallelization strategies
First, create a temporary access pod to interact with the PVC:
2.**For Retrieving Results**: Both benchmarking and profiling jobs write their results to the PVC, which you need to download for analysis
> **Note on Profiling Results**: When using DGDR (DynamoGraphDeploymentRequest) for SLA-driven profiling, profiling data is stored in `/data/` on the PVC. The planner component reads this data directly from the PVC, so downloading is **optional** - only needed if you want to inspect the profiling results locally (e.g., view performance plots, check configurations).
> **Note on Profiling Results**: When using DGDR (DynamoGraphDeploymentRequest) for SLA-driven profiling, profiling data is stored in `/data/` on the PVC. The planner component reads this data directly from the PVC, so downloading is **optional** - only needed if you want to inspect the profiling results locally (e.g., view performance plots, check configurations).
#### Path Requirements
#### Cleanup Access Pod
When finished, delete the access pod:
```bash
kubectl delete pod pvc-access-pod -n$NAMESPACE
```
**Important**: The PVC is mounted at `/data` in the access pod for security reasons. All destination paths must start with `/data/`.
-`/data/results/` - Benchmark results (for download after benchmarking jobs)
-`/data/results/` - Benchmark results (for download after benchmarking jobs)
-`/data/` - Profiling data (used directly by planner, typically not downloaded)
-`/data/` - Profiling data (used directly by planner, typically not downloaded)
-`/data/benchmarking/` - Benchmarking artifacts
-`/data/benchmarking/` - Benchmarking artifacts
**User-friendly error messages**: If you forget the `/data/` prefix, the script will show a helpful error message with the correct path and example commands.
#### Next Steps
#### Next Steps
For complete benchmarking and profiling workflows:
For complete benchmarking and profiling workflows: