
Benjamin Gandon
Perfect. Thanks Eric!
toggle quoted message
Show quoted text
Le 11 mars 2016 à 11:18, Eric Malm <emalm(a)pivotal.io> a écrit :
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.
Thanks, Eric, CF Runtime Diego PM
On Thu, Mar 10, 2016 at 4:42 AM, Benjamin Gandon <benjamin(a)gandon.org <mailto:benjamin(a)gandon.org>> wrote: 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 <https://github.com/cloudfoundry-incubator/diego-design-notes/blob/master/migrating-to-diego.md#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 ?
/Benjamin
Le 10 mars 2016 à 09:07, Amit Gupta <agupta(a)pivotal.io <mailto:agupta(a)pivotal.io>> 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)gandon.org <mailto:benjamin(a)gandon.org>> wrote: Hi cf-dev,
For a fresh new deployment of cf-release <https://github.com/cloudfoundry/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 <https://github.com/pivotal-cf/micropcf/blob/master/images/manifest.yml>. (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.
/Benjamin
|
|
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. Thanks, Eric, CF Runtime Diego PM On Thu, Mar 10, 2016 at 4:42 AM, Benjamin Gandon <benjamin(a)gandon.org> wrote: 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 <https://github.com/cloudfoundry-incubator/diego-design-notes/blob/master/migrating-to-diego.md#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 ?
/Benjamin
Le 10 mars 2016 à 09:07, Amit Gupta <agupta(a)pivotal.io> 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)gandon.org> wrote:
Hi cf-dev,
For a fresh new deployment of cf-release <https://github.com/cloudfoundry/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 <https://github.com/pivotal-cf/micropcf/blob/master/images/manifest.yml>. (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.
/Benjamin
|
|

Benjamin Gandon
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 ?
/Benjamin
toggle quoted message
Show quoted text
Le 10 mars 2016 à 09:07, Amit Gupta <agupta(a)pivotal.io> 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)gandon.org> wrote: 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.
/Benjamin
|
|
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)gandon.org> wrote: Hi cf-dev,
For a fresh new deployment of cf-release <https://github.com/cloudfoundry/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 <https://github.com/pivotal-cf/micropcf/blob/master/images/manifest.yml>. (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.
/Benjamin
|
|

Benjamin Gandon
Hi cf-dev, For a fresh new deployment of cf-release < https://github.com/cloudfoundry/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 < https://github.com/pivotal-cf/micropcf/blob/master/images/manifest.yml>. (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. /Benjamin
|
|