I'm hoping the release is not going to change at all.
On Apr 21, 2012, at 7:26 PM, Dr Nic Williams <drnicwilli...@gmail.com>
As you imagine composite jobs, would the release jobs stay the same and the
only thing change (from a BOSH user's perspective) be the deployment
manifest? Or can you imaging that jobs will need to be implemented
differently (monit, ctl scripts etc)?
Dr Nic Williams
Engine Yard, VP Developer Evangelism
cell +1 (415) 860-2185
On Saturday, April 21, 2012 at 6:58 PM, skaar wrote: Composite jobs (we even call it that) are on our short term road map for
exactly this reason - but the work required might take us a while to
On Sat, Apr 21, 2012 at 6:49 PM, Dr Nic Williams
$ gerrit clone ssh://reviews.cloudfoundry.org:29418/cf-release.git
$ cd cf-release
$ ls jobs | grep '\w' | wc
$ ls jobs/*/templates/*_ctl | wc
41 41 1840
There are 40 separate jobs, running 41 separate processes (approximately)
in VMWare's CloudFoundry release. For BOSH, this means minimum of 40 VMs.
On 40 AWS m1.smalls in Virginia or Oregon this is $3.20 per hour.
And then there is the Micro CloudFoundry concept (job/micro ?). So
CloudFoundry does scale down to 1 VM. BOSH doesn't allow for any notion of
this in a deployment manifest. If you want less than 40 VMs, then I guess
you need to create a whole new release project with composite jobs?
It seems that CF deserves to be able to scale up from 1 VM through
2,3,4,5,6 …. up to 40. Dang, you'd probably still have 2+ DEA VMs, and put
several of the controller/routing items on those VMs before you ever got up
to having each BOSH job running on a dedicated VM.
Is there a useful abstraction/join model to be considered where deployment
manifests specify which jobs (plural) run on each VM?
Dr Nic Williams - VP Developer Evangelism
[image: Engine Yard]
The Leading Platform as a Service
Office: 415 860 2185