Date   

NOTICE: Undocumented support for io.js will be removed from the Node.js buildpack after 2017-06-09

Stephen Levine
 

Hi All,

The Node.js buildpack has undocumented support for downloading unmaintained
versions of io.js. This support will be removed after June 9, 2017. If you
happen to rely on this undocumented behavior, please switch to a supported
version of Node.js before that date. For more information, refer to the
buildpack documentation: http://docs.cloudfoundry.org/buildpacks/node/

Thanks,
Stephen Levine
CF Buildpacks PM


NOTICE: Deprecated versions of NGINX will be removed from the PHP buildpack after 2017-06-09

Stephen Levine
 

Hi All,

NGINX versions 1.10.3 and 1.11.13 are no longer supported upstream and will
be removed from the PHP buildpack after June 9, 2017. NGINX versions 1.12.x
and 1.13.x are already included in the latest release of the buildpack. For
more information, refer to the buildpack documentation:
http://docs.cloudfoundry.org/buildpacks/php/

Thanks,
Stephen Levine
CF Buildpacks PM


NOTICE: Version of NGINX in the Staticfile buildpack will change to 1.13.x after 2017-06-09

Stephen Levine
 

Hi All,

The version of NGINX in the Staticfile buildpack will change from the
latest 1.11.x version (currently 1.11.13) to the latest 1.13.x version
(currently 1.13.0) in the first release of the Staticfile buildpack after
June 9, 2017. For more information, refer to the buildpack documentation:
http://docs.cloudfoundry.org/buildpacks/staticfile/

Thanks,
Stephen Levine
CF Buildpacks PM


Re: Issues on upgrading UAA 3.6.0 to 3.12.0?

Filip Hanik
 

We recommend that you upgrade to 3.16.0 to make sure you get all security
fixes included.

The UAA you are upgrading to supports multiple keys.
Here is an example

https://github.com/cloudfoundry/uaa/blob/develop/uaa/src/test/resources/test/bootstrap/all-properties-set.yml#L72-L82

add both your new and old keys into the configuration. Then set the
activeKeyId to be the new key.

The old key will be used to verify existing tokens only. The new key will
be used to sign new tokens.
When you believe the time is right, you can remove the old key from the
configuration. any tokens still signed with the old key will then be
considered invalid.

Filip

On Mon, May 8, 2017 at 4:23 PM, Sam Leong <sam.leong(a)quicken.com> wrote:

Hi,

We've been running UAA 3.6 on production and need to upgrade to 3.12. One
requirement is that we will need to retain the validity of the token that
was issued by UAA 3.6 after the upgrade.

We used the default key for token signing in 3.6, in the upgrade we will
use a new key, so I like to know the way how the client be able to verify
the signature of the old valid tokens while the new tokens will be signed
by a new key after upgrade to 3.12?

Thanks, Sam


Issues on upgrading UAA 3.6.0 to 3.12.0?

Sam Leong
 

Hi,

We've been running UAA 3.6 on production and need to upgrade to 3.12. One requirement is that we will need to retain the validity of the token that was issued by UAA 3.6 after the upgrade.

We used the default key for token signing in 3.6, in the upgrade we will use a new key, so I like to know the way how the client be able to verify the signature of the old valid tokens while the new tokens will be signed by a new key after upgrade to 3.12?

Thanks, Sam


Re: Proposal for named service bindings

Mike Youngstrom
 

This looks great! Thanks Zach.

Mike

On Mon, May 8, 2017 at 12:05 PM, Zach Robinson <zrobinson(a)pivotal.io> wrote:

Hey all,

Here's the implementation proposal: https://docs.google.com/
document/d/1PjcEx5_w383AKI9WyJHI4gGDkhIS9mhqwUK5nvmOWUc/edit?usp=sharing

And here's the tracker epic: https://www.pivotaltracker.
com/epic/show/3472063

-Zach


Re: Proposal for named service bindings

Zach Robinson
 


Get RTT with MessageInterceptor

Felipe Roca Blaya <felipe.rocablaya13@...>
 

