Ah, I was mistaken. If you set MEMORY_LIMIT, it will not get overwritten. So if you don't set it, it will be set to the container memory limit. But if you do set it, then the java buildpack can take

The MEMORY_LIMIT is used by the java buildpack to configure the various heap parameters for a java app. This variable value is set to the container size by default by the Cloud controller when you

Thanks for the response. But what I am observing is, by setting MEMORY_LIMIT as an environment variable does take effect when I restage the app and it reduces the memory allocated to the java app(not

This is not a environment variable you can set. To scale down the memory allocated to your instances, do cf scale <app-name> -m 1024M This will tell Warden/Garden to allocate that much memory to

Memory limits are set via cf scale. `cf scale <app-name> -m 512M` will scale your app to 512MB per instance. The cli will then tell you to restage your application so the buildpacks can observe the

We are not using Diego and we are on CF version 211. I had my application started with 2GB of memory set in the manifest file. I then ran the following command and restaged the app: cf set-env

The current way of sending metrics as either Values or Counters through the pipeline makes the development of a downstream consumer (=nozzle) pretty easy. If you look at the datadog nozzle[0], it just

Hi Daniel! What I've done while testing is to set the variable BOSH_AWS_REGION to the region I needed. export BOSH_AWS_REGION=<your region here> Regards!! Joaquin

Thanks for the help I had some permission issues on several files. Since diego run docker containers with user vcap. I created a user named as vcap and gave the file permission to vcap in advanced.

Thanks James, I've just corrected the three issues you've noted so far

The error message suggests that in `/etc/passwd` in the Docker image, the entry for `vcap` lists a path for the home dir that doesn't exist. I'm afraid I don't understand Diego well enough to know why

the example used for actions uses the v2 api instead of v3: https://github.com/cloudfoundry/cc-api-v3-style-guide#example-4 i like the idea of a unique error code. ideally the CAPI team

Anyone can help with interpreting the error log here garden-linux.pool.vl5hraecvg1.stream-in.command.failed cf-213 and

the collections example [1] does not actually include the required *resources* field [1] https://github.com/cloudfoundry/cc-api-v3-style-guide#example-2 -- Thank you, James Bayer

The CF CLI team just cut 6.12.3. Release notes and binaries are available at: https://github.com/cloudfoundry/cli/releases Highlights of this release include: Bug Fix: runtime error: index out

should the PUT example that updates the app name and space guid actually be a PATCH since it updates the resource? https://github.com/cloudfoundry/cc-api-v3-style-guide#put -- Thank you, James

Dan is correct - "cf file" for getting stdout/stderr files directly was deprecated some time ago. I'll try to locate when that happened (it was before my time.) From the cli, "cf logs" for

Have you tried running `cf logs` instead? Anything written to STDOUT or STDERR should be visible there for some period of time. For long term storage, you should look at setting up a log drain on

Hi, we are also facing the same issue when we check the "cf files pfh-cos-dicomobjectstore-dev /logs" we are able to see only the staging logs and not the stdout.log abd stderror.log. we need to

Hi , We are having the same problem where we are not able to see the stdout.log and stderror.log for all the application deployed in the cloud. Could you please let me know how do we access the logs