Change Details

While working on T360993 I depooled, stopped blazegraph and disabled puppet on a wdqs node. This machine (wdqs1013) was meant to stay offline while we address the problem. As part of scap deploy the next day it appears that the wdqs machine was repooling. It is possible that scap is * depooling * restart the service * repool no matter what was the pool status is at the beginning of the process. AC: - deploying wdqs via scap should not automatically repool a machine that was depooled prior to the deploy

While working on T360993 I depooled, stopped blazegraph and disabled puppet on a wdqs node. This machine (wdqs1013) was meant to stay offline while we address the problem. As part of scap deploy the next day it appears that the wdqs machine was repooled. It is possible that scap is * depooling * restart the service * repool no matter what is the pool status at the beginning of the process. AC: - deploying wdqs via scap should not automatically repool a machine that was depooled prior to the deploy

While working on T360993 I depooled, stopped blazegraph and disabled puppet on a wdqs node. This machine (wdqs1013) was meant to stay offline while we address the problem. As part of scap deploy the next day it appears that the wdqs machine was repoolinged. It is possible that scap is * depooling * restart the service * repool no matter what wais the pool status iss at the beginning of the process. AC: - deploying wdqs via scap should not automatically repool a machine that was depooled prior to the deploy