Hi,
I'm working with eclipse-leshan and I found troubles trying to retrieve the rtt between a Coap request and response.
I've created a new MessageInterceptor but I've saw that CoapEndpoint calculates and sets the RTT value after notify the different MessageInterceptor.
This seems strange for me because the RTT by definition excludes the overhead in the requester. My first reaction has been if you change the order it should works. But I'm sure this has been made for a good reason. So if someone could explain it to me or tell me some other way to retrieve the rtt I'll be grateful.
Thanks in advance


Re: CF Diego Apps logging on stdout

Prashant Ghorpade
 

Hi,

Any updates? I am not getting application staging logs for CF v259 as well. Same observations for CF v255/256 and 257.

Thanks,
Prashant

From: Prashant Ghorpade
Sent: Wednesday, April 26, 2017 3:14 PM
To: Discussions about Cloud Foundry projects and the system overall. <cf-dev(a)lists.cloudfoundry.org>
Subject: RE: [cf-dev] Re: CF Diego Apps logging on stdout

Hi,

Yes you right! I really mean to say application staging logs and following are sample output which I am not able to see for CF v255/256/257 for Diego as a default backend. It’s working for me for CF v254.

----------------------------------------------------------------------------------------------------------------------------
2017-04-24T13:00:31.67-0400 [STG/0] OUT Successfully created container
2017-04-24T13:00:31.67-0400 [STG/0] OUT Downloading app package...
2017-04-24T13:00:33.68-0400 [STG/0] OUT Staging...
2017-04-24T13:00:33.68-0400 [STG/0] OUT Downloaded app package (43.8M)
2017-04-24T13:00:35.32-0400 [STG/0] OUT -----> Java Buildpack Version: v3.14 (offline) | https://github.com/cloudfoundry/java-buildpack.git#d5d58c6
2017-04-24T13:00:35.51-0400 [STG/0] OUT -----> Downloading Open Jdk JRE 1.8.0_121 from https://java-buildpack.cloudfoundry.org/openjdk/trusty/x86_64/openjdk-1.8.0_121.tar.gz (found in cache)
2017-04-24T13:00:36.84-0400 [STG/0] OUT Expanding Open Jdk JRE to .java-buildpack/open_jdk_jre (1.3s)
2017-04-24T13:00:36.84-0400 [STG/0] OUT -----> Downloading Open JDK Like Memory Calculator 2.0.2_RELEASE from https://java-buildpack.cloudfoundry.org/memory-calculator/trusty/x86_64/memory-calculator-2.0.2_RELEASE.tar.gz (found in cache)
2017-04-24T13:00:36.87-0400 [STG/0] OUT Memory Settings: -Xms1363148K -XX:MetaspaceSize=209715K -Xmx1363148K -XX:MaxMetaspaceSize=209715K -Xss699K
2017-04-24T13:00:36.87-0400 [STG/0] OUT -----> Downloading Container Certificate Trust Store 2.0.0_RELEASE from https://java-buildpack.cloudfoundry.org/container-certificate-trust-store/container-certificate-trust-store-2.0.0_RELEASE.jar (found in cache)
2017-04-24T13:00:37.24-0400 [STG/0] OUT Adding certificates to .java-buildpack/container_certificate_trust_store/truststore.jks (0.3s)
2017-04-24T13:00:37.24-0400 [STG/0] OUT -----> Downloading Spring Auto Reconfiguration 1.10.0_RELEASE from https://java-buildpack.cloudfoundry.org/auto-reconfiguration/auto-reconfiguration-1.10.0_RELEASE.jar (found in cache)
2017-04-24T13:00:48.25-0400 [STG/0] OUT Uploading droplet...
2017-04-24T13:00:48.25-0400 [STG/0] OUT Exit status 0
2017-04-24T13:00:48.25-0400 [STG/0] OUT Staging complete
2017-04-24T13:00:48.25-0400 [STG/0] OUT Uploading droplet, build artifacts cache...
2017-04-24T13:00:48.25-0400 [STG/0] OUT Uploading build artifacts cache...
2017-04-24T13:00:48.32-0400 [STG/0] OUT Uploaded build artifacts cache (109B)
2017-04-24T13:00:53.13-0400 [STG/0] OUT Uploaded droplet (89.1M)
2017-04-24T13:00:53.16-0400 [STG/0] OUT Uploading complete
2017-04-24T13:00:53.19-0400 [STG/0] OUT Destroying container
2017-04-24T13:00:53.49-0400 [CELL/0] OUT Creating container
2017-04-24T13:00:54.04-0400 [CELL/0] OUT Successfully created container
2017-04-24T13:00:54.09-0400 [STG/0] OUT Successfully destroyed container
2017-04-24T13:00:57.49-0400 [CELL/0] OUT Starting health monitoring of container
----------------------------------------------------------------------------------------------------------------------------
Thanks,
Prashant

