Re: CF deployment with Diego support only ?

Eric Malm <emalm@...>

Hi, Benjamin,

Yes, in addition to setting the runner and hm9000 instance counts to 0 in
the CF manifest, those two CC properties should be all you need to change
to make your CF+Diego deployment Diego-only. CC Admins can still move apps
between backends, but no other users would be able to.

Eric, CF Runtime Diego PM

On Thu, Mar 10, 2016 at 4:42 AM, Benjamin Gandon <benjamin(a)>

That's right Amit, but it was just a typo by me. I meant setting
instances counts to zero for “runner_z*” and “hm9000_z*”.

I saw in a-detailed-transition-timeline
<> that
those two properties are also of help:
- cc.default_to_diego_backend=true
- cc.users_can_select_backend=false

So all in all, is that really all what needs to be done ?


Le 10 mars 2016 à 09:07, Amit Gupta <agupta(a)> a écrit :

You need the api jobs, those are the cloud controllers! Set the runner
and hm9000 jobs to 0 instances, or even remove them from your deployment
manifest altogether.

On Wed, Mar 9, 2016 at 11:39 PM, Benjamin Gandon <benjamin(a)>

Hi cf-dev,

For a fresh new deployment of cf-release
<>, I wonder how the default
manifests stubs and templates should be modified to remove unnecessary
support for DEA in favor of Diego ?

Indeed, I’m starting with a working deployment of cf+diego. And now I
want to wipe out those ancient DEA and HM9000 I don’t need.

I tried to draw inspiration from the MicroPCF main deployment manifest
(Are there any other sources for Diego-only CF deployments BTW?)
At the moment, all I see in this example is that I need to set «
instances: » counts to zero for both « api_z* » and « hm9000_z* » jobs.

Is this sufficient ? Should I perform some more adaptations ?
Thanks for your guidance.


Join to automatically receive all group messages.