1. Cf-Dev
  2. Messages

Expanded

Topics Messages
   Date   
BOSH PMC: Quarks Project Lead call for Nominations

Marco Voelz
 

Hi everyone,

 

Vlad Iovanov, the lead for the Quarks project within the BOSH PMC, is stepping down from the project, to focus on KubeCF and responsibilities internal to SUSE. We thank him for his service.

 

The Quarks team now has an opening for its project lead. Project leads must be nominated by a Cloud Foundry Foundation member. Please send nominations directly to me or in reply to this message no later than 11:59 PM PDT on June 25th.

 

Also, if you have any questions about the role or the nomination process, as described in the CFF governance documents (https://www.cloudfoundry.org/governance/cff_development_operations_policy/), please let me know.

 

Thanks and warm regards

Marco Völz, BOSH PMC Lead
Re: Proposal to retire the Perm project in the App Runtime PMC

Guillaume Berche
 

Hi Eric,

Thanks for sharing the plans for perm project with the community. Can you please remind me where more information can be found related to the "evolution of the identity space" ? I could yet not find mention of them into the CF4K8s index doc [1] or older "UAA integration with Kubernetes & Istio" [2] ?

More precisely, as I understand that CF4K8S will require Cf operators to be authenticated against K8S, I did not yet see the confirmed plans to require CF users (developers and admins) to be registered into K8S in order to grant them permissions on K8S entities using native technologies such as RBAC or Open Policy Agent (only found so far an exploration of CRD UX into [3]).

I feel that maintaining compatibility with CF CLI and CF CC API while migrating to Cf4K8S is an important part of CF value proposition which protects CF user base (developers and admins) from K8S complexity and preserves CF simple developer experience.  Is there ways the OPA or K8S RBAC would indirectly be used from CF CLI and APIs to fulfill perm project use-cases, without requiring these users to ramp up with associated K8S complexity and cognitive load ?

Thanks in advance for your help,


Guillaume.


On Fri, Jun 12, 2020 at 6:17 PM Eric Malm <emalm@...> wrote:
Hi, everyone,

I'm proposing to retire the incubating Perm project in the App Runtime PMC and to move its associated repos to the cloudfoundry-attic GitHub organization. We will plan to discuss and approve the proposal at the June 23rd App Runtime PMC meeting.

For context, the Perm project started in 2017 with the goal of providing a general authorization service for Cloud Foundry that could absorb and extend the authorization roles currently encoded in Cloud Controller. On account of difficulties integrating with the v2 Cloud Controller API, the project was placed on hiatus in late 2018, where it has remained to date. Although making authorization in the Cloud Foundry App Runtime more flexible and independent of existing components remains an important goal for the project, continual evolution in the identity space and the ongoing transition of the App Runtime to Kubernetes make it likely that any new efforts to achieve that goal will rely more directly on other community projects and technologies, such as the Open Policy Agent or Kubernetes RBAC itself.

Thanks,
Eric Malm, App Runtime PMC Lead
Update on the GA of cf CLI V7

Josh Collins <collinsjo@...>
 

Good Afternoon, Good Morning, and Good Evening,


We'd like to share a quick update regarding the GA of the v7 CLI. We're confident in the v7 GA and although the original target date hasn’t changed, we've made a few adjustments to how we’ll approach GA that you should be aware of.


TL;DR

  • We expect version 7.0.0 to release on or before June 22nd

  • The 7.0.0 release should have no impact to existing systems/workflows that rely on the v6 cf CLI

  • Thank you!


For those interested in more detail...

The following milestones are no longer considered pre-requisites for the GA of the v7 CLI (rationales for each is provided further below):


  1. Providing the package management infrastructure to support pinning to the v6 version of the CLI

  2. Getting the v7 CLI running in all of Release Integration's CF-Deployment CI pipelines


Rationales for the removal of  the following milestones:

  1. Providing the package management infrastructure to support pinning to the v6 version of the CLI:
    The v7 CLI depends on the latest CAPI release (v1.95.0), which the vast majority of foundations running in the wild will not have deployed yet.

    We’ve decided to publish the v7 GA to the various package managers we support in the same manner as we have been publishing the v7 betas.  Folks already consuming the v7 beta via a package manager should be updated to 7.0.0 the next time they update. Please note that the binary name of the cf CLI 7.0.0 will be `cf`, as opposed to the beta binary name `cf7`.

    This is intended to minimize disruption to the community and afford the CLI team the time we need to work through the discovered complexities of package management.

    As a result, staying on the major version of the CLI that you are currently consuming from package managers will not require special intervention (with the exception of those who are consuming the beta v7).

    For those who must do so, our Downloads section of the CLI README will be updated with instructions on how to switch back and forth between the v7 and v6 CLIs.

  2. Getting the v7 CLI running in all of the Release Integration team’s (RelInt’s) CF-Deployment CI pipelines:
    The purpose of RelInt's pipelines is to validate the stability of a particular combination of the component releases specified in the CF-Deployment manifest. In the context of RelInt's pipelines, the CLI is used as a vehicle to exercise the platform, and when their pipelines run green, a release of CF-Deployment can be published.

    While this milestone provides valuable information, it's not primarily a validation of the CLI itself. The pipelines that the CLI team manage test the CLI exhaustively.  When our pipelines run green, we can confidently release a version of CLI, including the GA of v7.

    That said, we've worked with the Release Integration team to get a copy of one of their pipelines running with the v7 CLI release candidate against a branch of cf-acceptance-tests with modifications necessary to run it.

    This helps us build confidence that the coming migration of all of the Release Integration team's pipelines will be relatively smooth.


We appreciate any efforts you take to share this information with others in the community and look forward to the GA of the cf CLI!


For more information and/or questions about the v7 CLI, please visit Cloud Foundry docs, message us on slack, or visit our github.


Thanks so very much,


The CLI Team
Re: Route integrity on Windows

Matthew Horan <hmatthew@...>
 

Hi Aaron,

As you've discovered, the experimental route integrity ops file exists and is a stopgap until Envoy Windows porting work is complete. This experimental ops file uses nginx in place of Envoy, and should be suitable for most usage. It is still considered experimental because we have not received much feedback on it, however we have been using it internally at VMware with no issues for some time now.

VMware and Microsoft are actively working on porting Envoy to Windows, as you noted. This work is ongoing, and no delivery date is available at this time. We are currently working to address performance issues due to the eventing model on Windows specifically, with Microsoft is leading those efforts.

I would recommend trying out the experimental ops file to see if it suits your needs. Please feel free to engage with us if you discover issues, as we would love the feedback and look to improve the experience.

Best,
Matt

From: cf-dev@... <cf-dev@...> on behalf of Aaron Huber <aaron.m.huber@...>
Sent: Friday, June 12, 2020 5:32 PM
To: cf-dev@... <cf-dev@...>
Subject: [cf-dev] Route integrity on Windows
 

We have been waiting for some time for a solution for route integrity support on Windows and I wanted to check on the status and compare notes on what others are doing.

 

We are still using the Windows 2012 R2 stack because we require IPSec encryption of the HTTP traffic between the router and the instance.  Overall CF has made great progress on removing all non-encrypted traffic across the platform and the last two places where encryption is missing are nats which is finally underway, and route integrity on Windows.  Once we close those two gaps we’ll finally be able to stop using IPSec on the platform, but until then, since Windows 2019 still doesn’t support IPSec along with NAT in containers, we are stuck with the older stack.

 

There are a few options that we know of:

 

  • Use the experimental route integrity ops file using Nginx instead of envoy – is anyone using this successfully in production?
  • Wait for Envoy support on Windows – this has been in progress for a while and Microsoft still seems to be actively working on it, but once it becomes available will support for it be added to Cloud Foundry?
  • Wait for Kubernetes support to be fully production ready – hopefully the new platform will be fully encrypted from the beginning

 

What are other platform operators that offer Windows support doing for now?

 

 

Aaron Huber

Intel Corporation
Re: Feedback requested: Sticky sessions: If request includes VCAP_ID cookie, always include it in the response

Marco Voelz
 

Great, thanks for the clarification!

 

Warm regards

Marco

 

From: <cf-dev@...> on behalf of David McClure <dmcclure@...>
Reply to: "cf-dev@..." <cf-dev@...>
Date: Thursday, 11. June 2020 at 02:46
To: "cf-dev@..." <cf-dev@...>
Subject: Re: [cf-dev] Feedback requested: Sticky sessions: If request includes VCAP_ID cookie, always include it in the response

 

Jonathan is correct. 

 

This issue applies whether or not the reverse proxy is a route service. In fact, while the reproduction steps in the original post used a route service, later in the issue, the original poster indicates that the use case they care about solving for currently is using nginx as the reverse proxy (not as a route service).

 

And yes, I believe it also applies if the proxy and the backend are deployed on two different CF's (though that is not what we care about now, so if a solution cut that out of scope, I think it'd be fine).

 