From: ronak banka [mailto:ronakbanka.cse(a)gmail.com]
Sent: Wednesday, April 26, 2017 2:54 PM
To: Discussions about Cloud Foundry projects and the system overall. <cf-dev(a)lists.cloudfoundry.org<mailto:cf-dev(a)lists.cloudfoundry.org>>
Subject: [cf-dev] Re: CF Diego Apps logging on stdout

Hello,

By "application startup logs", do you mean application staging logs??

Can you paste log lines which are missing?

Thanks
Ronak

On Wed, Apr 26, 2017 at 14:25 Prashant Ghorpade <prashant.ghorpade(a)sas.com<mailto:prashant.ghorpade(a)sas.com>> wrote:
Hello,

I have seen some changes related to “cf logs app_name” command from CF v255 onwards on Openstack using Diego as a default container. CF v254 is working for me.

I am not getting application startup logs after running “cf logs app_name” command on stdout.

I am able to see logs when I try to access the sample application from browser but I am more interested in application startup logs.

Kindly let me know in case any additional details are required for the same.

Thanks,
Prashant


Re: Update: Locks & Service Discovery in CF Runtime

Benjamin Gandon
 

The road off Consul looks like it is long but necessary. Consul looks like a spof in CF, when you know how much the platform needs it, and when you read that sometimes plain upgrades break it badly.

Plus, the myriad of logic in the confab wrapper around Consul is an example of how much Consul is hard to manage and keep up properly.

Don't forget that recently PCF benefitted a CRE (SRE-tye) shared review from Google.
Don't forget that we have converging evidences that let us think Google stays away from etcd for their hosted K8s on GCP.

My guess is that internally, Google SREs might have evidences at scale that systems like etcd or consul should be avoided, and this understanding is being ported to CF through the CRE program.


Also, moving away from Consul is like choosing to build Diego instead of building on top of K8s. Controlling the agenda is important. I mean not being forced to run after a project that has its own. Ensuring which value is put into the product, and that this value is consistent with the rest of the platform, is also important.


These are just thoughts. I would love to read more precise info about the Why, for this "away-from-Consul" move. Guys?

Le 26 avr. 2017 à 18:48, Voelz, Marco <marco.voelz(a)sap.com> a écrit :

Dear Luan,

Maybe that's a stupid question which has already been answered, but doesn't consul release 0.8 address most of the criticism from the CF community?

I see now big efforts on all sides (CF and BOSH teams) invested in building our own solution to a problem which seems to be pretty generic.

Do we think that's something we should spend engineering resources on and that others (e.g. HashiCorp in this case) cannot solve the problem to se be our needs? At least to me it seems that they try to move in the right direction.

Maybe my perspective on this is just too generic and I'm not deep enough in the technical details.

What do you think?

Thanks and warm regards
Marco



On 24. Apr 2017, at 20:35, Luan Santos <lsantos(a)pivotal.io> wrote:

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 document for more details and discussion.

Thanks,

Luan
Software Engineer, Cloud Foundry @ Pivotal


Re: Inconsistency in retrieval of service plans

Benjamin Gandon
 

Did you look at the doc on api.cloudfoundry.org about any ordering contract for those API calls?

Le 5 mai 2017 à 12:16, Roopali Sharma <roopali1193(a)gmail.com> a écrit :

Hello All,



