Good day everyone, Let me first introduce myself. My name is Sai and I am the new PM on Release Integration team. I am super excited to be here and also about the upcoming major cf-deployment

FYI... Same time 8a Pacific or 11a EST and also streamed on zoom. Room 116 at the Philadelphia convention center. Zoom link: https://zoom.us/j/757994996 So join remotely if you can or if you are at

I have a kind of same issue as you trying to understand how a buildpack works and creating a new one. The golang library used in the official buildpacks has no documentation, so it makes really

Feel free to reach out in the #capi channel on the Cloud Foundry Slack and folks from our team would be happy to chat! As I mentioned earlier, we're actively working on the MVP so it's very

This is outstanding. How can I get involved? I’d love to jump into that conversation with both feet and help!! We are looking to better control egress and offload app security on ingress.

Hi Cade, This won't necessarily help for your immediate needs, but wanted to share that the Cloud Controller (CAPI) team is actively working on experimental support for including user-specified

If your buildpack itself needs to be compiled, you have two choices: 1.) Compile locally, package a buildpack and install with `cf create-buildpack`. 2.) Use a shim script to build then run your

Hello Cloud Foundry: Just checking back on whether there are ways to control access to org or spaces using UAA scopes (i.e., mapping LDAP Groups to Cloud Foundry Orgs and/or Spaces). I last posted to

The default version of Node.js in the dotnet-core buildpack will change from the latest 6.x version to the latest 10.x version in the first release of the dotnet-core buildpack after April 28, 2019.

The default version of Node.js in the Ruby buildpack will change from the latest 6.x version to the latest 10.x version in the first release of the Ruby buildpack after April 28, 2019. Due to the end

Thank you all for your replies and input! We’ve decided to go forward with treating this as a bug (and not an expected behaviour) and hence not a breaking change. Best regards, Oleksii, on behalf

Hi, I'm totally in favour of fixing this. The current behaviour always felt wrong and I'm looking forward to the change. Best, Sascha

Can't talk now.

Sorry, the calendar was all mixed up, it’s Thursday 28.03-- Oleksii Fedorov Senior Software Engineer Pivotal Labs, Berlin DE: +49 15757 486 476

Of course, we’re just trying “to play the card” that the original behaviour was a bug in the first place. As an admin, If you want to see enabled and disabled plans as a result of the same

Long time reader... first time poster :D I'm really digging and deconstruction a few different buildpacks trying to understand how they really work. supply, compile, detect, etc. Especially the

If you take the conservative approach it would be a breaking change. We have a tool that validates the CF environment after deployment. In our use case, the service exists with plans x, y, z but plan

Hey, friends! Following up on this one more time before we make a decision (currently favouring that this is not a breaking change). We’ll make a decision how to move forward with this issue this

Woohoo! I can't begin to convey how excited I am about this as a former CAPI PM. -Dieu

Hello, The CAPI team has been working on a document to give operators some guidance with regards to knowing when and how to scale their Cloud Controllers (and related jobs in capi-release) based on