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

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

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

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

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

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

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

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:

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

Hi Arghya, You have mentioned in Github that you were able to overcome this issue. For everyone else, here is the context and a bit more information. History In very early CFCR days, we did not

Dear Josh, Thanks for the context, I wasn't aware of what happened before the release of networking 2.0. To stick with your example, though: From what you are saying I have understood that you would

aaarrgh, there is a bug in my psuedo code clusterWeight = [v1,v1,v1,v1,v1,v1,v2,v2,v2,v3,v3] should be clusterWeight = [v1,v1,v1,v1,v1,v1,v2,v2,v2,v3,v4] Full solution: Implementation: "Randomized

I put a long comment in the doc, maybe comments are good for short notes. here is the spiel "The sum of weights must add to 100" I would say this is where being user friendly ends. If I add reviews-v4

The CF Routing team has received feedback from many users that support for weighted routing would make it easier to accomplish their goals. We have a proposal on the preferred user experience for

Hi Marco, I'm happy to provide more context on the container networking 2.0 reference. The container networking team submitted a PR to cf-deployment with changes required for them to ship v2.0.

That issue could be addressed by having CFCR use a different router group, which is part of the solution we have proposed here:

Also: I suspect that the CFCR route-sync feature has a dangerous interaction with CFAR Cloud Controller, if both CFCR and CFAR are sharing a TCP Routing API. CFAR Cloud Controller creates and uses a

Hi Oleksandr, What alternative do we have if we want to use kubectl with tls Thanks, Arghya

Hi, cf-dev Almost one year ago CFCR has added the ability to expose applications using CFAR gorouter. This was an experiment. We haven't added any changes to this feature for one year and plan to

Hi cf-dev- Here is a feature narrative. The feature narrative is called "Let's Fix CPU Sharing and Metrics in CF" (but actually it's just a proposal to make them quite a lot better). More information