If you're trying to get the memory usage for everything running in the app's container, then `cf app` is your best bet. If you want to look at specific things inside the container (cause there will be

wrote: This is probably not necessary as there's a bunch of ways to override PHP config currently. You mentioned `.user.ini` files which is a great option, you can also use `.htaccess` files assuming

You can include a `.profile.d/` script or a `.profile` script. It depends on exactly what you're trying to do as to which one would be better to use, but I believe most of the time you'd want the `.pr

No. See this email for an explanation. https://lists.cloudfoundry.org/archives/list/cf-dev(a)lists.cloudfoundry.org/message/B76YGMZ5DQS2WGJZLAI45LBV6ZRKVVRI/ Dan bren(a)juanantonio.info> wrote:

I don't have strong feelings one way or another on this, but I will say that when I was doing a bit of plugin development this is an area that confused me. I was quite sure that the cf cli was not jus

I think this has come up before, although I'm not sure if anything came out of that thread. http://cf-dev.70369.x6.nabble.com/cf-dev-aligning-cf-push-health-check-default-value-tp4718.html FYI, there'

I believe the idea is that the last build pack in the list will have the final say. It can either return the command it wants to use or it can take the command from a previous build pack and use (or p

+1 - Can't wait. This looks like it will be a nice step forward for build packs! Dan

Sorry, I didn't explain that very well. Let me try again. In the simplest case where you're watch it from a terminal / console, yes it would be the same. A few cases where this might be an issue: - bo

See inline... Noted. It is an interesting point that this is isolated to just those circumstances. I don't think that this is a build pack error because you're not getting to the point where the appli

The 500 error is coming from Cloud Controller, which indicates a problem there. Check out the CC logs and look for a stack trace to get more details on what is failing. It doesn't mean that CC is nece

Just my $0.02, but I like the current behavior. I find it helpful for troubleshooting purposes to be able to get the stream of HTTP messages inline with the output from the cli. It helps to very quick

I don't think it's the build pack itself that's taking up this space, it's what the build pack is installing. In this case, I think it would be Python & your Python dependencies. You can `cf ssh` into

Any chance you could include more output from the problem? Might be helpful to see what is going on when it fails. A bit of a guess, but it sounds like the build pack requires that much space to stage

Take a look at TCP Routing. In that case, the client connects through a different path and I believe you can handle SSL directly from your application. https://docs.cloudfoundry.org/adminguide/enablin

The app_logs demo is just logs. Look at either the firehose demo or the container_metrics demo. https://github.com/cloudfoundry/noaa#logs-and-metrics-firehose or https://github.com/cloudfoundry/noaa#c

I think this might also be helpful. https://github.com/cloudfoundry/noaa#sample-applications Sample app that shows how to connect to loggregator and stream container metrics. It can run as an admin or

If the ETCD servers are working, you might try restarting your dopplers. The dopplers register in ETCD and Metron looks at ETCD to locate the dopplers. If ETCD is working and you're getting this messa

Disregard what I said earlier. I think John's right. The output from staging is showing... That looks like it could be coming from the null-buildpack. https://github.com/ryandotsmith/null-buildpack/bl

What is the system you are targeting? For example, a bosh lite install, PCF-dev, PWS, Bluemix, other? If it's a system you deployed, which CF Release & Diego release are you using? Also, can you push