I’m going to agree with Marco’s concerns here. Making life harder and less stable for the end users of CF has a real potential to alienate and push away the CF userbase altogether, even if it’s

Use case: I want v1-stable to receive 5 times more traffic than each individual upgrade version I deploy Phase 1: Deploy alpha 1 Proposed (sum MUST add up to a 100): v1-stable: 83 v2-alpha1:

Hello All, Simon Moser, the Project Lead for the Bits-Service team within the Application Runtime PMC, is rotating into a different role within IBM. We thank him for his time serving as the

Hello all, IBM is nominating Peter Goetz for theCF Bits Service Project Lead in the Application Runtime PMC. Peter is a Software Engineer at IBMworking both as a core contributor to the Cloud Foundry

FYI... Zoom soon. Best, dr.max ibm ☁ silicon valley, ca dr.max ibm ☁ silicon valley, ca

All, We held our last CF/K8S SIG call today, which is great news. They served the purpose of getting a bunch of the interesting work that's happening out into the open, and now most of the efforts are

Food for thought: One of the challenges here is that maintaining patches for past coordinated releases is expensive (both in time and CI costs). In the CF ecosystem, this has traditionally been the

I don't agree with the claim that we didn't introduce major breaking changes in the past - we did. Routinely. `cf-release` was sem-ver only insofar as every version was a major version. Changes just

I was about to mention that I indeed enjoyed the existing CF model of releases which roughly translated to “you better run fast” for consumers. The thing I found needed some tweaking in the

CVE-2018-11047: UAA accepts refresh token as access token on admin endpoints Severity HighVendor Cloud Foundry FoundationAffected Cloud Foundry Products and Versions You are using uaa versions 4.19

As the previous project lead for RelInt, I want to speak to Marco's concerns directly. We _definitely_ considered the operator as an important persona during any decision-making; if anything, we were

Another point: most (certainly not all, but most) CVEs are stemcell, buildpack, or rootfs bumps that can be consumed safely/have minimal integration concerns. Even those that are in more substantive

Thanks Geoff, Marco, Chip, Jesse, Bernd, and David for sharing your feedback and thoughts. You’ve expressed valid concerns and provided valuable context that I take to heart. I really appreciate the

We haven't done anything beyond proposing the interface and implementing the option to respect permissions. Since the time of this proposal, BPM has implemented a feature that should allow us to run

Hi all, We're pleased to confirm that there'll be an Unconference at Basel again this year at 6pm on Tuesday 9th October. We're planning on the same rough schedule as last year, so talks interspersed

Thanks for putting the time into another unconference. I'm working on a book about the UAA; hopefully its done by the conf. Since the UAA is delightfully invisible to most people, I'd love to do 5-10

Hi CF Team, I was exploring on variable substitution in manifest.yml : https://docs.cloudfoundry.org/devguide/deploy-apps/manifest.html#variable-substitution I see there is a vars.yml that can be used

If the CF CLI doesn't support environment variables, It would be really wonderful if the file would consider environment variables. It would be more in line with the 12 factor manifesto, it would

Yes that sounds right - or if you’re deploying in CI then your CI pipeline would create the vars.yml file for each diff target/stage. Nic

Hello, The CF container networking team has received feedback from users regarding some pain points around using Application Security Groups (ASGs) for defining egress policies. After much research,