Robin Shen [02/Oct/13 10:51 PM] For issue 1: why all configurations have to be re-written when you change licenses from 5 to 10?

Jonathan Oulds [03/Oct/13 09:48 AM] With the current system: 5 floating licenses: * One machine with 5 instance of the Coverity resource. > Step1: Master >> Step2: Checkout >> Step3: Sequential step that requires the Coverity resource (will only run on one machine) >>> Step4: Build step runs on any machine. 10 Fixed licenses: i.e. only specifc machines can run a Coverity build. * 10 machines have 1 instance of the Coverity resource. > Step1: Master >> Step2: Checkout >> Step3: Build step requires the Coverity resource. Becaue I change my Coverity license I have to modify my builds to remove the sequential step that acquires the Coverity resource. I also have to change the way resources are defined on my machines. Note that with the floating licences example if I want to copy files between machines I now need to perform an unnecessary copy to the machine owning the Coverity resource simply so that I can pass on the files to the actual machine that will perform the build. After resource pools are implemented: 5 floating licenses: * Define a resource pool that contains 5 instances of the Coverity resource. * Allow all machines to draw from the Coverity resource pool. > Step1: Master >> Step2: Checkout >> Step4: Build step runs on any machine that has the Coverity resource i.e. any of them as long as there are enough instances in the pool. 10 Fixed licenses: i.e. only specifc machines can run a Coverity build. I have a choice, I can restrict the number of machines that can access the pool and up the instances in the pool to 10 or I can define a Coverity resource on each of the 10 machines that will be allowed to perform the Coverity build, in either case the steps look like this, i.e. unchanged. > Step1: Master >> Step2: Checkout >> Step3: Build step requires the Coverity resource. Currently I have to define my steps to work around the type of resource I wish to define, as you can see by extending the resource concept to include pooled resource this is no longer necessary.

Jonathan Oulds [03/Oct/13 10:10 AM] As an extra: Imagine I have have 5 floating licenses for Coverity and 2 floating licenses for AdvancedInstaller. I want to run a Coverity build and produce an MSI in the same build. Currently I have two choices * One machine with 5 instance of the Coverity resource. * Another machine with 2 instances of the AdvancedInstaller resource. > Step1: Master >> Step2: Checkout >> Step3: Sequential step that requires the Coverity resource. >>> Step4: Sequential step that requires the AdvancedInstaller resource. >>>> Step5: Build step runs on any machine. As you can see lots of copying of files and a convuluted setup. or: * One machine with 5 instance of the Coverity resource and two instances of the AdvancedInstaller resource, effectively a license server. > Step1: Master >> Step2: Checkout >> Step3: Sequential step that requires the Coverity resource and AdvancedInstaller resource. >>> Step4: Build step runs on any machine. Now imagine that I buy 3 fixed licenses of AdvancedInstaller, 5 licenses in total. This setup CANNOT be represented with the current resource model. So instead I give up my 2 floating licenses and buy 5 fixed licenses of AdvancedInstaller, now I have to go through my builds and change the resource requirements of all my builds. With resource pools, I simply specify that my build step requires Coverity and AdvancedInstaller, and I am free to change the nature of my licenses at will, from fixed to floating to a mixture of both.