Date   
REQUEST for REVIEW - Proposed Scope for CF-Deployment v4.0

Josh Collins
 

Hello Fellow Cloud-Foundrians,

Based on the feedback generated during the cf-deployment v3.0 retro and observations of the impact of 3.0 on the CF development community CI's, I'd like to share and gather feedback on proposed scope of the next major release of cf-deployment.

As per the action item generated in the 3.0 retro, I've created a Google Doc which describes the high-level changes under proposal.


Anyone with the link above can review and comment.
Please feel free to review and provide feedback in the document as soon as you're able.

We'll be locking the scope the middle of next week (Wednesday August 22nd).

For those interested in following, here's the v4.0 epic in our backlog.
 
Lastly, if you've got breaking changes that you'd like Release Integration to consider in the future please bring them to my and the team's attention:
Thanks very much for reading to the end and Happy Friday!

Josh Collins
PM - Release Integration
--
Josh Collins
PM - CF R&D Release Integration

NOTICE: [go-buildpack] Default Go version will change from 1.8.x to 1.10.x after 2018-09-17

Scott Sisil
 

The default version of Go will be updated to 1.10.x in the first release after 2018-09-17.


Per the Go release website, Go versions that are two releases behind the latest major release are not supported[1]. Therefore we are giving users a 30 day notice before we change the default version of Go to the latest major version 1.10.x and remove Go versions 1.6.x and 1.7.x as they are no longer supported. If you are using 1.6.x and 1.7.x, please make plans to migrate your applications to 1.10.x in the next 30 days.


[1] https://golang.org/doc/devel/release.html



Scott

CF Buildpacks PM


Re: Proposal: Improving Security for HTTP Ingress to CFAR Application Containers

Eric Malm <emalm@...>
 

On Thu, Aug 16, 2018 at 9:16 PM, Mike Youngstrom <youngm@...> wrote:
Oh man, after re-reading your email it now makes sense.  To be honest I didn't actually read the document you provided since it wasn't open for read to everyone so I just assumed what was in there instead.  Sorry.

Huh, something weird has been going on with the permissions on that document: this is the third time now that I've had to change them back to allowing global comments. If for some reason that reverts back to a more restricted mode (on this proposal document or any others I've posted here) please let me know via an access request or via email or Slack and I'll correct it again.
 
Typically in our environments we use network firewalls to force that ingress into the network zones holding CF instances only happen through Enterprise load balancers and only then to specific components, e.g. gorouter, ssh-proxy, tcp router, etc., and use security groups to stop apps talking directly to other containers.  Though I imagine in the future we may deploy to environments with less strict network firewall setups.  In such an environment this configuration option would be very useful and we probably would use it without TCP routing support if we had such a situation.  But we don't currently.

Thanks for helping me through this email. :)

Sure, thanks for the extra feedback, and for hanging in there!

Best,
Eric 

Re: Proposal: Improving Security for HTTP Ingress to CFAR Application Containers

Mike Youngstrom
 

We would probably not deploy the improved http ingress until tcp and ssh are both working.  Our priority from the improvements in http ingress have been more on the reliable side and less on the security side.  We haven't run into any NATS mis-routing requests issues for a while and we do have TCP customers.  So, we would probably prefer to keep riding our current NATS good luck streak than disrupt our TCP customers.

Great, thanks for letting me know. Just to clarify, route integrity on its own (enabled via https://github.com/cloudfoundry/cf-deployment/blob/master/operations/experimental/enable-routing-integrity.yml) is intended primarily to improve HTTP routing reliability in the face of NATS and other component failures, and is still compatible with both CF SSH and TCP routing. This proposed more secure mode is an opt-in configuration that depends on but is separate from that "basic" route integrity.

Also, we on the Diego team think that we've finally finished ironing out a minor edge case around making sure incoming requests are handled correctly when app instances are being shutdown gracefully, so we expect to work with Release Integration in the next month or so to promote that route-integrity ops file to be a stable one and then later to be the default configuration in cf-deployment.

Oh man, after re-reading your email it now makes sense.  To be honest I didn't actually read the document you provided since it wasn't open for read to everyone so I just assumed what was in there instead.  Sorry.

Typically in our environments we use network firewalls to force that ingress into the network zones holding CF instances only happen through Enterprise load balancers and only then to specific components, e.g. gorouter, ssh-proxy, tcp router, etc., and use security groups to stop apps talking directly to other containers.  Though I imagine in the future we may deploy to environments with less strict network firewall setups.  In such an environment this configuration option would be very useful and we probably would use it without TCP routing support if we had such a situation.  But we don't currently.

Thanks for helping me through this email. :)

