Fail fast(er) on crm failures
Fail fast(er) on crm failures

Currently, we check the crm failure report during the testsetup phase to
make sure that nothing in the deployment caused any resources to hiccup.
This is great for telling us that something went wrong, but because our
logs from supportconfig are truncated, we often can't get enough
information to see what happened on the system at the time the failure
occurred. This patch adds the check during the proposal phase after each
proposal starting with the nova proposal is applied. This way, if an
error occurred during the application of a proposal (whether the error
was caused by the proposal or not) the automation run will terminate and
the supportconfig generated should have relatively recent logs to
examine. The reason this is only applied for proposals that come after
and including the nova proposal is that the oncontroller function uses
the nova proposal to determine which node is the controller. If
keystone, for example, causes a failure, we won't know until after the
nova proposal is applied, but we will still have a better chance of
getting relevant logs.

aspiers/automation,vmoravec/automation,SUSE-Cloud/automation,SUSE-Cloud/automation,gosipyan/automation,aspiers/automation,aspiers/automation,gosipyan/automation,gosipyan/automation,vmoravec/automation,SUSE-Cloud/automation,vmoravec/automation,SUSE-Cloud/automation,gosipyan/automation,vmoravec/automation,aspiers/automation