Comment 4 for bug 1848541

I disagree with having patch orchestration ignore the CPU alarms. If there happened to be a (bad) patch that caused run-away CPU usage in some configurations, we would want patch orchestration to stop after this condition was detected on the first set of hosts. Otherwise, patch orchestration would continue and hose the entire system.

The right thing to do here is to update the CPU alarm detection logic to be more tolerant.