Hi Norm, That's an interesting possible UX. Part of this process is to gather feedback before making a change and to potentially alter the proposal to better fit everybody's needs. Thanks for sharing

Hi Dr Nic, Yes this is a proposal to maintain that workflow, but with a slightly different command set. The title is bad. Should have called it Proposal to replace --no-start. -Zach

Hey all, We asked for some feedback regarding the use of the --no-start flag some time ago. As a result, we're proposing a change to push in the upcoming CLI v7. In the linked doc we've described what

Hello cf-dev, We are writing to announce a couple of major plans for both the CC API and the CF CLI teams. We've recently formed a new team: the v3 acceleration team. What? The goals of the team are t

Congrats CF Networking Team!

Awesome feature. Congrats Services API Team!

thanks to all that have replied. i'd like to ask a clarifying question. it sounds like most of these use-cases are "set up some environment for the app". this implies to me that these workflows are fo

Hi Lee, Have you seen the new variable substitution feature for manifests? It might really help your use-case. https://docs.cloudfoundry.org/devguide/deploy-apps/manifest.html#multi-manifests -Zach

Hey Preetam There's not any work to get 'cf restart-app-instance` to update env vars and there is not a way to clone an app. The current canonical method for updating an app's config, is to perform a

#cf

Thanks for taking the time to read through it. There was no specific consideration around API similarity in general. It just seemed to make sense for this specific use case. Kube has a nice partitioni

Hey all, The CAPI team would like to share a proposal to apply metadata to API resources. Please have a look and add comments for any questions or concerns. https://docs.google.com/document/d/1Ebko_wN

Excited to see this proposed Nikolay! Nikolay has been sharing this project with some of the core teams over the last couple of months. We have even been giving some thought to adopting some of the be

This was killing me the other day on cf-deployment. I really prefer to exclude the 'v'. It doesn't seem to add anything. -Zach

Wanted to close the loop on this. We are now making the change to enforce secure communication. It is required as of capi-release 1.46.0. This will be included in upcoming cf-release and cf-deployment

Hey all, We're working on exposing some new ways of interacting with apps through the cli. I wrote up a blog post to share our progress. We'd love for the tinkerers out there to give some of this stuf

Hey Jon, You should be safe to continue working the way you are. The API that is used under the hood is here http://apidocs.cloudfoundry.org/272/user_provided_service_instances/creating_a_user_provide

Hi Ketaki, I'm not able to reproduce that issue on latest CF. -Zach

Hello Prasad, This is actually expected behavior. You can find documentation about service access here https://docs.cloudfoundry.org/services/access-control.html. It notes a limitation at the bottom.

I'm happy to announce that the CAPI and Diego teams have completed work for CF v269 that enables all communication between the two systems to use mTLS. This announcement is the beginning of a migratio

Hello Ketaki, This is a known issue. When a plan is disabled it becomes "invisible" to users. However, we don't remove existing service instances because this would break existing apps. Ideally a user