Jesse, sorry for the late reply. One thing we normally add to our internal bosh releases - something that is especially useful for the control/drain scripts, but that we do almost for every single pro

Just a couple of random notes about this: - since we have a lot of certificates in our deployment manifest (not just the CF/diego ones) we actually have a step in our deployment process that automatic

> Was the current maximum number of instances really implemented?. No, it wasn't implemented yet. But it's just an improvement to avoid calling the API. > I see your point however it sounds like somet

Sergio, there are multiple ways to do this: - call the API to get the number of instances and then send the request to each instance, making sure that each instance confirms that the cache was cleared

Dmitriy, > is this something that you all determined you need? We have confirmed with our IaaS provider that they believe guests to be not affected, as such disabling PTI would seem like a good way to

Are there plans to allow operators to boot with nopti/pti=off?

One thing that is missing (that I mentioned in the original proposal) is the ability for operators to specify the CFS period. The default (and current hardcoded value) is 100ms. To understand why this

#cf

(sorry, please ignore this message)

FWIW, we sometimes suggest to use the manifest to pass complex configuration via JSON: applications: - name: myapp instances: 1 memory: 32M disk_quota: 128M env: MYAPP_CONFIG: |- { "token": "116ba6c17

Hi Guido, I think you may be interested in the proposed resolution of https://github.com/cloudfoundry/cloud_controller_ng/issues/904 and https://github.com/cloudfoundry/cloud_controller_ng/issues/905.

Shannon, I agree with Mike - we're in a similar situation where we already have implemented all network ACLs and FW rules - so also for us access control would be the priority, and partitioning nice t

Shannon, Are there plans to extend the use of zap to all CF components? Thanks, Carlo

Hi Bernd, What we do in these cases in Rakuten is to implement an API that receives requests from unprivileged users, perform any additional validation authorization logic we deem necessary and then,

It is our understanding that currently application instances get CPU quotas assigned via cgroup CPU shares on the container running them[1]. This effectively sets a "minimum quota" of CPU time each co

Will just drop this here in case somebody wants to add something: https://github.com/cloudfoundry/loggregator/issues/150

Guillaume, thank you so much! One beer at the next CF summit is on me. :) Carlo

Yes, it's the protocol[1] proposed by ISRG letsencrypt[2] (under the linux foundation umbrella) that allows automated generation and PKI signing of TLS certificates. For the record, there's a go imple

Our current policy to our users is SNI by default, i.e. unless they explicitly require non-SNI TLS termination they get SNI termination. We went with this because browser support seems good[1] and bec

While we're talking about TLS, but this is only partially related, it would be awesome if we were to implement (or some hooks were provided to be able to complete) either the http or tls ACME challeng

We don't have the requirement to use an external secure store, but for that custom terminator component we were thinking to use an external secure store (Vault or something along those lines) to make