I really like the idea of finding a way to move away from bundling binaries with the buildpacks while continuing to not require internet access. My organization actually doesn't even use the binary bu

You mention that this change is non-breaking for metrics users. I don't know much about protobufs backwards compatibility story. Can you detail a little more the implications from a compatibility stan

Thanks Mike that helps. Hopefully that work will get prioritized in the next year or so. :) For the record, on the stemcell side I've been battling a non CF issue [0] with Trusty that I'm hoping is fi

Thanks for the heads up Jim, I use wire (https://github.com/square/wire) for a number of my projects. Unfortunately, it appears the map<string, string> syntax is too new for wire. Looks like I have so

I may not have anything that qualifies as compelling. But, here are some of the reasons I've got: * If skipping Xenial that give at the most 1 year to transition from trusty to a 2018.04 based rootfs.

Thanks for doing that research Eric. So, it appears to be some requirement for Heroku compatibility. So, I guess I have 2 issues I'd like to dig further on that might help other from repeating the iss

Ubuntu Xenial Xerus was released a few weeks ago. Any plans to incorporate Xenial into the platform? Stemcells and/or new root fs? The recent lucid to trusty rootfs fire drill was frustrating to my cu

This burned me today because I was attempting to put fonts into the home directory identified by the java system property "user.home" (which is /home/vcap) instead of the environment variable $HOME wh

This is awesome! Thanks guys! Mike

I have a few customers that grab that instance index to aid in monitoring and logging and to self identify in certain situations. Is there an issue with continuing to expose the instance index? I don'

Here is another minor use case. My users are often confused that a stopped app returns a 404 instead of a 503. So, we implement that functionality for the user using an app mapped to wildcard routes t

Yup, makes sense. I'm sure there is some valid reason for Diego not to use log_sender.ScanLogStream today. When that get's sorted out then the event demarcation and this replacement will all be in the

We passed the smoke tests by: * Only returning a 503 if the requested route exists. * Embed the old 404 page text in a comment of the returned html. Mike

I'm an idiot. I see what you and Eric are saying now. Put the code in Dropsonde then let the Executor simply initialize Dropsonde that way. Works for me. Thanks, Mike wrote:

You may want to reference the issue I created on executor. In that issue I note that I don't think dropsonde is the right place to do this token replacement because dropsonde doesn't know that the eve

Rather than continue this discussion here I've created an issue stating my case here: https://github.com/cloudfoundry-incubator/executor/issues/17 Mike

Thanks for the insight Jim. I still think that the Executor is the place to fix this since multi line logging isn't a Loggregator limitation it is a log inject limitation which is owned by the Executo

Thanks for the clarification Danny. I guess the point I was trying to make earlier with the "oracle_library" buildpack use case, is that this feature has some potential functional commonality with the

I was thinking whoever demarcates and submits the original event to loggregator. dea_logging_agent and the equivalent in Deigo. Doing it at that point could provide a bit more flexibility. I know this

Before I submit the CLI issue let me ask one more question. Would it be better to replace the newline token with /n at event creation time instead of asking the cli, splunk, anyone listening on the fi