In any case, I think the issue title feels OK still given the above, but thanks for asking the question and giving us a chance to clarify!

 

From: cf-dev@... <cf-dev@...> on behalf of Jonathan Matthews via lists.cloudfoundry.org <contact+cfdev=jpluscplusm.com@...>
Sent: Tuesday, June 9, 2020 2:37 AM
To: cf-dev@... <cf-dev@...>
Subject: Re: [cf-dev] Feedback requested: Sticky sessions: If request includes VCAP_ID cookie, always include it in the response

 

Marco,

 

I’ve no extra information on this than this thread, but it strikes me that it’s definitely possible to deploy apps to CF which would reverse proxy other apps on CF, *without* attaching them as route services. 

 

I think it might be a interesting and potentially sub-optimal choice to do so, given route services are essentially reverse-proxy-as-a-service(!), but I can definitely see folks doing that. Perhaps with workflows baked in from before route services were a thing. 

 

Overall I’d suggest the framing of this should reference the hosting of both the proxy and the origin service: AIUI both have to be on CF for this thread’s problem and solution to be in scope. They can be *different* CF installations, however, if I’ve got it correct in my head ...

 

“Reverse proxy applications which are called by a gorouter, and which themselves call a gourouter”? Hmmm. Perhaps a bit too wordy ...

 