While listing service plans for any given service , if we use /v2/service_plans?q=<service_guid> , the plans appear in the same order as defined in the service catalog. However, call to /v2/services/<service_guid>?inline-relations-depth=1 returns the service plans in some random ordering which does not respect the order of catalog. The ordering however does not change with every call and also does not seem to take into account unique plan_id or the plan_name itself. Hence , it is unclear as to what sorting paradigm is in use.



Can someone comment if this is a bug with controller API or if not, some clarity regarding the ranking order.



With regards,

Roopali Sharma


Re: Questions on credential rotation

Krannich, Bernd <bernd.krannich@...>
 

Hey Dan,

Thank you very much for your reply!

I think there is overwhelming agreement that all components should allow credential rotation without downtime, where possible, so I would expect it is on many teams' radar. If not, I am happy to start conversations once we get to that phase of our project.
Sound great. We are actively following the developments in bosh-deployment and cf-deployment also with respect to credhub integration. It would be great if you could send an update via this list once you have reached the next phase here.

Thanks,
Bernd

P.S.: > We view our project as being part of the 'rotate' component of Justin's vision. Repave is focused on recreating instances to a known-good state, which is something outside of our area of concern.
Yes, I meant to write:
CredHub [4] seems to be geared in the direction of “rotate”.
Repave is of course largely based on regular stemcell updates using BOSH.

P.P.S.: For the people reading through this thread, I corrected my footnotes which unfortunately pointed to the head of the master branch earlier:
[2] https://github.com/cloudfoundry/cf-release/blob/01ccfbbb01bb8824594f67529a4c325214507f08/templates/cf.yml#L640
[3] https://github.com/cloudfoundry/cf-release/blob/01ccfbbb01bb8824594f67529a4c325214507f08/templates/cf.yml#L872

From: Dan Jahner <djahner(a)pivotal.io>
Reply-To: "Discussions about Cloud Foundry projects and the system overall." <cf-dev(a)lists.cloudfoundry.org>
Date: Thursday, 4. May 2017 at 22:22
To: "Discussions about Cloud Foundry projects and the system overall." <cf-dev(a)lists.cloudfoundry.org>
Subject: [cf-dev] Re: Questions on credential rotation

Hey Bernd,

I am the product manager of CredHub. We view our project as being part of the 'rotate' component of Justin's vision. Repave is focused on recreating instances to a known-good state, which is something outside of our area of concern.

The current roadmap for CredHub is focused on pulling credentials into our system; specifically BOSH deployment and service credentials, later application credentials. Once we have a solid footing for storing and managing access to these credentials, we plan to explore what possibilities exist for reducing the friction of credential rotation.

Although I haven't spent a long time investigating, I would agree with your characterization of the 3 classes of credentials. I think there is overwhelming agreement that all components should allow credential rotation without downtime, where possible, so I would expect it is on many teams' radar. If not, I am happy to start conversations once we get to that phase of our project.

Thanks,
Dan
On Thu, May 4, 2017 at 6:32 AM Krannich, Bernd <bernd.krannich(a)sap.com<mailto:bernd.krannich(a)sap.com>> wrote:
Hello all,

We love Justin Smith’s approach of “Rotate, Repair, Repave” [1] when it comes to security. Looking at how the “Rotate” aspect is handled in Cloud Foundry and other BOSH deployments today, we think there’s currently three classes of credentials:


1. Credentials that can be rotated by updating them and doing a `bosh deploy` with zero downtime

2. Credentials that can be rotated by updating them and doing a `bosh deploy` involving a downtime [2]

3. Credentials that cannot be rotated easily at all [3]

A couple of questions here:


• Is the above summary accurate?

• For updates involving a downtime, the only naïve solution I could come up with is to support two sets of credentials during the transition. Are there any more strategies?

• Are there any efforts to turn credentials falling under #2 and #3 into ones that can be updated without downtime?

• CredHub [4] seems to be geared in the direction of “repave”. Is this the case and does this maybe even support work on the previous bullet?

Thanks in advance,
Bernd

