Customer is using in v. 15.0 to deploy stateless workers as part of master/worker pattern:
gs.sh pu deploy --instances=$NUM_WORKER_INSTANCES <pu name> <pu jar>
When NUM_WORKER_INSTANCES set to 0, the deploy fails.
In previous version of gs.sh, v. 12.2:
gs.sh deploy -cluster total_members=$NUM_WORKER_INSTANCES -max-instances-per-vm 1 <pu.jar>
This will allow them to set number of instances to 0.
This is important to them because they are using the master worker pattern and they are doing batch processing. The workers are started on demand. When they need to begin process they increment the number of workers. Master is already deployed and on standby.
They are using virtual machines (VMWare) and the resources are shared w/ other processing.
Workarounds:
gs.sh --cli-version=1 to get old deployment behavior
Use the Admin API and write a wrapper script that calls Admin api. The admin API does not have the same limitation.
Re-write their scripts so instead of calling increment, have logic to see if the PU is deployed first. If not deploy, due a deployment. If already deployed ignore or do an increment.
Customer feels that it would be simpler if we could revert to old behavior rather than relying on above workarounds.
allows the new gs.sh cli tool to support the deployment of 0 instances