HTH,

Jonathan

 

On Tue, 9 Jun 2020 at 08:47, Marco Voelz <marco.voelz@...> wrote:

Dear David,

 

Thanks for the detailed explanations and the heads-up! While looking at the initial issue in github, I noticed that there's a mismatch in vocabulary between the OP and your team responding: My understanding is this change impacts route service, as they are known to the Cloud Controller, it does not impact any generic setup where people deploy a reverse proxy application and forward from there the requests to individual CF applications. Is this an accurate summary?

 

In this case, I'd like to see this reflected in the language for the issue/backlog item: only scope this to cf route services, not "cf deployed reverse proxy applications".

 

In case this influences also reverse proxy applications deployed with other means than route services, I'd need to ping some internal teams to assess the impact of this from their point of view.

--

Jonathan Matthews
London, UK
http://www.jpluscplusm.com/contact.html
Re: Customize the Email content of password reset request #cf #uaa

Dr Nic Williams <drnicwilliams@...>
 

Perhaps try finding the UAA core team on the CF Slack in the #uaa room and they might be able to help you.

Nic

On Mon, 15 Jun 2020 at 5:18 am, shilpa kulkarni <shilpakulkarni91@...> wrote:
Hi,

I am using UAA war file in tomcat. I want to customize the email content of password reset request. I am not getting where to change that code.
Can anyone please provide solution for this?

Thanks & Regards
Shilpa

--
Dr Nic Williams
Stark & Wayne LLC
+61 437 276 076
twitter @drnic
customize the validation message of mismatching password and confirm password in reset password page #uaa #cf

shilpa kulkarni
 

Hi,

I am using UAA war file in tomcat. I want to customize the validation message of mismatching password and confirm password (in reset password page). I am not getting where to change that code.
Can anyone please provide solution for this?

Thanks & Regards
Shilpa
Customize the Email content of password reset request #cf #uaa

shilpa kulkarni
 

Hi,

I am using UAA war file in tomcat. I want to customize the email content of password reset request. I am not getting where to change that code.
Can anyone please provide solution for this?

Thanks & Regards
Shilpa
Re: Reset password : if the unregistered email address entered then also giving success message. #cf #uaa

Jonathan Matthews <contact+cfdev@...>
 

Hey Shilpa,

I wouldn’t be surprised to find this is intentional. 

If this didn’t happen, then it would be possible for an attacker to try submitting many addresses, and then receive confirmation of which of them were related to accounts on the service/system.

I also wouldn’t be surprised to find that the service had an option to disable this behaviour in trusted environments, but I’ve no insight into that - I’m just mentioning that’s it’s /possible/ :-)

HTH,
J

On Sun, 14 Jun 2020 at 16:59, shilpa kulkarni <shilpakulkarni91@...> wrote:
Hi,
 
