$ gerrit clone ssh://reviews.cloudfoundry.org:29418/cf-release.git $ cd cf-release $ ls jobs | grep '\w' | wc 40
$ 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?
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 complete.
/skaar
On Sat, Apr 21, 2012 at 6:49 PM, Dr Nic Williams <nwilli...@engineyard.com>wrote:
> $ gerrit clone ssh://reviews.cloudfoundry.org:29418/cf-release.git > $ cd cf-release > $ ls jobs | grep '\w' | wc > 40 > $ 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?
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)?
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 complete.
> /skaar
> On Sat, Apr 21, 2012 at 6:49 PM, Dr Nic Williams <nwilli...@engineyard.com (mailto:nwilli...@engineyard.com)> wrote: > > $ gerrit clone ssh://reviews.cloudfoundry.org:29418/cf-release.git (http://reviews.cloudfoundry.org:29418/cf-release.git) > > $ cd cf-release > > $ ls jobs | grep '\w' | wc > > 40
> > 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?
I'm hoping the release is not going to change at all.
-Vadim
On Apr 21, 2012, at 7:26 PM, Dr Nic Williams <drnicwilli...@gmail.com> wrote:
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)?
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 complete.
/skaar
On Sat, Apr 21, 2012 at 6:49 PM, Dr Nic Williams <nwilli...@engineyard.com>wrote:
$ gerrit clone ssh://reviews.cloudfoundry.org:29418/cf-release.git $ cd cf-release $ ls jobs | grep '\w' | wc 40 $ 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?
On Saturday, April 21, 2012 at 7:27 PM, Vadim Spivak wrote: > I'm hoping the release is not going to change at all.
> -Vadim
> On Apr 21, 2012, at 7:26 PM, Dr Nic Williams <drnicwilli...@gmail.com (mailto:drnicwilli...@gmail.com)> wrote:
> > 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)?
> > 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 complete.
> > > /skaar
> > > On Sat, Apr 21, 2012 at 6:49 PM, Dr Nic Williams <nwilli...@engineyard.com (mailto:nwilli...@engineyard.com)> wrote: > > > > $ gerrit clone ssh://reviews.cloudfoundry.org:29418/cf-release.git (http://reviews.cloudfoundry.org:29418/cf-release.git) > > > > $ cd cf-release > > > > $ ls jobs | grep '\w' | wc > > > > 40
> > > > 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?
