|
Re: Java Buildpack 4.0
Josh Long <starbuxman@...>
Congrats! This is awesome 👏
On Tue, Apr 25, 2017 at 02:09 Chip Childers <cchilders(a)cloudfoundry.org> wrote: What's really wonderful about this, IMO (as one example of many), is
|
|
|
|
Re: cflinuxfs2 (CF root FS) BOSH release rename
Eric Malm <emalm@...>
Hi, all,
toggle quoted messageShow quoted text
Related to this change in BOSH releases for the cflinuxfs2 rootfs, the manifest-generation script in Diego v1.14.0 now allows operators to use the "-r" flag to opt into the cflinuxfs2 release instead of the now-deprecated cflinuxfs-rootfs release, in order to ensure that they are able to switch to the new release successfully. Within a few weeks, that mode will become the default and only option for deploying the cflinuxfs2 release. Best, Eric, CF Diego PM
On Wed, Apr 19, 2017 at 11:09 AM, Stephen Levine <slevine(a)pivotal.io> wrote:
Hi All,
|
|
|
|
Issue with Routing Release v149-151
Abby Chau
Hi CF Devs,
It was recently discovered that routing release versions 149-151 includes a bug whereby increased latency and 502s can be observed. If you have deployed cf-release 256 or greater, you should change your gorouter job(s) to use version 0.147.0 of the cf-routing-release: releases: - name: cf version: 256 - name: routing version: 0.147.0 ... jobs: - name: router_z1(z2) ... templates: - name: gorouter release: routing ... The routing team is currently investigating this issue and we will provide a patch as soon as possible. Please feel free to reach out if you have any questions. Thanks, Abby
|
|
|
|
Re: Java Buildpack 4.0
Chip Childers <cchilders@...>
What's really wonderful about this, IMO (as one example of many), is seeing
how focused the CF technical community is on meaningful changes that are clearly the result of maturing users and well established feedback loops. Great stuff! On Mon, Apr 24, 2017 at 4:31 PM Dieu Cao <dcao(a)pivotal.io> wrote: Congrats to Ben and team!Chip Childers CTO, Cloud Foundry Foundation 1.267.250.0815
|
|
|
|
Re: Java Buildpack 4.0
Dieu Cao <dcao@...>
Congrats to Ben and team!
toggle quoted messageShow quoted text
-Dieu
On Mon, Apr 24, 2017 at 12:03 PM, Ben Hale <bhale(a)pivotal.io> wrote:
I’m pleased to announce the release of Java Buildpack 4.0. This release
|
|
|
|
Java Buildpack 4.0
Ben Hale <bhale@...>
I’m pleased to announce the release of Java Buildpack 4.0. This release has been a big effort for the team over the last couple of months and is the culmination of a major focus on improving how the JVM runs in a containerized environment. These improvements have resulted in an updated Memory Calculator and a new jvmkill Out of Memory agent. Please take a moment to read the release announcement[1] for more detail about how and why we made these changes.
The important thing to note about the Java Buildpack 4.0 release is that it is not 100% compatible with previous application configurations. Because the memory calculator now accounts for memory regions that were not accounted for earlier, applications that used to start (but would likely go OoM under a high load) will no longer start. It is possible to tune an application's memory configuration to run in small containers, but using the JVM defaults means that applications will not start in less than ~700M of memory. The CF default is 1G per container and applications will start and run nicely in that configuration. Because of this incompatibility, we’re releasing Java Buildpack 4.0 in parallel with Java Buildpack 3.16. Java Buildpack 3.x will continue to remain the default versions for a short time in order to gather feedback from users and allow a reasonable migration period. We intend for this parallel release system to go on for 3-6 months, but if there are significant difficulties, this can be changed. I highly encourage you to start trying Java Buildpack 4.0 during this period and giving us feedback in the GitHub issues[2]. Your feedback, with production applications, can help influence the ongoing behavior of the memory calculator and jvmkill agent. Finally I’d like to recognize Andrew Thorburn and Rafael de Albuquerque Ribeiro for their input into changes that should be made as well as Glyn Normington and Chris Frost for their efforts in making these changes a reality. -Ben Hale Cloud Foundry Java Experience [1]: https://www.cloudfoundry.org/just-released-java-buildpack-4-0/ [2]: https://github.com/cloudfoundry/java-buildpack/issues
|
|
|
|
Update: Locks & Service Discovery in CF Runtime
Luan Santos
Hi all,
We have been working on the milestones proposed before in order to lessen and remove our dependencies on Consul. Please see the updated Locks & Service Discovery in CF Runtime <https://docs.google.com/document/d/1zw2tQtpBqYol9usIuK_3VKmXHCMW6J9Dupzjr16J-TY/edit> document for more details and discussion. Thanks, Luan Software Engineer, Cloud Foundry @ Pivotal
|
|
|
|
Re: BOSH Windows is GA! (& ACTION REQUIRED: End-of-life for Diego MSI)
Dieu Cao <dcao@...>
So exciting!
Congrats to the BOSH Windows team! On Fri, Apr 21, 2017 at 11:31 AM, Chip Childers <cchilders(a)cloudfoundry.org> wrote: Amazing! Great work BOSH Windows team!
|
|
|
|
Re: BOSH Windows is GA! (& ACTION REQUIRED: End-of-life for Diego MSI)
By this we mean this is the technology that will put us on the path to full feature parity. We do, however, have a active track of work to scope and deliver persistence on Windows VMs. As far as full parity with Diego cells, we have a ways to go.
|
|
|
|
Re: BOSH Windows is GA! (& ACTION REQUIRED: End-of-life for Diego MSI)
Stockley, Jonathan <Jonathan.Stockley@...>
I note that your announcement says "This enables feature parity with BOSH-deployed Linux VMs”.
Does this mean it now supports persistent disk on windows? Or is this only “feature parity” wrt Diego cells? Thanks, Jo From: Colin Jackson <cojackson(a)pivotal.io<mailto:cojackson(a)pivotal.io>> Reply-To: "cf-dev(a)lists.cloudfoundry.org<mailto:cf-dev(a)lists.cloudfoundry.org>" <cf-dev(a)lists.cloudfoundry.org<mailto:cf-dev(a)lists.cloudfoundry.org>> Date: Friday, April 21, 2017 at 11:26 AM To: "cf-dev(a)lists.cloudfoundry.org<mailto:cf-dev(a)lists.cloudfoundry.org>" <cf-dev(a)lists.cloudfoundry.org<mailto:cf-dev(a)lists.cloudfoundry.org>> Subject: [cf-dev] BOSH Windows is GA! (& ACTION REQUIRED: End-of-life for Diego MSI) Hi cf-dev, This is a very exciting email to write! I'm extremely proud to announce that BOSH Windows, the new deployment mechanism for Windows cells, is now generally available! ACTION REQUIRED: Given that BOSH Windows is now ready to use and fully compatible with Diego, we intend to end-of-life the Diego MSI immediately. More details on this and an explanation for the accelerated timescale are at the bottom of this email. About BOSH Windows: At this point BOSH Windows has been successfully running 100% of the CI/CD workload for the BOSH Windows and Greenhouse teams for more than a month. The Diego team has also just finished an effort to integrate workers deployed via BOSH Windows in their CI/CD pipeline. In all cases it has held up remarkably well. Given this I'm happy to recommend people move over to BOSH Windows as soon as possible (the cf-deployment "windows-cell" ops file<https://github.com/cloudfoundry/cf-deployment/blob/master/operations/windows-cell.yml> should make this extremely simple -- but please note you MUST evacuate any cells that were deployed using the MSI as part of the transition or you WILL have problems in the future). As well as being based on open standards, BOSH Windows has some other significant benefits: * We've been able to simplify and modularise the BOSH code base as part of this transition. This enables feature parity with BOSH-deployed Linux VMs * BOSH Windows uses the exact same agent code as BOSH Linux for running jobs, so when you run jobs you know they run similarly on Windows as elsewhere I'm immensely proud of the teams that have worked together to deliver this. DIEGO MSI END OF LIFE: 19/5/2017 - ACTION REQUIRED: Now that BOSH Windows is ready we’re extremely keen to avoid maintaining two deployment methods for any longer than necessary, so we would like to move everyone to BOSH Windows immediately. Doing this on an accelerated timescale is particularly important because Diego intends to remove the global route-emitter in the near future. Due to the release of BOSH Windows, we have not implemented the local route-emitter for MSI cells, which would prevent apps on MSI cells from being routed to once the global route-emitter is removed. If anyone has huge problems moving off MSI cells now please reach out to me asap and we’ll see what we can do. Either way, we will no longer be supporting MSI cells or accepting pull requests from this point. Unless anyone has a strong reason otherwise (if so please do say!), we will end support for MSI cells on 19/5/2017. Thanks all very much, and again a huge thanks to the BOSH Windows team!
|
|
|
|
Re: BOSH Windows is GA! (& ACTION REQUIRED: End-of-life for Diego MSI)
Chip Childers <cchilders@...>
Amazing! Great work BOSH Windows team!
toggle quoted messageShow quoted text
On Fri, Apr 21, 2017 at 2:30 PM Colin Jackson <cojackson(a)pivotal.io> wrote:
Hi cf-dev, --
Chip Childers CTO, Cloud Foundry Foundation 1.267.250.0815
|
|
|
|
BOSH Windows is GA! (& ACTION REQUIRED: End-of-life for Diego MSI)
Colin Jackson <cojackson@...>
Hi cf-dev,
This is a very exciting email to write! I'm extremely proud to announce that BOSH Windows, the new deployment mechanism for Windows cells, is now generally available! ACTION REQUIRED: Given that BOSH Windows is now ready to use and fully compatible with Diego, we intend to end-of-life the Diego MSI immediately. More details on this and an explanation for the accelerated timescale are at the bottom of this email. About BOSH Windows: At this point BOSH Windows has been successfully running 100% of the CI/CD workload for the BOSH Windows and Greenhouse teams for more than a month. The Diego team has also just finished an effort to integrate workers deployed via BOSH Windows in their CI/CD pipeline. In all cases it has held up remarkably well. Given this I'm happy to recommend people move over to BOSH Windows as soon as possible (the cf-deployment "windows-cell" ops file <https://github.com/cloudfoundry/cf-deployment/blob/master/operations/windows-cell.yml> should make this extremely simple -- but please note you MUST evacuate any cells that were deployed using the MSI as part of the transition or you WILL have problems in the future). As well as being based on open standards, BOSH Windows has some other significant benefits: - We've been able to simplify and modularise the BOSH code base as part of this transition. This enables feature parity with BOSH-deployed Linux VMs - BOSH Windows uses the exact same agent code as BOSH Linux for running jobs, so when you run jobs you know they run similarly on Windows as elsewhere I'm immensely proud of the teams that have worked together to deliver this. DIEGO MSI END OF LIFE: 19/5/2017 - ACTION REQUIRED: Now that BOSH Windows is ready we’re extremely keen to avoid maintaining two deployment methods for any longer than necessary, so we would like to move everyone to BOSH Windows immediately. Doing this on an accelerated timescale is particularly important because Diego intends to remove the global route-emitter in the near future. Due to the release of BOSH Windows, we have not implemented the local route-emitter for MSI cells, which would prevent apps on MSI cells from being routed to once the global route-emitter is removed. If anyone has huge problems moving off MSI cells now please reach out to me asap and we’ll see what we can do. Either way, we will no longer be supporting MSI cells or accepting pull requests from this point. Unless anyone has a strong reason otherwise (if so please do say!), we will end support for MSI cells on 19/5/2017. Thanks all very much, and again a huge thanks to the BOSH Windows team!
|
|
|
|
Re: [Proposal] Making the Service Broker API less CF-specific
Matt McNeeney
Hi Gwenn,
We agree that this change is important. However, the Open Service Broker API Change Policy [1] specifies the following: New fields may be added to existing request/response messages. These fields must be optional and should be ignored by clients and servers that do not understand them. Service brokers that want to be accessed from multiple platforms can check for the presence of the context parameter, and fall back to using the existing required fields if necessary. In a future version of the spec, we may consider making the context parameter a required field. Many thanks, Matt - [1] https://github.com/openservicebrokerapi/servicebroker/blob/master/spec.md#change-policy On Fri, Apr 21, 2017 at 3:37 AM Gwenn Etourneau <getourneau(a)pivotal.io> wrote: HI,
|
|
|
|
Re: [Proposal] Making the Service Broker API less CF-specific
Gwenn Etourneau
HI,
I think this change is important and need to be done, I like the new context parameters but not sure about the `optional`, I think it's important to which env. / platform we are talking too. Thanks, On Thu, Apr 20, 2017 at 7:38 PM, Matthew McNeeney <mmcneeney(a)pivotal.io> wrote: The Open Service Broker API [1] working group have created a proposal [2]
|
|
|
|
[Proposal] Making the Service Broker API less CF-specific
Matt McNeeney
The Open Service Broker API [1] working group have created a proposal [2]
to make the Service Broker API less CF-specific. The proposed changes will help grow the services community by allowing service broker authors to create and deliver services to a range of cloud-native platforms (including Cloud Foundry, OpenShift and Kubernetes). The key parts of the proposal are: - Platforms can *optionally* send a new *context *parameter to service brokers containing platform-specific information (a Cloud Foundry platform would send the platform name, the organization GUID and the space GUID). - The existing *required *CF-specific parameters, *organization_guid *and *space_guid *will be marked as deprecated to be removed from the specification in a future version. We'd love to get some feedback from the community on this proposal. Many thanks, Matt - [1] https://www.openservicebrokerapi.org/ [2] https://github.com/openservicebrokerapi/servicebroker/issues/115
|
|
|
|
CVE-2017-4973: Privilege Escalation in UAA
Molly Crowther
CF Devs,
Please see information for the following high UAA CVE. This issue was fixed in the same releases as CVE-2017-4972 (the blind SQL injection) so if you already have plans to upgrade, you don't need to take any further action. https://www.cloudfoundry.org/cve-2017-4973/ Please let me know if you have any other questions or concerns. Thanks, Molly Crowther Cloud Foundry Foundation Security Team
|
|
|
|
NOTICE: Removal of old .NET Core frameworks and SDKs from the .NET Core buildpack after 2017-05-19
Stephen Levine
Hi All,
To reduce the size of the .NET Core buildpack and discourage the use of unsupported versions of .NET Core, we will be removing the following SDK versions: 1.0.0-preview2-1-003177 As well as the following framework versions: 1.0.0 1.0.1 This change will apply to the first .NET Core buildpack release after May 19, 2017. Moving forward, we will only provide the latest two patch versions of each supported minor version of the .NET Core framework (ex. 1.1.0 and 1.1.1). We will continue to provide the latest two releases of the SDK. SDKs supporting the project.json format will eventually be retired after a separate 30-day notice. Thanks, Stephen CF Buildpacks PM
|
|
|
|
Re: cflinuxfs2 (CF root FS) BOSH release rename
Stephen Levine
Hi All,
toggle quoted messageShow quoted text
Quick follow-up to this. To ease the transition, we're going to continue updating the current cflinuxfs2 BOSH release[1] until May 19, 2017. After May 19, 2017, only the new BOSH release[2] will be updated. Please make sure to update the release name in your deployment manifest ("cflinuxfs2-rootfs" -> "cflinuxfs2") when you switch to the new release. [1] https://github.com/cloudfoundry/cflinuxfs2-rootfs-release [2] https://github.com/cloudfoundry/cflinuxfs2-release Thanks, Stephen (CF Buildpacks PM)
On Wed, Mar 29, 2017 at 2:46 PM, Stephen Levine <slevine(a)pivotal.io> wrote:
Hi All,
|
|
|
|
CVE-2017-4972: Blind SQL Injection in UAA
Molly Crowther
CF devs,
Please see the following public link for information about a high CVE in UAA. https://www.cloudfoundry.org/cve-2017-4972/ Friendly reminder that you can subscribe to new Cloud Foundry security issues at: https://www.cloudfoundry.org/category/security/feed/ Please let me know if you have any questions or concerns. Thanks, Molly Crowther Cloud Foundry Foundation Security Team
|
|
|
|
[IMPORTANT] Reminder - EOL for Legacy DEA Backend on May 22, 2017
Dieu Cao <dcao@...>
Hello All,
I'm excited to send this email as a reminder that EOL for the Legacy DEA Backend is May 22, 2017, just over a month away, finally closing out a great chapter for Cloud Foundry. You can find the previous notice of this here [1] and here [2]. Documentation on how to migrate to Diego can be found here [3]. The EOL phase for the DEAs out will entail: (1) moving the DEAs to the Cloud Foundry Attic (meaning the DEAs will no longer be supported, no longer be patched for any reason, and no longer accept any contributions), (2) removing distribution of the DEAs from cf-release, (3) shutting down all CI pipelines related to the DEAs, (4) removing all code paths and technical debt in the Cloud Controller associated with running Cloud Foundry on multiple backends. Additionally, the Runtime OG team's support efforts have not required much in the last several months, and the team is standing down for now. Thanks! Dieu Cao CF Runtime PMC Lead [1] https://lists.cloudfoundry.org/archives/list/cf-dev(a)lists.cloudfoundry.org/thread/PFXSJMKSQ6UNR2I5U5Q2H2QTXTCAEIJR/#PFXSJMKSQ6UNR2I5U5Q2H2QTXTCAEIJR [2] https://lists.cloudfoundry.org/archives/list/cf-dev(a)lists.cloudfoundry.org/message/GMXXJTTM2Q6SIRGVXSQH4TPLHTVHKNNG/ [3] https://docs.cloudfoundry.org/running/apps-enable-diego.html
|
|
|