Hi, guys.

Suddently (after monthns of working fine), my CF instalation on aws started to fail. I'm getting this erros when trying to push an app: Staging error: no available stagers.

Googling, I found it: https://groups.google.com/a/cloudfoundry.org/forum/#!topic/vcap-dev/_vY8aQmTAi4

It seems that there is some kind of limit in DEA resource. It's not a physical limit, but a config that is limiting DEA to use all of the resources. Following this disucssion in google groups, I saw that we should change these parameters:

disk_mb
memory_mb
staging_disk_limit_mb
staging_memory_limit_mb

The only one that is shown in my manifest is memory_mb and it's quite huge: 30GB. The others I couldn't figured out where they are. It seems that they are encapsulated in a external template:

templates:
- {name: dea_next, release: cf}
- {name: dea_logging_agent, release: cf}
- {name: metron_agent, release: cf}

But i don't have a dea_next template. I don't know where to find it.

Can anyone help me?

Hi Flávio,

The limits on DEA resource are set via a config, however disk_mb and memory_mb should be set to closely track the hardware configuration of the instance you're using for your runner job. For example, if the vm has 32gb of Memory, a sensible setting for memory_mb would be 30000.

The staging limits should be set to sane defaults that limit the amount of resources an app may consuming during buildpack staging. The defaults for those should be fine for most installations. These settings are probably unrelated to your issue.

The "templates" property under the runner jobs is a red herring. These templates represent the bosh jobs that will be run on that VM and do not represent some external configuration that is being pulled in. The other properties (disk_mb etc) would be added to the manifest alongside memory_mb.

Given your memory_mb is closely matched to the resources available to the runner VM, it is entirely possible that you are actually using your entire allocated disk and memory on your runners. A simple way to determine if this is the case is to run `cf app` for each app, and compare the actual values with the allocated values. If can scale down the memory or disk usage for some apps, this may solve your problem.

The default value for disk_mb is 32000 so if the total allocated memory to all pushed apps is close to that value, new apps will not have enough disk to stage. If you are deploying to VMs that have significantly more disk space than 32gb you should redeploy the runners with a value for disk_mb that is closer to the available resources.

If you can scale down app usage you should find that new apps stage successfully. If this is not possible you will need to either increase the number of runners, or increase the resources available to the VMs at the IAAS level and update the manifest to reflect these new values. Both of these operations require a bosh redeploy.

Rob Dimsdale & Zak Auerbach
CF integration team,
Pivotal