Date   

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
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!

-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
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

--
Chip Childers
CTO, Cloud Foundry Foundation
1.267.250.0815


Re: cflinuxfs2 (CF root FS) BOSH release rename

Eric Malm <emalm@...>
 

Hi, all,

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,

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,

The BOSH release for the Cloud Foundry root filesystem (cflinuxfs2) has
moved from:
https://github.com/cloudfoundry/cflinuxfs2-rootfs-release
To:
https://github.com/cloudfoundry/cflinuxfs2-release

This means that future releases will no longer be available at:
http://bosh.io/releases/github.com/cloudfoundry/cflinuxfs2-rootfs-release
And instead will be available at:
http://bosh.io/releases/github.com/cloudfoundry/cflinuxfs2-release

Furthermore, the cflinuxfs2 source repository has moved from:
https://github.com/cloudfoundry/stacks
To:
https://github.com/cloudfoundry/cflinuxfs2

Future versions of cflinuxfs2 will be synced with cflinuxfs2-release to
reduce the current confusion caused by having two separates versions that
are close to each other.

Thanks,
Stephen
(CF Buildpacks PM)


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!

-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
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

--
Chip Childers
CTO, Cloud Foundry Foundation
1.267.250.0815


Re: Java Buildpack 4.0

Dieu Cao <dcao@...>
 

Congrats to Ben and team!

-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
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


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!

On Fri, Apr 21, 2017 at 2:30 PM Colin Jackson <cojackson(a)pivotal.io>
wrote:

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!
--
Chip Childers
CTO, Cloud Foundry Foundation
1.267.250.0815 <(267)%20250-0815>


Re: BOSH Windows is GA! (& ACTION REQUIRED: End-of-life for Diego MSI)

A William Martin
 

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!

On Fri, Apr 21, 2017 at 2:30 PM Colin Jackson <cojackson(a)pivotal.io> wrote:

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!
--
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,

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]
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


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]
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


[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,

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,

The BOSH release for the Cloud Foundry root filesystem (cflinuxfs2) has
moved from:
https://github.com/cloudfoundry/cflinuxfs2-rootfs-release
To:
https://github.com/cloudfoundry/cflinuxfs2-release

This means that future releases will no longer be available at:
http://bosh.io/releases/github.com/cloudfoundry/cflinuxfs2-rootfs-release
And instead will be available at:
http://bosh.io/releases/github.com/cloudfoundry/cflinuxfs2-release

Furthermore, the cflinuxfs2 source repository has moved from:
https://github.com/cloudfoundry/stacks
To:
https://github.com/cloudfoundry/cflinuxfs2

Future versions of cflinuxfs2 will be synced with cflinuxfs2-release to
reduce the current confusion caused by having two separates versions that
are close to each other.

Thanks,
Stephen
(CF Buildpacks PM)


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