[1] https://www.youtube.com/watch?v=NUXpz0Dni50
[2] https://github.com/cloudfoundry/cf-release/blob/master/templates/cf.yml#L634 might be a good example
[3] https://github.com/cloudfoundry/cf-release/blob/master/templates/cf.yml#L865 might be a good example
[4] https://github.com/cloudfoundry-incubator/credhub


Bernd Krannich
SAP Cloud Platform
SAP SE
Dietmar-Hopp-Allee 16, 69190 Walldorf, Germany

E bernd.krannich(a)sap.com<mailto:bernd.krannich(a)sap.com>

Pflichtangaben/Mandatory Disclosure Statement: www.sap.com/impressum<http://www.sap.com/company/legal/impressum.epx/>

Diese E-Mail kann Betriebs- oder Geschäftsgeheimnisse oder sonstige vertrauliche Informationen enthalten. Sollten Sie diese E-Mail irrtümlich erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts, eine Vervielfältigung oder Weitergabe der E-Mail ausdrücklich untersagt. Bitte benachrichtigen Sie uns und vernichten Sie die empfangene E-Mail. Vielen Dank.

This e-mail may contain trade secrets or privileged, undisclosed, or otherwise confidential information. If you have received this e-mail in error, you are hereby notified that any review, copying, or distribution of it is strictly prohibited. Please inform us immediately and destroy the original transmittal. Thank you for your cooperation.


Spring Cloud data flow

Mohan Radhakrishnan
 

Where can look at some instructions to deploy Spring data flow and Apache Spark on one pipeline and a ML tool like H2O or MapR on the other ? I am trying to simulate stream data processing by analyzing data that originates from Spark,flows through Spring Cloud data flow and reaches the ML tool. At this time I would to try this setup. I don't own any licenses.

Thanks,
Mohan


Upcoming changes to cf-release manifests

David Sabeti
 

Hi cf-dev!

As you may have heard, May 22 marks the last day of DEA support. In advance
of that, the manifest templates in CF 260 will start to choose Diego as the
default backend for running apps. You can still set
`default_to_diego_backend` to false if you would really like to run the
DEAs, but making Diego the default in the manifest templates is a long
overdue change.

Feel free to reach out if you have any questions!

David Sabeti
CF Release Integration PM


Reliability issue with Diego v1.15.1; please use v1.15.0 instead

Eric Malm <emalm@...>
 

Hi, all,

Please do not use v1.15.1 of the Diego BOSH release. The Diego team instead
recommends using v1.15.0, or the forthcoming next final release (most
likely named v1.15.2).

The only change between v1.15.0 and v1.15.1 is an upgrade of the Golang
version from v1.7.4 to v1.8.1. After deploying this release in a large
environment, we observed that the Diego auctioneers on v1.15.1 failed to
make successful requests to retrieve the Diego cells' latest state at the
start of an auction, and typically failed seemingly at random on a
substantial proportion of them. While we did not observe any obvious
significant impact to application developers or application traffic because
of these failures, we are still concerned about them, and do not feel
comfortable recommending operation of a system that exhibits them.

Rolling back to Diego v1.15.0 in the same environment caused the
auctioneers to resume functioning normally, so we're fairly confident that
this issue is caused by the change to the version of Golang in the release.
We'll be reverting that version to v1.7.4 for the next Diego final release,
which we hope to have available as soon as possible, and will then
investigate these failures and ensure we have a resolution for them in
place before re-advancing to the v1.8 Golang line in the release.

Apologies for any inconvenience this issue may have caused, and please let
me or the rest of the Diego team know if you have further questions.

Best,
Eric, CF Diego PM


Inconsistency in retrieval of service plans

Roopali Sharma <roopali1193@...>
 

Hello All,



While listing service plans for any given service , if we use
/v2/service_plans?q=<service_guid> , the plans appear in the same order as
defined in the service catalog. However, call to
/v2/services/<service_guid>?inline-relations-depth=1 returns the service
plans in some random ordering which does not respect the order of catalog.
The ordering however does not change with every call and also does not seem
to take into account unique plan_id or the plan_name itself. Hence , it is
unclear as to what sorting paradigm is in use.



