Cool, that makes a lot of sense. Thanks for filling in that gap in my understanding.

I read through this yesterday and didn't have any specific comments to leave in-line, but I am happy to see this surface now as I know it's come up in a number of settings in the past. I also thought

Nice! Love the gif demo :)

I think I'm in favor of this idea overall as well. Jesse, if I understand correctly, you're advocating "don't fork, just use branches". Is that right? What about the case where team A needs to use a f

Is this for production or testing? If its for testing, definitely check out cf-deployment <https://github.com/cloudfoundry/cf-deployment> which uses new features of bosh to generate certs and keys for

Are you familiar with bbl (bosh-bootloader)? https://github.com/cloudfoundry/bosh-bootloader This is a command line utility for standing up a CloudFoundry or Concourse The team developing it has an ep

filtering rules would have affected other apps on the same VM? Or it works in some other different way? In the "batteries included" implementation of cf-networking, policy enforcement is still done wi

Just wanted to chime in and say how much I appreciate these projects. cf-deployment and bbl, combined with the cf-deployment-concourse-tasks, have been an immense improvement to our experience for dev

One thing worth considering is that with container networking, there will be more use cases for apps that bind to ports but do not expose a route externally: for example: https://github.com/cloudfound