If I pass email id (which is not registered)for reset password link  then it should give error message but it is giving success message only. I am not getting where to change that code.
Can anyone please provide solution for this?
 
Thanks & Regards
Shilpa

--
Jonathan Matthews
London, UK
https://jpluscplusm.com
Reset password : if the unregistered email address entered then also giving success message. #cf #uaa

shilpa kulkarni
 

Hi,
 
If I pass email id (which is not registered)for reset password link  then it should give error message but it is giving success message only. I am not getting where to change that code.
Can anyone please provide solution for this?
 
Thanks & Regards
Shilpa
Route integrity on Windows

Aaron Huber
 

We have been waiting for some time for a solution for route integrity support on Windows and I wanted to check on the status and compare notes on what others are doing.

 

We are still using the Windows 2012 R2 stack because we require IPSec encryption of the HTTP traffic between the router and the instance.  Overall CF has made great progress on removing all non-encrypted traffic across the platform and the last two places where encryption is missing are nats which is finally underway, and route integrity on Windows.  Once we close those two gaps we’ll finally be able to stop using IPSec on the platform, but until then, since Windows 2019 still doesn’t support IPSec along with NAT in containers, we are stuck with the older stack.

 

There are a few options that we know of:

 

  • Use the experimental route integrity ops file using Nginx instead of envoy – is anyone using this successfully in production?
  • Wait for Envoy support on Windows – this has been in progress for a while and Microsoft still seems to be actively working on it, but once it becomes available will support for it be added to Cloud Foundry?
  • Wait for Kubernetes support to be fully production ready – hopefully the new platform will be fully encrypted from the beginning

 

What are other platform operators that offer Windows support doing for now?

 

 

Aaron Huber

Intel Corporation
Reminder: CAB call on Wednesday, June 17 @ 8AM PDT / 11AM EDT / 5PM CEST

Troy Topnik
 

Please join us for this month's Community Advisory Board call!

We'll have James Hunt from Stark & Wayne telling us all about managing BOSH from Kubernetes with Gluon:

 https://github.com/starkandwayne/gluon

... along with the regular community updates from the PMC leads and community Q&A. Here's the agenda:

https://docs.google.com/document/d/1SCOlAquyUmNM-AQnekCOXiwhLs6gveTxAcduvDcW_xI/edit#

And the chat room: slack.cloudfoundry.org - join the #cab channel Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/757994996 Or iPhone one-tap : US: +16468769923,,757994996# or +16699006833,,757994996# Or Telephone: Dial(for higher quality, dial a number based on your current location): US: +1 646 876 9923 or +1 669 900 6833 or +1 408 638 0968 Meeting ID: 757 994 996 International numbers available: https://zoom.us/zoomconference?m=BbM_MZowkH08pdKycQk10at13V5cLneM
Hope to see you there!

TT

--
Troy Topnik
Senior Product Manager, 
SUSE Cloud Application Platform 
troy.topnik@...
 
Proposal to retire the Perm project in the App Runtime PMC

Eric Malm
 

Hi, everyone,

I'm proposing to retire the incubating Perm project in the App Runtime PMC and to move its associated repos to the cloudfoundry-attic GitHub organization. We will plan to discuss and approve the proposal at the June 23rd App Runtime PMC meeting.

For context, the Perm project started in 2017 with the goal of providing a general authorization service for Cloud Foundry that could absorb and extend the authorization roles currently encoded in Cloud Controller. On account of difficulties integrating with the v2 Cloud Controller API, the project was placed on hiatus in late 2018, where it has remained to date. Although making authorization in the Cloud Foundry App Runtime more flexible and independent of existing components remains an important goal for the project, continual evolution in the identity space and the ongoing transition of the App Runtime to Kubernetes make it likely that any new efforts to achieve that goal will rely more directly on other community projects and technologies, such as the Open Policy Agent or Kubernetes RBAC itself.

Thanks,
Eric Malm, App Runtime PMC Lead
CF-K8s-Networking v0.2.0

Keshav Sharma <sharmake@...>
 

Hi cf-dev,

CF-K8s-Networking-Release v0.2.0 has been cut!

Release Highlight

  • Platform Operator can verify that cf-for-k8s leverages Istio 1.6.x version details



What was included in CF-K8s-Networking-Release v0.1.0?

Release Highlights