Can someone comment if this is a bug with controller API or if not, some
clarity regarding the ranking order.



With regards,

Roopali Sharma


Re: Concourse-Up: Deploy Concourse CI in a Single Command

Tim Lawrence <tim.lawrence1984@...>
 

on the beach or on the bench?

I find the glare on my screen difficult on the beach :-)

Good work!

On Thu, May 4, 2017 at 2:19 PM, Dan Young <dan.young(a)engineerbetter.com>
wrote:

Hi all,

I guess there are a lot of Concourse CI users on this list, so I thought
I'd mention a new tool that some of the EngineerBetter team built while on
the beach. Concourse-Up will let you deploy a production-ready Concourse on
AWS for your team, *using just a single command *and without needing to
know anything about BOSH. It supports custom domains, SSL termination,
scaling workers, and idempotent upgrades.

Here is a blog post: http://www.engineerbetter.com/2017/05/03/introducing-
concourse-up.html

And the GitHub repo: https://github.com/engineerbetter/concourse-up
Hopefully this will be useful for teams setting up Concourse for new
projects, or new Concourse users who less than enthusiastic about needing
to learn BOSH.

Feedback, feature requests and bug reports are most welcome.

Regards,
Dan Young - CEO
EngineerBetter Ltd <http://www.engineerbetter.com> - The UK Cloud Foundry
Specialists
@dan0young <http://www.twitter.com/dan0young>
+44 (0)7783 397092 <+447783397092>


Re: Questions on credential rotation

Dan Jahner
 

Hey Bernd,

I am the product manager of CredHub. We view our project as being part of
the 'rotate' component of Justin's vision. Repave is focused on recreating
instances to a known-good state, which is something outside of our area of
concern.

The current roadmap for CredHub is focused on pulling credentials into our
system; specifically BOSH deployment and service credentials, later
application credentials. Once we have a solid footing for storing and
managing access to these credentials, we plan to explore what possibilities
exist for reducing the friction of credential rotation.

Although I haven't spent a long time investigating, I would agree with your
characterization of the 3 classes of credentials. I think there is
overwhelming agreement that all components should allow credential rotation
without downtime, where possible, so I would expect it is on many teams'
radar. If not, I am happy to start conversations once we get to that phase
of our project.

Thanks,
Dan

On Thu, May 4, 2017 at 6:32 AM Krannich, Bernd <bernd.krannich(a)sap.com>
wrote:

Hello all,



We love Justin Smith’s approach of “Rotate, Repair, Repave” [1] when it
comes to security. Looking at how the “Rotate” aspect is handled in Cloud
Foundry and other BOSH deployments today, we think there’s currently three
classes of credentials:



1. Credentials that can be rotated by updating them and doing a
`bosh deploy` with zero downtime

2. Credentials that can be rotated by updating them and doing a
`bosh deploy` involving a downtime [2]

3. Credentials that cannot be rotated easily at all [3]



A couple of questions here:



· Is the above summary accurate?

· For updates involving a downtime, the only naïve solution I
could come up with is to support two sets of credentials during the
transition. Are there any more strategies?

· Are there any efforts to turn credentials falling under #2 and
#3 into ones that can be updated without downtime?

· CredHub [4] seems to be geared in the direction of “repave”. Is
this the case and does this maybe even support work on the previous bullet?



Thanks in advance,

Bernd



[1] https://www.youtube.com/watch?v=NUXpz0Dni50

[2]
https://github.com/cloudfoundry/cf-release/blob/master/templates/cf.yml#L634 might
be a good example

[3]
https://github.com/cloudfoundry/cf-release/blob/master/templates/cf.yml#L865 might
be a good example

[4] https://github.com/cloudfoundry-incubator/credhub





*Bernd Krannich*

SAP Cloud Platform

*SAP SE*

Dietmar-Hopp-Allee 16, 69190 Walldorf, Germany



E bernd.krannich(a)sap.com



Pflichtangaben/Mandatory Disclosure Statement: www.sap.com/impressum
<http://www.sap.com/company/legal/impressum.epx/>



