Emergency-management surge models need GPUs immediately during a flood event, while low-priority parks jobs still hold capacity. What should ops apply via the BCM-managed scheduler?
Select an answer to reveal the explanation.
Short Explanation
Flood surge models are the fire trucks—parks CV can yield the lane. BCM-managed preemption and priority let emergency jobs reclaim GPUs without waiting days or randomly killing containers. Wiping the parks image is a permanent punishment for a temporary surge.
Full Explanation
During a flood event, emergency-management surge models need GPUs immediately; low-priority parks jobs still holding capacity should yield through BCM-managed scheduler preemption and priority rules. That is the designed mechanism for reclaiming GPUs for higher-urgency municipal workloads without destroying long-term platform state. Permanently deleting the parks software image from BCM is a permanent punishment for a temporary surge and creates a rebuild crisis after the incident. Blocking emergency jobs until all parks jobs finish gracefully over several days is operationally unacceptable in a flood window—policy must prefer surge capacity for emergency management. Disabling the scheduler and manually killing random containers on every node abandons controlled preemption, risks killing the wrong work, and leaves the cluster harder to recover. Exam caveat: preemption should be policy-scoped (which queues/priorities) and preferably draining checkpoints where possible—not chaotic root kills across the civic estate. Operational check: raise emergency priority/preemption, confirm parks jobs are preempted or requeued, verify surge models obtain GPUs within the incident SLA, and restore normal priorities after the flood event closes.