Basic Ingress Routing:

  • Alana can confirm that Istio objects and Services describing CC Routes are represented in the K8s API details
  • Cody can confirm that an application on cf-for-k8s is accessible to end users via basic HTTP routing details
  • Cody can map/create routes that have FQDNs that are longer than 63 characters details
  • Cody can confirm that wildcard routes get successfully created on cf-for-k8s details
  • Cody can confirm that ingress TLS is configured for the “default” app domain for a vanilla installation of cf-for-k8s details

Securing app and system component communications:

  • Alana can confirm that all communication between metacontroller and route syncer are encrypted and mutually authenticated (via sidecars) details
  • Alana can confirm that connections between istio control- plane components are encrypted details
  • Cody can confirm that ensure that all communications between system components and between apps are encrypted and mutually authenticated (via sidecars) details

Exposing networking sub-system metrics:

  • Alana can identify memory usage of ingress router by looking at metrics details
  • Alana can use prometheus to see details such as number of http, and tcp connections being made by the incoming traffic details
  • Alana can confirm that envoy is receiving up-to-date information from istio control plane details

CF-K8s Networking
Reset password : if the unregistered email address entered then also giving success message. #cf

shilpa kulkarni
 

Hi,

If I pass email id (which is not registered)for reset password link  then it should give error message but it is giving success message only. I am not getting where to change that code.
Can anyone please provide solution for this?

Thanks & Regards
Shilpa
Re: Feedback requested: Sticky sessions: If request includes VCAP_ID cookie, always include it in the response

David McClure
 

Jonathan is correct. 

This issue applies whether or not the reverse proxy is a route service. In fact, while the reproduction steps in the original post used a route service, later in the issue, the original poster indicates that the use case they care about solving for currently is using nginx as the reverse proxy (not as a route service).

And yes, I believe it also applies if the proxy and the backend are deployed on two different CF's (though that is not what we care about now, so if a solution cut that out of scope, I think it'd be fine).

In any case, I think the issue title feels OK still given the above, but thanks for asking the question and giving us a chance to clarify!

From: cf-dev@... <cf-dev@...> on behalf of Jonathan Matthews via lists.cloudfoundry.org <contact+cfdev=jpluscplusm.com@...>
Sent: Tuesday, June 9, 2020 2:37 AM
To: cf-dev@... <cf-dev@...>
Subject: Re: [cf-dev] Feedback requested: Sticky sessions: If request includes VCAP_ID cookie, always include it in the response
 
Marco,

I’ve no extra information on this than this thread, but it strikes me that it’s definitely possible to deploy apps to CF which would reverse proxy other apps on CF, *without* attaching them as route services. 

I think it might be a interesting and potentially sub-optimal choice to do so, given route services are essentially reverse-proxy-as-a-service(!), but I can definitely see folks doing that. Perhaps with workflows baked in from before route services were a thing. 

Overall I’d suggest the framing of this should reference the hosting of both the proxy and the origin service: AIUI both have to be on CF for this thread’s problem and solution to be in scope. They can be *different* CF installations, however, if I’ve got it correct in my head ...

“Reverse proxy applications which are called by a gorouter, and which themselves call a gourouter”? Hmmm. Perhaps a bit too wordy ...

HTH,
Jonathan

On Tue, 9 Jun 2020 at 08:47, Marco Voelz <marco.voelz@...> wrote:

Dear David,

 

Thanks for the detailed explanations and the heads-up! While looking at the initial issue in github, I noticed that there's a mismatch in vocabulary between the OP and your team responding: My understanding is this change impacts route service, as they are known to the Cloud Controller, it does not impact any generic setup where people deploy a reverse proxy application and forward from there the requests to individual CF applications. Is this an accurate summary?

 

In this case, I'd like to see this reflected in the language for the issue/backlog item: only scope this to cf route services, not "cf deployed reverse proxy applications".

 

In case this influences also reverse proxy applications deployed with other means than route services, I'd need to ping some internal teams to assess the impact of this from their point of view.

--
Jonathan Matthews
London, UK
http://www.jpluscplusm.com/contact.html
Re: Feedback requested: Sticky sessions: If request includes VCAP_ID cookie, always include it in the response

Jonathan Matthews <contact+cfdev@...>
 

Marco,

I’ve no extra information on this than this thread, but it strikes me that it’s definitely possible to deploy apps to CF which would reverse proxy other apps on CF, *without* attaching them as route services. 