Mike

Re: Proposal: Improving Security for HTTP Ingress to CFAR Application Containers

Eric Malm <emalm@...>
 

We would probably not deploy the improved http ingress until tcp and ssh are both working.  Our priority from the improvements in http ingress have been more on the reliable side and less on the security side.  We haven't run into any NATS mis-routing requests issues for a while and we do have TCP customers.  So, we would probably prefer to keep riding our current NATS good luck streak than disrupt our TCP customers.

Great, thanks for letting me know. Just to clarify, route integrity on its own (enabled via https://github.com/cloudfoundry/cf-deployment/blob/master/operations/experimental/enable-routing-integrity.yml) is intended primarily to improve HTTP routing reliability in the face of NATS and other component failures, and is still compatible with both CF SSH and TCP routing. This proposed more secure mode is an opt-in configuration that depends on but is separate from that "basic" route integrity.

Also, we on the Diego team think that we've finally finished ironing out a minor edge case around making sure incoming requests are handled correctly when app instances are being shutdown gracefully, so we expect to work with Release Integration in the next month or so to promote that route-integrity ops file to be a stable one and then later to be the default configuration in cf-deployment.
 
That's perfect.  We don't use the port.

Some examples where cell ip address has come in handy:
* Mostly firewall debugging.  Our firewall situation is a mess.  Lots of manual work and issues to debug where sometimes knowing the specific cell ip address can help in debugging a problem.
* Occasionally customers want to do tcpdumps from a destination server.  The ip of the cell hosting the source app instance helps reduce the tcpdump scope.  Unfortunately, in tcpdump situations the CF operations team usually gets involved anyway to grab a tcpdump from the cell side since last time I checked we couldn't take tcpdumps from in a container.  So, these scenarios are usually not very self service anyway.

Hope that helps.

Certainly, thanks for the details!

Best,
Eric

Re: Proposal: Improving Security for HTTP Ingress to CFAR Application Containers

Mike Youngstrom
 

Got it.
 
Not quite: in the initial form of this more secured configuration, neither CF SSH nor TCP routing will work at all, as their gateway/front/edge routers would not have the network pathway into the container that they currently recognize. The Diego team is actually done at this point with the diego-release features required to enable that initial secured configuration, and will soon contribute an experimental operations file to opt into it to cf-deployment shortly and then focus on our approach to make CF SSH work again in this secure mode. We don't expect the current TCP routing tier ever to work with this configuration, though, as the Routing team is instead focused on the Istio integration effort as a longer-term plan to replace both the HTTP and TCP routing tiers. So I'm interested in knowing whether you'd be able to enable this extra security in any of your CF environments if either (a) CF SSH doesn't work as a result (short-term obstacle, resolved in a month or so) or (b) TCP routing doesn't work (longer-term obstacle, resolved only with Istio integration).

We would probably not deploy the improved http ingress until tcp and ssh are both working.  Our priority from the improvements in http ingress have been more on the reliable side and less on the security side.  We haven't run into any NATS mis-routing requests issues for a while and we do have TCP customers.  So, we would probably prefer to keep riding our current NATS good luck streak than disrupt our TCP customers.
 
Great, thanks for the feedback! The CF_INSTANCE_IP environment variable will continue to contain the cell VM's IP inside the container environment, and it'll likewise still be present in the response from the CC stats endpoint, so it sounds like those network-debugging activities would be unaffected. It'd of course be great to hear the specifics of how having that cell VM IP has been useful to your developers or to you as the platform operators in resolving those network-related issues, though.

That's perfect.  We don't use the port.

Some examples where cell ip address has come in handy:
* Mostly firewall debugging.  Our firewall situation is a mess.  Lots of manual work and issues to debug where sometimes knowing the specific cell ip address can help in debugging a problem.
* Occasionally customers want to do tcpdumps from a destination server.  The ip of the cell hosting the source app instance helps reduce the tcpdump scope.  Unfortunately, in tcpdump situations the CF operations team usually gets involved anyway to grab a tcpdump from the cell side since last time I checked we couldn't take tcpdumps from in a container.  So, these scenarios are usually not very self service anyway.

Hope that helps.

Mike

Re: Proposal: Improving Security for HTTP Ingress to CFAR Application Containers

Eric Malm <emalm@...>
 

Hey, Mike,

On Wed, Aug 15, 2018 at 10:36 AM, Mike Youngstrom <youngm@...> wrote:
- This secured configuration would initially be incompatible with CF SSH, and would likely never be compatible with TCP routing, as the Routing team has focused its efforts on replacing both the Gorouter and the TCP routers with Istio-configured gateway Envoy proxies. Would those incompatibilities prohibit you as platform operators from opting into this improved security in environments where you would particularly like to enforce it?

We would love to have greater route integrity and security for our HTTP clients.  If configuring this would provide those improvements to HTTP but not for TCP and SSH, we would still deploying it just to get the benefits for HTTP.  Is that what you're asking? 

Not quite: in the initial form of this more secured configuration, neither CF SSH nor TCP routing will work at all, as their gateway/front/edge routers would not have the network pathway into the container that they currently recognize. The Diego team is actually done at this point with the diego-release features required to enable that initial secured configuration, and will soon contribute an experimental operations file to opt into it to cf-deployment shortly and then focus on our approach to make CF SSH work again in this secure mode. We don't expect the current TCP routing tier ever to work with this configuration, though, as the Routing team is instead focused on the Istio integration effort as a longer-term plan to replace both the HTTP and TCP routing tiers. So I'm interested in knowing whether you'd be able to enable this extra security in any of your CF environments if either (a) CF SSH doesn't work as a result (short-term obstacle, resolved in a month or so) or (b) TCP routing doesn't work (longer-term obstacle, resolved only with Istio integration).
 
We don't use these values as part of an API or client library.  However, we do find it useful, on occasion, to know real network ip address of the cell an application is running on usually for firewall or other network debugging activities.  We don't ever use the port information.  I imagine we can find this information other ways but the CC api is currently the simplest way our application developers could self service find this data.  I don't think this is a big issue.  Just noting that my team (and perhaps others) will need to devise a different way to provide this information to app developers.

Great, thanks for the feedback! The CF_INSTANCE_IP environment variable will continue to contain the cell VM's IP inside the container environment, and it'll likewise still be present in the response from the CC stats endpoint, so it sounds like those network-debugging activities would be unaffected. It'd of course be great to hear the specifics of how having that cell VM IP has been useful to your developers or to you as the platform operators in resolving those network-related issues, though.

Thanks again,
Eric

PHP Buildpack Config Feedback

Daniel Mikusa
 

Hi All!

To anyone out there using the PHP buildpack.  We're trying to understand if what the buildpack does currently to configure Nginx + PHP-FPM so that it works within the defined memory limits works well for people and a variety of use cases.

If you have any thoughts on this topic, please pop over to the following Github issue and leave some comments. Example questions to consider: Are there problems with what we do now? Does the current config work for most cases (80%+)? Are there things people routinely change, customize or override with how the buildpack configures memory usage now? Are there any concrete use cases that people could share good or bad related to this topic? etc..


Thanks in advance for any feedback!

Dan

Re: Proposal: Improving Security for HTTP Ingress to CFAR Application Containers

Mike Youngstrom
 

- This secured configuration would initially be incompatible with CF SSH, and would likely never be compatible with TCP routing, as the Routing team has focused its efforts on replacing both the Gorouter and the TCP routers with Istio-configured gateway Envoy proxies. Would those incompatibilities prohibit you as platform operators from opting into this improved security in environments where you would particularly like to enforce it?

We would love to have greater route integrity and security for our HTTP clients.  If configuring this would provide those improvements to HTTP but not for TCP and SSH, we would still deploying it just to get the benefits for HTTP.  Is that what you're asking? 
 
- As part of enforcing this more secure configuration, the Diego cell components no longer map ports on their host VM directly to application ports inside the container. Each app instance currently receives the value of its host-side port in its CF_INSTANCE_PORT environment variable, though, and it is also exposed in the response from CC's app stats endpoint. For a variety of reasons (primarily the general availability of container networking and default app-security-group policies), we expect that these values are no longer useful for applications, and so we would like to deprecate them as part of this work and not to supply them in this optional, more secure configuration. Before we do so, we would like to know whether your applications, libraries, or other CF-related tools currently use this information and, if so, to what end.
 
We don't use these values as part of an API or client library.  However, we do find it useful, on occasion, to know real network ip address of the cell an application is running on usually for firewall or other network debugging activities.  We don't ever use the port information.  I imagine we can find this information other ways but the CC api is currently the simplest way our application developers could self service find this data.  I don't think this is a big issue.  Just noting that my team (and perhaps others) will need to devise a different way to provide this information to app developers.
 
Thanks,
Mike

Re: [cf-bosh] Incubation proposal: CF Containerization

vlad.iovanov@...
 

Thank you for the great news Marco!

 

Cheers,

Vlad

 

From: cf-dev@... <cf-dev@...> On Behalf Of Marco Voelz
Sent: Wednesday, August 15, 2018 12:10 PM
To: CF BOSH Mailing List <cf-bosh@...>
Cc: Discussions about Cloud Foundry projects and the system overall. <cf-dev@...>; cschum@...
Subject: Re: [cf-dev] [cf-bosh] Incubation proposal: CF Containerization

 

Hi everyone,

 

The BOSH PMC voted unanimously in favor of incubating the CF Containerization project. Welcome to Vlad and the team!

 

Warm regards

Marco

 


From: Voelz, Marco
Sent: Monday, August 13, 2018 1:52 PM
To: CF BOSH Mailing List
Cc: Discussions about Cloud Foundry projects and the system overall.
Subject: Re: [cf-bosh] Incubation proposal: CF Containerization

 

Hi everyone,

 

Thanks for the comments, discussions and suggestions everyone! The deadline for raising major concerns before we go on with the usual incubation process ended on August 10th. I don't see any ongoing discussions that would prevent us moving forward, so I'll call for a vote within the PMC and we will then proceed.

 

Warm regards

Marco

 


From: cf-bosh@... <cf-bosh@...> on behalf of Dmitriy Kalinin <dkalinin@...>
Sent: Friday, July 13, 2018 12:02:27 AM
To: CF BOSH Mailing List
Cc: Discussions about Cloud Foundry projects and the system overall.
Subject: Re: [cf-bosh] Incubation proposal: CF Containerization

 

Thank you for submitting this proposal. Let's shoot for collecting and resolving most of the comments in the next month by Aug 10th and voting at that time to incubate it in BOSH PMC.

 

On Tue, Jul 3, 2018 at 2:25 AM, Cornelius Schumacher <cschum@...> wrote:

Hi all,

We would like to propose the CF Containerization effort for incubation in the
BOSH PMC.

The full proposal can be found here:
https://docs.google.com/document/d/1_IvFf-cCR4_Hxg-L7Z_R51EKhZfBqlprrs5NgC2iO2w/edit

As a first step towards this, we are proposing the Fissile code base as a
starting point, with the goal of transforming it in the direction of the above
proposal. Fissile is a tool that allows developers to convert existing BOSH
releases to docker images and deploy them to Kubernetes. Fissile is currently
used in SUSE CAP (https://www.suse.com/products/cloud-application-platform)
and IBM Cloud Foundry Enterprise Environment (https://console.bluemix.net/
docs/cloud-foundry/
).

Fissile is fully open  source and can currently be found on GitHub at
https://github.com/SUSE/fissile

The project would follow a distributed committer model.

Project Lead: Vlad Iovanov
Initial Committers:
- Jan Dubois (SUSE)
- Mark Yen (SUSE)
- Mario Manno (SUSE)
- Enrique Encalada (IBM)
- Matthias Diester (IBM)
- Gong (Grace) Zhang (IBM)

SAP is also currently evaluating additional staffing.

We are looking forward to your questions and comments.

Best Regards,
Cornelius

--
Cornelius Schumacher <cschum@...>


 

Re: [cf-bosh] Incubation proposal: CF Containerization

Marco Voelz
 

Hi everyone,


The BOSH PMC voted unanimously in favor of incubating the CF Containerization project. Welcome to Vlad and the team!


Warm regards

Marco




From: Voelz, Marco
Sent: Monday, August 13, 2018 1:52 PM
To: CF BOSH Mailing List
Cc: Discussions about Cloud Foundry projects and the system overall.
Subject: Re: [cf-bosh] Incubation proposal: CF Containerization
 

Hi everyone,


Thanks for the comments, discussions and suggestions everyone! The deadline for raising major concerns before we go on with the usual incubation process ended on August 10th. I don't see any ongoing discussions that would prevent us moving forward, so I'll call for a vote within the PMC and we will then proceed.


Warm regards

Marco



From: cf-bosh@... <cf-bosh@...> on behalf of Dmitriy Kalinin <dkalinin@...>
Sent: Friday, July 13, 2018 12:02:27 AM
To: CF BOSH Mailing List
Cc: Discussions about Cloud Foundry projects and the system overall.
Subject: Re: [cf-bosh] Incubation proposal: CF Containerization
 
Thank you for submitting this proposal. Let's shoot for collecting and resolving most of the comments in the next month by Aug 10th and voting at that time to incubate it in BOSH PMC.

On Tue, Jul 3, 2018 at 2:25 AM, Cornelius Schumacher <cschum@...> wrote:
Hi all,

We would like to propose the CF Containerization effort for incubation in the
BOSH PMC.

The full proposal can be found here:
https://docs.google.com/document/d/1_IvFf-cCR4_Hxg-L7Z_R51EKhZfBqlprrs5NgC2iO2w/edit

As a first step towards this, we are proposing the Fissile code base as a
starting point, with the goal of transforming it in the direction of the above
proposal. Fissile is a tool that allows developers to convert existing BOSH
releases to docker images and deploy them to Kubernetes. Fissile is currently
used in SUSE CAP (https://www.suse.com/products/cloud-application-platform)
and IBM Cloud Foundry Enterprise Environment (https://console.bluemix.net/
docs/cloud-foundry/
).

Fissile is fully open  source and can currently be found on GitHub at
https://github.com/SUSE/fissile

The project would follow a distributed committer model.

Project Lead: Vlad Iovanov
Initial Committers:
- Jan Dubois (SUSE)
- Mark Yen (SUSE)
- Mario Manno (SUSE)
- Enrique Encalada (IBM)
- Matthias Diester (IBM)
- Gong (Grace) Zhang (IBM)

SAP is also currently evaluating additional staffing.

We are looking forward to your questions and comments.

Best Regards,
Cornelius

--
Cornelius Schumacher <cschum@...>




REMINDER: CAB call for August is Wednesday 08/15 @ 8a PST or 11a EST + TALKS AGENDA

Michael Maximilien
 

Quick reminder for the call on Wednesday and announcing two talks:
 
1. Using Istio Pilot and Envoy for Edge Routing in Cloud Foundry [1] by Shubha Anjur Tupil of Pivotal
2. Update on Project Eirini: Kubernetes backend for Cloud Foundry [2] by Julian Friedman of IBM
 
Full agenda and Zoom details in [0]. Zoom soon. Best,
 
------
dr.max
ibm ☁ 
silicon valley, ca
maximilien.org
 
 

----- Original message -----
From: Michael Maximilien/Almaden/IBM
To: cf-dev@...
Cc:
Subject: CAB call for August is Wednesday 08/15 @ 8a PST or 11a EST
Date: Wed, Aug 8, 2018 8:04 AM
 
 

FYI..,

 

Please remember to book your calendar to join the Zoom call [0] Wednesday August 15th at 8a Pacific for QAs, PMC highlights, and community presentations.

 

If you have a presentation about an OSS project related to CF or an update on a current project then please contact me ASAP. Reply direct to me or Slack.

 

Zoom soon. Best,

 
 
 

Re: [cf-bosh] Incubation proposal: CF Containerization

Marco Voelz
 

Hi everyone,


Thanks for the comments, discussions and suggestions everyone! The deadline for raising major concerns before we go on with the usual incubation process ended on August 10th. I don't see any ongoing discussions that would prevent us moving forward, so I'll call for a vote within the PMC and we will then proceed.


Warm regards

Marco



From: cf-bosh@... <cf-bosh@...> on behalf of Dmitriy Kalinin <dkalinin@...>
Sent: Friday, July 13, 2018 12:02:27 AM
To: CF BOSH Mailing List
Cc: Discussions about Cloud Foundry projects and the system overall.
Subject: Re: [cf-bosh] Incubation proposal: CF Containerization
 
Thank you for submitting this proposal. Let's shoot for collecting and resolving most of the comments in the next month by Aug 10th and voting at that time to incubate it in BOSH PMC.

On Tue, Jul 3, 2018 at 2:25 AM, Cornelius Schumacher <cschum@...> wrote:
Hi all,

We would like to propose the CF Containerization effort for incubation in the
BOSH PMC.

The full proposal can be found here:
https://docs.google.com/document/d/1_IvFf-cCR4_Hxg-L7Z_R51EKhZfBqlprrs5NgC2iO2w/edit

As a first step towards this, we are proposing the Fissile code base as a
starting point, with the goal of transforming it in the direction of the above
proposal. Fissile is a tool that allows developers to convert existing BOSH
releases to docker images and deploy them to Kubernetes. Fissile is currently
used in SUSE CAP (https://www.suse.com/products/cloud-application-platform)
and IBM Cloud Foundry Enterprise Environment (https://console.bluemix.net/
docs/cloud-foundry/
).

Fissile is fully open  source and can currently be found on GitHub at
https://github.com/SUSE/fissile

The project would follow a distributed committer model.

Project Lead: Vlad Iovanov
Initial Committers:
- Jan Dubois (SUSE)
- Mark Yen (SUSE)
- Mario Manno (SUSE)
- Enrique Encalada (IBM)
- Matthias Diester (IBM)
- Gong (Grace) Zhang (IBM)

SAP is also currently evaluating additional staffing.

We are looking forward to your questions and comments.

Best Regards,
Cornelius

--
Cornelius Schumacher <cschum@...>




Stratos User Survey

Richard Cox
 

Hi All!

The team here in Stratos have created a quick survey for users of, or people who would consider using, Stratos.

In case you're unfamiliar with Stratos, it's an Open Source Web-based UI (Console) for managing Cloud Foundry. For information, screen shots, deployment methods and more please pop over to https://github.com/cloudfoundry-incubator/stratos. If there are any more immediate questions please feel free to ask in our cf slack channel #stratos (https://cloudfoundry.slack.com/messages/C80EP4Y57/).

We can't promise t-shirts or Amazon vouchers for those who complete the survey, but can promise it will help shape the future of the project.

Survey Link - https://www.surveymonkey.com/r/2L8XWST

Thanks!

Richard

on behalf of the Stratos Team

CF CLI v6.38.0 Released Today

Abby Chau
 

Hey everyone,

The CF CLI team released cf CLI v6.38.0 today; please see release notes for full details. Highlights include: 

Changes to the `cf app app-name` Display
  • In late June, we sent out a survey (thank you to all who responded) to ask the community their opinion on changing the `cf app app-name` display.  Buoyed by your feedback, we decided to move forward with changing the `cf app` display such that it is backed by the v3 app api endpoint. Users on cc api 3.27 or higher will see the new app display.  

Multiple Buildpacks Support
  • Previously, pushing with multiple buildpacks, required you to use a combination of "v2" and "v3" commands. Now, if you are using CC API `3.25` or above, you can push with multiple buildpacks by either passing in multiple `-b` flags, or use the new `buildpacks` field in the manifest. 

Invocation Timeout Configuration
  • App devs on cc api `3.43.0` or higher can now use `v3-set-health-check` to set per invocation timeouts for http and port health checks  for individual health checks. 

Upgraded to Golang 1.10.3
  • This release bumps the CLI to use Golang `1.10.3`. 

Support for SOCKS5
  • We added SOCKS5 support for `cf v3-ssh` 

Other Enhancements
  • `v3-ssh` process type now defaults to `web` 
  • Support added for setting tags for user provided service instances 
  • Now a warning appears if you attempt to use deprecated properties and variable substitution 
  • Updated usage so now you can rename the `cf` binary use it with every command 
  • `cf events` now displays the Diego `cell_id` and `instance` guid in crash events 
  • Includes `cf service service-instance` table display improvements wherein the service instance information is now grouped separately from the binding information
  • `cf service service-instance` table display information for user provided services changed: `status` has been added to the table 
New Translations
  • New translations are included in this release. Big thanks to IBM who contributed updated translations of CLI output and help text. As the update came in mid-release and a number of message strings changed since, you may find some untranslated messages (in particular in the help pages).

Bug Fixes
  • the CLI now properly handles escaped commas in the `X-Cf-Warnings` header

Deprecations
  • the `buildpack` field in the manifest has been deprecated in favour of `buildpacks`.

Contributors:  An Yu, Sebastian Vidrio, Anande Gaitonde, Thomas Viehman, Alex Zhao, Abby Chau, Spencer Hawley, Renee Chu, Nick Guerette

Special Guests: Dies Koper (for helping us test SOCK5 support), SAPI London team (for tags support for user provided services and help updating the `cf service service-instance` table),  Dr. Max and the IBM team (for translation updates). 

Best,

Abby and the CLI team




CAB call for August is Wednesday 08/15 @ 8a PST or 11a EST

Michael Maximilien
 

FYI..,


Please remember to book your calendar to join the Zoom call [0] Wednesday August 15th at 8a Pacific for QAs, PMC highlights, and community presentations.


If you have a presentation about an OSS project related to CF or an update on a current project then please contact me ASAP. Reply direct to me or Slack.


Zoom soon. Best,



Re: routing-release 0.180.0

Shubha Anjur Tupil
 

I wanted to add a note to clarify now that some routing components use bpm. 

BPM needs to be colocated on the VM for the components that are using BPM (gorouter, routeing-api and route-registrar). If you are using cf-deployment, BPM is already colocated on the bosh deployed VMs, but if you are not using cf-deployment you would have to colocate the BPM job on the component VMs for gorouter, routing-api and route-registrar.

Regards, 
Shubha

On Mon, Aug 6, 2018 at 4:08 PM, Shubha Anjur Tupil <sanjurtupil@...> wrote:
Hi, 

We released routing-release 0.180.0 today. 

  • Operator can see a log message that indicates the number of tries when the Gorouter fails to connect to a backend in the gorouter.log details
  • Golang has been updated to 1.10.3 for all routing components details here and here
  • Release author can now specify an IP for the route-registrar using the job spec. If a host is not found in the job spec it will default to the IP of the VM the route-registrar is running on details

Using BPM for routing components

  • We are now using BPM for gorouter details
  • We are now using BPM for routing-api details
  • We are now using BPM for route_registrar details

Fixed Issues:

  • Fixed a issue where query parameters were not sent to the application when preceded by a //anywhere in the URL. Now when the request URL includes a //, the query parameters are sent to the application by the Gorouter details
  • Fixed an issue with symlinks to enable bosh-cli v5.x to work with routing-release details
  • PID files are being deleted when the Gorouter stops details

Regards, 
Shubha


Re: Version of UAA to upgrade to from version 4.11.0

Sree Tummidi
 

Please update to the latest line which is 4.19.2

Thanks,
Sree Tummidi
Sr. Manager, Product Management
Pivotal Cloud Foundry


On Tue, Aug 7, 2018 at 9:02 AM, <brian.sung@...> wrote:
Hi, we are currently using version UAA 4.11.0 and like to update to a more recent version. 

Looking at the Github repo, the latest release is 4.12.4, and I think this is what I should aim for.

But I also see 4.13.4, 4.14.0, and 4.19.2 releases.  Are these releases of feature branches under development?  Should I consider upgrading to one of these?

Regards,
Brian


Version of UAA to upgrade to from version 4.11.0

brian.sung@...
 

Hi, we are currently using version UAA 4.11.0 and like to update to a more recent version. 

Looking at the Github repo, the latest release is 4.12.4, and I think this is what I should aim for.

But I also see 4.13.4, 4.14.0, and 4.19.2 releases.  Are these releases of feature branches under development?  Should I consider upgrading to one of these?

Regards,
Brian

routing-release 0.180.0

Shubha Anjur Tupil
 

Hi, 

We released routing-release 0.180.0 today. 

  • Operator can see a log message that indicates the number of tries when the Gorouter fails to connect to a backend in the gorouter.log details
  • Golang has been updated to 1.10.3 for all routing components details here and here
  • Release author can now specify an IP for the route-registrar using the job spec. If a host is not found in the job spec it will default to the IP of the VM the route-registrar is running on details

Using BPM for routing components

  • We are now using BPM for gorouter details
  • We are now using BPM for routing-api details
  • We are now using BPM for route_registrar details

Fixed Issues:

  • Fixed a issue where query parameters were not sent to the application when preceded by a //anywhere in the URL. Now when the request URL includes a //, the query parameters are sent to the application by the Gorouter details
  • Fixed an issue with symlinks to enable bosh-cli v5.x to work with routing-release details
  • PID files are being deleted when the Gorouter stops details

Regards, 
Shubha