Diese E-Mail kann Betriebs- oder Geschäftsgeheimnisse oder sonstige
vertrauliche Informationen enthalten. Sollten Sie diese E-Mail irrtümlich
erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts, eine
Vervielfältigung oder Weitergabe der E-Mail ausdrücklich untersagt. Bitte
benachrichtigen Sie uns und vernichten Sie die empfangene E-Mail. Vielen
Dank.



This e-mail may contain trade secrets or privileged, undisclosed, or
otherwise confidential information. If you have received this e-mail in
error, you are hereby notified that any review, copying, or distribution of
it is strictly prohibited. Please inform us immediately and destroy the
original transmittal. Thank you for your cooperation.


disabling ipv6 at the kernel level in stemcells

Dmitriy Kalinin <dkalinin@...>
 

hey all,

we've disabled ipv6 via ipv6.disable=1 in grub in 3363.19+ linux stemcells
some time ago. in previous stemcells it was disabled via sysctl at bootup.

we are now aware that small number of releases may be affected (one release
for example was disabling portion of ipv6 functionality themselves but no
longer can succeed since /proc/... entry is gone and that code was not
checking for its existence). we also had a report that some java processes
may be affected if they were using particular libraries that for some
reason try to obtain local ipv6 address (even though ipv6 was disabled
before their startup).

we try very hard to avoid making any breaking changes in minor stemcell
versions; however, this changed turned out to be more disruptive than we
expected. given that it affects only small number of releases we have
decided to keep it in (hoping that it should be easy for release authors to
issue a patch if necessary).

(for folks thinking about the future ipv6 support, bosh-agent will
automatically turn it on at runtime if necessary.)

as usual feel free to reach out to us on #bosh slack if you need any help.

dmitriy


Questions on credential rotation

Krannich, Bernd <bernd.krannich@...>
 

Hello all,

We love Justin Smith’s approach of “Rotate, Repair, Repave” [1] when it comes to security. Looking at how the “Rotate” aspect is handled in Cloud Foundry and other BOSH deployments today, we think there’s currently three classes of credentials:


1. Credentials that can be rotated by updating them and doing a `bosh deploy` with zero downtime

2. Credentials that can be rotated by updating them and doing a `bosh deploy` involving a downtime [2]

3. Credentials that cannot be rotated easily at all [3]

A couple of questions here:


· Is the above summary accurate?

· For updates involving a downtime, the only naïve solution I could come up with is to support two sets of credentials during the transition. Are there any more strategies?

· Are there any efforts to turn credentials falling under #2 and #3 into ones that can be updated without downtime?

· CredHub [4] seems to be geared in the direction of “repave”. Is this the case and does this maybe even support work on the previous bullet?

Thanks in advance,
Bernd

[1] https://www.youtube.com/watch?v=NUXpz0Dni50
[2] https://github.com/cloudfoundry/cf-release/blob/master/templates/cf.yml#L634 might be a good example
[3] https://github.com/cloudfoundry/cf-release/blob/master/templates/cf.yml#L865 might be a good example
[4] https://github.com/cloudfoundry-incubator/credhub


Bernd Krannich
SAP Cloud Platform
SAP SE
Dietmar-Hopp-Allee 16, 69190 Walldorf, Germany

E bernd.krannich(a)sap.com<mailto:bernd.krannich(a)sap.com>

Pflichtangaben/Mandatory Disclosure Statement: www.sap.com/impressum<http://www.sap.com/company/legal/impressum.epx/>

Diese E-Mail kann Betriebs- oder Geschäftsgeheimnisse oder sonstige vertrauliche Informationen enthalten. Sollten Sie diese E-Mail irrtümlich erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts, eine Vervielfältigung oder Weitergabe der E-Mail ausdrücklich untersagt. Bitte benachrichtigen Sie uns und vernichten Sie die empfangene E-Mail. Vielen Dank.

This e-mail may contain trade secrets or privileged, undisclosed, or otherwise confidential information. If you have received this e-mail in error, you are hereby notified that any review, copying, or distribution of it is strictly prohibited. Please inform us immediately and destroy the original transmittal. Thank you for your cooperation.

2641 - 2660 of 9425