I think it might be a interesting and potentially sub-optimal choice to do so, given route services are essentially reverse-proxy-as-a-service(!), but I can definitely see folks doing that. Perhaps with workflows baked in from before route services were a thing. 

Overall I’d suggest the framing of this should reference the hosting of both the proxy and the origin service: AIUI both have to be on CF for this thread’s problem and solution to be in scope. They can be *different* CF installations, however, if I’ve got it correct in my head ...

“Reverse proxy applications which are called by a gorouter, and which themselves call a gourouter”? Hmmm. Perhaps a bit too wordy ...

HTH,
Jonathan

On Tue, 9 Jun 2020 at 08:47, Marco Voelz <marco.voelz@...> wrote:

Dear David,

 

Thanks for the detailed explanations and the heads-up! While looking at the initial issue in github, I noticed that there's a mismatch in vocabulary between the OP and your team responding: My understanding is this change impacts route service, as they are known to the Cloud Controller, it does not impact any generic setup where people deploy a reverse proxy application and forward from there the requests to individual CF applications. Is this an accurate summary?

 

In this case, I'd like to see this reflected in the language for the issue/backlog item: only scope this to cf route services, not "cf deployed reverse proxy applications".

 

In case this influences also reverse proxy applications deployed with other means than route services, I'd need to ping some internal teams to assess the impact of this from their point of view.

--
Jonathan Matthews
London, UK
http://www.jpluscplusm.com/contact.html
Re: Feedback requested: Sticky sessions: If request includes VCAP_ID cookie, always include it in the response

Marco Voelz
 

Dear David,

 

Thanks for the detailed explanations and the heads-up! While looking at the initial issue in github, I noticed that there's a mismatch in vocabulary between the OP and your team responding: My understanding is this change impacts route service, as they are known to the Cloud Controller, it does not impact any generic setup where people deploy a reverse proxy application and forward from there the requests to individual CF applications. Is this an accurate summary?

 

In this case, I'd like to see this reflected in the language for the issue/backlog item: only scope this to cf route services, not "cf deployed reverse proxy applications".

 

In case this influences also reverse proxy applications deployed with other means than route services, I'd need to ping some internal teams to assess the impact of this from their point of view.

 

Thanks and warm regards

Marco

 

From: <cf-dev@...> on behalf of David McClure <dmcclure@...>
Reply to: "cf-dev@..." <cf-dev@...>
Date: Friday, 5. June 2020 at 19:19
To: "cf-dev@..." <cf-dev@...>
Subject: [cf-dev] Feedback requested: Sticky sessions: If request includes VCAP_ID cookie, always include it in the response

 

Hi all,

 

Recently, the following feature request was made for gorouter:

 

 

The suggestion for implementing this feature in gorouter is relatively simple and we have validated that it works: If the request includes a VCAP_ID cookie, then always include a VCAP_ID in the response.

 

While the cookie in the response is redundant in most cases, we think this is a reasonable change to make. It would only impact applications that use sticky sessions.

 

That said, we wanted to bring this up to a wider audience before proceeding. Please respond here or on the issue if you can share any reasons why we should not make this change.

 

 

Additional background:

 

Currently, when an application sets a cookie that matches one of the sticky session cookie names configured for gorouter, the gorouter will add an additional Set-Cookie header with the name __VCAP_ID__ with the value being the instance ID of the backend that handled that request. On subsequent requests, as the client includes this cookie in the request, the gorouter will route the request to the same instance. If it succeeds, it does not include the instance ID in the response (as this was assumed to be redundant information). The only exceptions currently are 1) if the backend sets the session cookie (most don't do this in every response for the same reason - it's usually redundant), or 2) if the backend instance was not found (e.g. because that instance failed or was rescheduled to another cell).

 

The current implementation described above works in most cases, but fails in the following way when there is a cf-deployed proxy in front of the backend.

 

In that case, the request path looks like this:

 

client -> gorouter -> proxy -> gorouter -> backend

 

In this scenario, the first gorouter in front of the proxy fails to find the instance ID of the backend, as it only looks for instances of proxy. Because it fails to match, in its response, it sets the cookie to an instance of the proxy app instead, and the subsequent request gets routed to a random backend. It ends up in a pattern where 2 requests go to the same backend at a time, and then flipping to a different one.

 

