A customer may want to make changes (such as a new release) or perform operations (such as a restart or recreate) only on certain VMs. This article describes how to use "bosh ignore" and apply it to all the VMs you do NOT want to touch or change.
For example, to apply a release to a subset of VMs, i
ssue a "bosh ignore" command for all the VMs in the TAS deployment EXCEPT the router VMs:
for i in `bosh -d <tas-deployment> vms | awk '{print $1}' | egrep -v ^router `
do
bosh -d <tas-deployment> ignore $i
done
To deploy a specific release version, use the technique described in this KB article:
https://knowledge.broadcom.com/external/article?articleNumber=293785
Lastly, unignore the ignored VMs:
for i in `bosh -d <tas-deployment> vms | awk '{print $1}' | egrep -v ^router `
do
bosh -d <tas-deployment> unignore $i
done
This example targets the router VMs. To target others, you can modify the argument of the "egrep" command to exclude other VMs, such as cloud_controllers, from the ignore command. When all the VMs except the targeted class are ignored by bosh, the deploy will only change the release specified in the manifest for that targeted class.
This technique can be used to apply a "mask" of ignored VMs, so that you can make changes to a subset of VMs in a deployment. This change could be as simple as a restart, a stop, a start, a recreate, or an update defined in the manifest (as in the release example above).
This technique should be used with caution, since having VMs in different states with different release versions might have unanticipated results; for example, your deployment may end up in a partially-upgraded state. Moreover, unless you continue applying this "ignore" mask to your deployment, then the changes will be overwritten by subsequent Apply Changes or bosh deploys.