A workaround in the current implementation of the gorouter is to always have the backend application set the session cookie. This works, but requires changes to application code.

 

 

 

Thanks!

Dave

 

Engineer on #networking

 

 

 

 
Re: Seeking Nominations: Cloud Foundry Extensions PMC

Chip Childers <cchilders@...>
 

This sounds great, and aligns with how Dr Max combined running the CAB calls and leading the Extensions PMC. I'll leave this until EOD today, and then start a vote within the PMC.

Chip Childers
Executive Director
Cloud Foundry Foundation



On Thu, Jun 4, 2020 6:45 PM, Neil MacDougall NMacDougall@... wrote:

All,

 

I believe we are still seeking nominations for the extensions PMC.

 

I’d like to nominate Troy Topnik from SUSE – he has a passion for Cloud Foundry that would serve the extensions PMC well.

 

Regards,

 

Neil

 

From: Swarna Podila <spodila@...>
Date: Thursday, 7 May 2020 at 00:57
To: CF Developers Mailing List <cf-dev@...>, cf-extensions-pmc <cf-extensions-pmc@...>, Michael Maximilien <maxim@...>
Subject: Re: Seeking Nominations: Cloud Foundry Extensions PMC

 

Hi Everyone,

Just a quick reminder to send us your nominations by the end of Friday (May 8).

 

Cheers!

 

-- Swarna Podila (she/her)

Senior

 Director

, Community

 | Cloud Foundry Foundation

 

You can read more about pronouns here, or please ask if you'd like to find out more.

 

 

On Thu, Apr 30, 2020 at 4:30 PM Swarna Podila <spodila@...> wrote:

Hi All,

You may have seen Dr. Max's note earlier.  After leading Extensions PMC for almost four years, he would like to step down and make space for new folks to take on the role. 

 

Please send in your nominations for a new lead for Cloud Foundry Extensions PMC by the end of day next Friday, May 8, 2020. 

 

-- Swarna Podila (she/her)

Senior

 Director

, Community

 | Cloud Foundry Foundation

 

You can read more about pronouns here, or please ask if you'd like to find out more.

--
You received this message because you are subscribed to the Google Groups "cf-extensions-pmc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cf-extensions-pmc+unsubscribe@....
To view this discussion on the web visit https://groups.google.com/a/cloudfoundry.org/d/msgid/cf-extensions-pmc/CAPYQVGLQO3vLjyQ-YKvPWV8nWmf_40tndAB_Tg3WC5WaepAh%3DA%40mail.gmail.com.
Feedback requested: Sticky sessions: If request includes VCAP_ID cookie, always include it in the response

David McClure
 

Hi all,

Recently, the following feature request was made for gorouter:


The suggestion for implementing this feature in gorouter is relatively simple and we have validated that it works: If the request includes a VCAP_ID cookie, then always include a VCAP_ID in the response.

While the cookie in the response is redundant in most cases, we think this is a reasonable change to make. It would only impact applications that use sticky sessions.

That said, we wanted to bring this up to a wider audience before proceeding. Please respond here or on the issue if you can share any reasons why we should not make this change.


Additional background:

Currently, when an application sets a cookie that matches one of the sticky session cookie names configured for gorouter, the gorouter will add an additional Set-Cookie header with the name __VCAP_ID__ with the value being the instance ID of the backend that handled that request. On subsequent requests, as the client includes this cookie in the request, the gorouter will route the request to the same instance. If it succeeds, it does not include the instance ID in the response (as this was assumed to be redundant information). The only exceptions currently are 1) if the backend sets the session cookie (most don't do this in every response for the same reason - it's usually redundant), or 2) if the backend instance was not found (e.g. because that instance failed or was rescheduled to another cell).

The current implementation described above works in most cases, but fails in the following way when there is a cf-deployed proxy in front of the backend.

In that case, the request path looks like this:

client -> gorouter -> proxy -> gorouter -> backend

In this scenario, the first gorouter in front of the proxy fails to find the instance ID of the backend, as it only looks for instances of proxy. Because it fails to match, in its response, it sets the cookie to an instance of the proxy app instead, and the subsequent request gets routed to a random backend. It ends up in a pattern where 2 requests go to the same backend at a time, and then flipping to a different one.

A workaround in the current implementation of the gorouter is to always have the backend application set the session cookie. This works, but requires changes to application code.



Thanks!

Dave

Engineer on #networking
401 - 420 of 9441