Date   

Re: Unable to upload bits to application using REST

Bob Whiton
 

Turns out the problem was specifying the boundary in the content-type header. If I leave that off, it works fine.


Open PM nominations for CredHub CF Extensions project

Michael Maximilien
 

Hi, all,

Pivotal just mentioned to me that the CredHub project will be relocating to be based primarily out of the Pivotal NYC office (it's currently in Pivotal SF) and as a result Dan Jahner (current PM) is going to roll onto another (TBD) project in 4-6 weeks.

As a result we are announcing the opening of the PM role for CredHub?

If you would like to nominate someone for this role, please do so before next week Monday EOD by sending name, brief bio, and some justification for why you believe this person would be a great PM for the CredHub project.

I will compile nominations and initiate discussions, and a vote (if necessary) by end of next week and announce results here thereafter.

Best,

dr.max

ibm cloud labs
sillicon valley, ca
usa
maximilien.org

Sent from my iPhone


Alex Ley is the new chair for Open Service Broker API PMC

Shannon Coen
 

I am stepping down as chair of the OSB API project management committee
(PMC) and have nominated Alex Ley for the role. The PMC members met and
confirmed the change.

I will continue as a member of the PMC for the time being. In the role of
chair, Alex will act as liaison with the CF Foundation.

Thank you,

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.


Unable to upload bits to application using REST

Bob Whiton
 

I have a deployed application running in a pcf dev environment. I've traced through the calls that the cli makes during the uploading of bits and I'm trying to recreate the PUT request. My request (via curl) is:

curl -X PUT \
'http://api.local.pcfdev.io/v2/apps/f626d0b7-89c8-472f-8136-2e5810e6252c/bits' \
-H 'accept: application/json' \
-H 'authorization: bearer eyJhbGciOiJSUzI1NiIsImtpZCI6ImtleS0xIiwidHlwIjoiSldUIn0.eyJqdGkiOiJkOWZmNTg1NjA0NjE0ZTFjOTE0OThkZDQyNWVkZjlhOSIsInN1YiI6ImZkOTE3YjdjLWFlZGYtNGY3NC1hNDgyLTk4Njk1ODcyYmNjMiIsInNjb3BlIjpbIm9wZW5pZCIsInVhYS51c2VyIiwiY2xvdWRfY29udHJvbGxlci5yZWFkIiwicGFzc3dvcmQud3JpdGUiLCJjbG91ZF9jb250cm9sbGVyLndyaXRlIl0sImNsaWVudF9pZCI6ImNmIiwiY2lkIjoiY2YiLCJhenAiOiJjZiIsImdyYW50X3R5cGUiOiJwYXNzd29yZCIsInVzZXJfaWQiOiJmZDkxN2I3Yy1hZWRmLTRmNzQtYTQ4Mi05ODY5NTg3MmJjYzIiLCJvcmlnaW4iOiJ1YWEiLCJ1c2VyX25hbWUiOiJ1c2VyIiwiZW1haWwiOiJ1c2VyIiwiYXV0aF90aW1lIjoxNTA2ODA4MDQzLCJyZXZfc2lnIjoiNWFiZWZiMTYiLCJpYXQiOjE1MDY4MDgwNDMsImV4cCI6MTUwNjgwODY0MywiaXNzIjoiaHR0cHM6Ly91YWEubG9jYWwucGNmZGV2LmlvL29hdXRoL3Rva2VuIiwiemlkIjoidWFhIiwiYXVkIjpbImNsb3VkX2NvbnRyb2xsZXIiLCJwYXNzd29yZCIsImNmIiwidWFhIiwib3BlbmlkIl19.mhI70oAJs1VQ4DAiWV9908DIIp1MpH7mVsPL26i_7wDVLk-gMgQsyiGOhMpyNE7lAeI835EMNOs0ggw4xTak8PfDLuLSMdMNB8GkCscGcokqM2JFIHC4X8N8sVx60q_pAe3amTsNnBCN_OH0gbppWdkzOmb1dJASnWiwZGC-Pzs' \
-H 'cache-control: no-cache' \
-H 'content-type: multipart/form-data; boundary=-98a67bca59f8bf21dde85ac9e24a2b50105795ad1c295dfeaa4649ff1895' \
-F 'resources=[{"sha1":"9af1440f8edcba96c1d19af7949471cab4bd5f7f","size":141377,"fn":"out_with_host_and_domain.txt","mode":"0644"},{"sha1":"0b3effe3da813132e92d5f873ada776fd1c17f32","size":162353,"fn":"public/javascripts/prototype.js","mode":"0644"}]' \
-F 'application=@...;type=application/zip'

However, I continue to receive the following error:
{
"description": "The app upload is invalid: missing :resources",
"error_code": "CF-AppBitsUploadInvalid",
"code": 160001
}

I've tried all sorts of variations and continue to receive the error. Any ideas what is wrong with the request? (Note: this all stemmed from errors I obtained when trying to perform the same action against Bluemix's implementation of cloud foundry)


Garden Pods Feature Narrative

Julz Friedman
 

Hi cf-dev!

Garden is planning to incept on a feature narrative to bring proper support
for sidecar processes (i.e. processes that share some but not all
namespaces and cgroups with the main container process) to the platform.
This isn't a very user facing feature: it will mostly make implementing
user facing features - such as Envoy proxies, long running health checks
and custom metrics - easier. Nevertheless, we're very happy to hear any
comments or feedback y'all might have!

The document is here:
https://docs.google.com/document/d/1KnGH6TdbU8_7__iFQZtacatr22DqBiQf4maKUsZzYgU/edit#

Thanks!
Julz
Garden PM


Service brokers for 84codes managed services

ipolyzos <i.polyzos@...>
 

I would like to bring to your attention some early prototypical work I have
open sourced, looking forward to your feedback.It is three draft,
proof-of-concept, cloudfoundry service brokers for 84codes.com managed
services i.e. CloudAMQP, ElephantSQL and CloudKarafka

The source code can be found at :
- https://github.com/ipolyzos/cloudamqp-broker
- https://github.com/ipolyzos/elephantsql-broker
and
- https://github.com/ipolyzos/cloudkarafka-broker



--
Sent from: http://cf-dev.70369.x6.nabble.com/


Re: Is fluent-plugin-nats inactive?

Dr Nic Williams <drnicwilliams@...>
 

I've been on vacation. I'll sort you out soon.

________________________________
From: okkez <okkez000(a)gmail.com>
Sent: Friday, September 29, 2017 10:27:03 AM
To: Discussions about Cloud Foundry projects and the system overall.
Subject: [cf-dev] Re: Re: Is fluent-plugin-nats inactive?

Hi, Dr Nic

I've sent my information to the cf-dev list.

Could you help me to keep maintain the project
(cloudfoundry/fluent-plugin-nats)?

Here is my info:

My Github ID is `@okkez` https://github.com/okkez
Please add me to Cloud Foundry Community.

And fluent-plugin-nats is released as RubyGems.
https://rubygems.org/gems/fluent-plugin-nats

So I want to add me as a owner of fluent-plugin-nats gem.
I think that we need original author achied's help or rubygems.org admin's help.

If you want to update boshreleases - blobs & final releases - then ping me for access to the community S3 account.
And one more question.
What is boshreleases? Could you show me the pointers for it?
(I'm not familiar with Cloud Foundry)


2017-09-26 15:21 GMT+09:00 Dr Nic Williams <drnicwilliams(a)gmail.com>:
Kenji, and anyone else wondering about how to take over maintenance (even
temporarily) of inactive cloudfoundry-community projects,

I, or any other owner of the organization, can add you to the org and you
can then write to repos & merge pull requests. Email me/them with your
github ID.

If you want to update boshreleases - blobs & final releases - then ping me
for access to the community S3 account.

Taking over inactive repos is a wonderful thing to do and I highly encourage
it.

Dr Nic

________________________________
From: Kenji Okimoto <okkez000(a)gmail.com>
Sent: Tuesday, September 26, 2017 3:46:18 PM
To: cf-dev(a)lists.cloudfoundry.org
Subject: [cf-dev] Is fluent-plugin-nats inactive?

Hi, cf-dev

I have sent 2 PRs to cloudfoundry-community/fluent-plugin-nats[1][2][3].
These are very simple obvious changes.

But there are no action for long time (about 5 months or more).
Original author is inactive for these 2 years[4].

Could you help me to keep maintaining the repository?
I will keep maintain and add new features to this plugin.
I would like to take over this repository if I can.
Or I would like to become a collaborator.

Can anyone help me, please?

Additional information.
I am writing some fluent-plugin-* and send lots of patches to Fluentd core.
And I have sent a lot of patches to 3rd patty fluent-plugin-*.
See also my recent activities on Github.com [5].

[1]: https://github.com/cloudfoundry-community/fluent-plugin-nats
[2]: https://github.com/cloudfoundry-community/fluent-plugin-nats/pull/7
[3]: https://github.com/cloudfoundry-community/fluent-plugin-nats/pull/8
[4]: https://github.com/achied
[5]:
https://github.com/pulls?utf8=%E2%9C%93&q=is%3Apr+author%3Aokkez+is%3Aclosed

Thanks.


--
okkez
okkez000(a)gmail.com


Re: Is fluent-plugin-nats inactive?

okkez
 

Hi, Dr Nic

I've sent my information to the cf-dev list.

Could you help me to keep maintain the project
(cloudfoundry/fluent-plugin-nats)?

Here is my info:

My Github ID is `@okkez` https://github.com/okkez
Please add me to Cloud Foundry Community.

And fluent-plugin-nats is released as RubyGems.
https://rubygems.org/gems/fluent-plugin-nats

So I want to add me as a owner of fluent-plugin-nats gem.
I think that we need original author achied's help or rubygems.org admin's help.

If you want to update boshreleases - blobs & final releases - then ping me for access to the community S3 account.
And one more question.
What is boshreleases? Could you show me the pointers for it?
(I'm not familiar with Cloud Foundry)


2017-09-26 15:21 GMT+09:00 Dr Nic Williams <drnicwilliams(a)gmail.com>:
Kenji, and anyone else wondering about how to take over maintenance (even
temporarily) of inactive cloudfoundry-community projects,

I, or any other owner of the organization, can add you to the org and you
can then write to repos & merge pull requests. Email me/them with your
github ID.

If you want to update boshreleases - blobs & final releases - then ping me
for access to the community S3 account.

Taking over inactive repos is a wonderful thing to do and I highly encourage
it.

Dr Nic

________________________________
From: Kenji Okimoto <okkez000(a)gmail.com>
Sent: Tuesday, September 26, 2017 3:46:18 PM
To: cf-dev(a)lists.cloudfoundry.org
Subject: [cf-dev] Is fluent-plugin-nats inactive?

Hi, cf-dev

I have sent 2 PRs to cloudfoundry-community/fluent-plugin-nats[1][2][3].
These are very simple obvious changes.

But there are no action for long time (about 5 months or more).
Original author is inactive for these 2 years[4].

Could you help me to keep maintaining the repository?
I will keep maintain and add new features to this plugin.
I would like to take over this repository if I can.
Or I would like to become a collaborator.

Can anyone help me, please?

Additional information.
I am writing some fluent-plugin-* and send lots of patches to Fluentd core.
And I have sent a lot of patches to 3rd patty fluent-plugin-*.
See also my recent activities on Github.com [5].

[1]: https://github.com/cloudfoundry-community/fluent-plugin-nats
[2]: https://github.com/cloudfoundry-community/fluent-plugin-nats/pull/7
[3]: https://github.com/cloudfoundry-community/fluent-plugin-nats/pull/8
[4]: https://github.com/achied
[5]:
https://github.com/pulls?utf8=%E2%9C%93&q=is%3Apr+author%3Aokkez+is%3Aclosed

Thanks.


--
okkez
okkez000(a)gmail.com


Re: Feature Proposal - Polyglot service discovery for c2c

Sascha Matzke
 

Hi,

Sounds great. I'm really looking forward to it!

Sascha

On Wed, Sep 27, 2017 at 7:20 PM, Usha Ramachandran <uramachandran(a)pivotal.io
wrote:
Hello CF community,

The CF networking team would like to share a feature proposal [1] for
platform service discovery for east-west traffic using container
networking.

Please take a look and provide us with feedback and comments in the
document.

Thanks,
Usha

[1] https://docs.google.com/document/d/1Kix6QzXn8Q2Rbgdl97S4E6xsHUTSf
KUQJKrBv7JzAVc/edit?usp=sharing
--
Usha Ramachandran | Senior Product Manager | Pivotal Cloud Foundry - San
Francisco
--
Through the darkness of future past
the magician longs to see
One chants out between two worlds
*Fire walk with me*.


Feature Proposal - Polyglot service discovery for c2c

Usha Ramachandran
 

Hello CF community,

The CF networking team would like to share a feature proposal [1] for
platform service discovery for east-west traffic using container
networking.

Please take a look and provide us with feedback and comments in the
document.

Thanks,
Usha

[1]
https://docs.google.com/document/d/1Kix6QzXn8Q2Rbgdl97S4E6xsHUTSfKUQJKrBv7JzAVc/edit?usp=sharing
--
Usha Ramachandran | Senior Product Manager | Pivotal Cloud Foundry - San
Francisco


Re: Open Service Broker API v2.13

Matt McNeeney
 

Hey Mike,

CC fully supports v2.13 as of now, and that change should be in a CF
release very soon!

Matt

On Wed, Sep 27, 2017 at 4:16 PM Mike Youngstrom <youngm(a)gmail.com> wrote:

Thanks Matt. These are some great updates. I assume the CC will need to
be updated to support this version of the spec? Has that work started?

Thanks,
Mike

On Wed, Sep 27, 2017 at 3:49 AM, Matt McNeeney <mmcneeney(a)pivotal.io>
wrote:

Hello all,

*A new version of the Open Service Broker API - v2.13 - has just been
released.*

This version includes a number of new features that service brokers on
Cloud Foundry can leverage, including:

- Added a schemas
<https://github.com/openservicebrokerapi/servicebroker/blob/v2.13/spec.md#schema-object>field
to services in the catalog that brokers can use to declare the
configuration parameters their service accepts for creating a service
instance, updating a service instance and creating a service binding.
- Added a context
<https://github.com/openservicebrokerapi/servicebroker/blob/v2.13/spec.md#binding> field
to the request body for creating a service binding.
- Allow non-BasicAuth authentication mechanisms
<https://github.com/openservicebrokerapi/servicebroker/blob/v2.13/spec.md#authentication>
.
- Added a Getting Started
<https://github.com/openservicebrokerapi/servicebroker/blob/v2.13/gettingStarted.md> page
including sample service brokers.
- Add originating identity HTTP header
<https://github.com/openservicebrokerapi/servicebroker/blob/v2.13/spec.md#originating-identity>
.

For more information, please check out the specification
<https://github.com/openservicebrokerapi/servicebroker/blob/v2.13/spec.md>
and release notes
<https://github.com/openservicebrokerapi/servicebroker/blob/v2.13/release-notes.md>.
A blog post has been published as part of this release which you can find
here
<https://www.openservicebrokerapi.org/blog/2017/09/27/open-service-broker-v2-13-has-landed>
.

Any community feedback on this release from either service broker authors
or platform authors would be greatly appreciated.

Matt


Re: Open Service Broker API v2.13

Alexander Blease <ablease@...>
 

Hey Mike,

The work to update CC has been merged already. This PR contains links to
all the relavent bits of work.

https://github.com/cloudfoundry/cloud_controller_ng/pull/908

Look out for the next release ;)

On Wed, Sep 27, 2017 at 4:15 PM, Mike Youngstrom <youngm(a)gmail.com> wrote:

Thanks Matt. These are some great updates. I assume the CC will need to
be updated to support this version of the spec? Has that work started?

Thanks,
Mike

On Wed, Sep 27, 2017 at 3:49 AM, Matt McNeeney <mmcneeney(a)pivotal.io>
wrote:

Hello all,

*A new version of the Open Service Broker API - v2.13 - has just been
released.*

This version includes a number of new features that service brokers on
Cloud Foundry can leverage, including:

- Added a schemas
<https://github.com/openservicebrokerapi/servicebroker/blob/v2.13/spec.md#schema-object>field
to services in the catalog that brokers can use to declare the
configuration parameters their service accepts for creating a service
instance, updating a service instance and creating a service binding.
- Added a context
<https://github.com/openservicebrokerapi/servicebroker/blob/v2.13/spec.md#binding> field
to the request body for creating a service binding.
- Allow non-BasicAuth authentication mechanisms
<https://github.com/openservicebrokerapi/servicebroker/blob/v2.13/spec.md#authentication>
.
- Added a Getting Started
<https://github.com/openservicebrokerapi/servicebroker/blob/v2.13/gettingStarted.md> page
including sample service brokers.
- Add originating identity HTTP header
<https://github.com/openservicebrokerapi/servicebroker/blob/v2.13/spec.md#originating-identity>
.

For more information, please check out the specification
<https://github.com/openservicebrokerapi/servicebroker/blob/v2.13/spec.md>
and release notes
<https://github.com/openservicebrokerapi/servicebroker/blob/v2.13/release-notes.md>.
A blog post has been published as part of this release which you can find
here
<https://www.openservicebrokerapi.org/blog/2017/09/27/open-service-broker-v2-13-has-landed>
.

Any community feedback on this release from either service broker authors
or platform authors would be greatly appreciated.

Matt


Re: Open Service Broker API v2.13

Mike Youngstrom
 

Thanks Matt. These are some great updates. I assume the CC will need to
be updated to support this version of the spec? Has that work started?

Thanks,
Mike

On Wed, Sep 27, 2017 at 3:49 AM, Matt McNeeney <mmcneeney(a)pivotal.io> wrote:

Hello all,

*A new version of the Open Service Broker API - v2.13 - has just been
released.*

This version includes a number of new features that service brokers on
Cloud Foundry can leverage, including:

- Added a schemas
<https://github.com/openservicebrokerapi/servicebroker/blob/v2.13/spec.md#schema-object>field
to services in the catalog that brokers can use to declare the
configuration parameters their service accepts for creating a service
instance, updating a service instance and creating a service binding.
- Added a context
<https://github.com/openservicebrokerapi/servicebroker/blob/v2.13/spec.md#binding> field
to the request body for creating a service binding.
- Allow non-BasicAuth authentication mechanisms
<https://github.com/openservicebrokerapi/servicebroker/blob/v2.13/spec.md#authentication>
.
- Added a Getting Started
<https://github.com/openservicebrokerapi/servicebroker/blob/v2.13/gettingStarted.md> page
including sample service brokers.
- Add originating identity HTTP header
<https://github.com/openservicebrokerapi/servicebroker/blob/v2.13/spec.md#originating-identity>
.

For more information, please check out the specification
<https://github.com/openservicebrokerapi/servicebroker/blob/v2.13/spec.md>
and release notes
<https://github.com/openservicebrokerapi/servicebroker/blob/v2.13/release-notes.md>.
A blog post has been published as part of this release which you can find
here
<https://www.openservicebrokerapi.org/blog/2017/09/27/open-service-broker-v2-13-has-landed>
.

Any community feedback on this release from either service broker authors
or platform authors would be greatly appreciated.

Matt


Re: Container-to-container networking questions

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

Hi Usha,

Thank you very much for your reply.

Could you provide some more details about what fine-grained access you are looking for? Currently we do not plan to extend policy config to any other role than Space Developer but are open to feedback.
I guess for any multi-tenant PaaS environment that is running separate customer tenants in separate CF orgs, container-to-container networking will only be usable (in the sense of a customer-facing feature) if users are restricted to creating policies pointing to sources and targets that can also be modified by those users.

So, if I understood you correctly, this means that a user that is SpaceDeveloper in org A/space a as well as org B/space b should be able to create a policy connecting an app that is located in org A/space a and another app in org B/space b, but not to an org C/space c the user doesn’t have any access to. Maybe the same is true for an OrgManager of both orgs (but one could say this is not required because OrgManagers could grant SpaceDeveloper rights to their own users). Is this roughly what you had in mind?

Thanks in advance,
Bernd

From: Usha Ramachandran <uramachandran(a)pivotal.io>
Reply-To: "Discussions about Cloud Foundry projects and the system overall." <cf-dev(a)lists.cloudfoundry.org>
Date: Tuesday, 26. September 2017 at 20:38
To: "Discussions about Cloud Foundry projects and the system overall." <cf-dev(a)lists.cloudfoundry.org>
Subject: [cf-dev] Re: Re: Re: Container-to-container networking questions

Hi Bernd,

Please see inline.

Two more follow-up questions:
· What would be a use case for tags [1] in this context and is there only a way to retrieve them or also a way to create them which is not yet part of the API readme?
The tags are read-only, if you have a packet capture of container to container traffic, the GBP tag in the VXLAN header can be provided as input to this API to identify the source application. This is simpler than tracing an IP address back to an application.

·
· Permission-wise, it seems to me that network.write allows configuring container-to-container networking also for apps that otherwise a user wouldn’t even be able to access/modify (in terms of being a SpaceDeveloper for the space in which the app is deployed). So, providing network.write to a user is more delegating a CF-wide permission from the admin to other users. Is my impression correct and if so, are there any plans to go in the direction of providing more fine-grained delegation mechanisms for container-to-container networking?
Your understanding is correct. Could you provide some more details about what fine-grained access you are looking for? Currently we do not plan to extend policy config to any other role than Space Developer but are open to feedback.

Thanks,
Usha

·

Thanks in advance,
Bernd

[1] https://github.com/cloudfoundry-incubator/cf-networking-release/blob/develop/docs/API.md --> GET /networking/v1/external/tags

From: Usha Ramachandran <uramachandran(a)pivotal.io<mailto:uramachandran(a)pivotal.io>>
Reply-To: "Discussions about Cloud Foundry projects and the system overall." <cf-dev(a)lists.cloudfoundry.org<mailto:cf-dev(a)lists.cloudfoundry.org>>
Date: Friday, 22. September 2017 at 00:44
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: Container-to-container networking questions

Hi Bernd,

The CLI currently only supports configuring policies for the targeted space. The APIs can be used to configure policies for apps in different spaces and orgs. Here is a link to the API config - https://github.com/cloudfoundry-incubator/cf-networking-release/blob/develop/docs/API.md

Thanks,
Usha

On Sep 21, 2017, at 10:58 AM, Krannich, Bernd <bernd.krannich(a)sap.com<mailto:bernd.krannich(a)sap.com>> wrote:
Hello all,

Testing container-to-container networking on BOSH Lite, it looks to me that both apps need to be deployed into the same CF org and space. At least I got errors for other scenarios I tried, e.g. deployment into different spaces of the same org or even into a different org.

Questions:
• Is my observation correct?
• I tried finding the respective section around the above in the docs but couldn’t. Did I miss the respective section?
• Are there any plans to go beyond app-to-app communication in the same CF org and space? This would open up a couple of follow-up questions, I guess, on the permissions required to configure such a setup.

Thanks in advance,
Bernd

Bernd Krannich
SAP Cloud Platform
SAP SE
Dietmar-Hopp-Allee 16, 69190 Walldorf, Germany<https://maps.google.com/?q=Dietmar-Hopp-Allee+16,+69190+Walldorf,+Germany&entry=gmail&source=g>

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.
--
Usha Ramachandran | Senior Product Manager | Pivotal Cloud Foundry - San Francisco


Open Service Broker API v2.13

Matt McNeeney
 

Hello all,

*A new version of the Open Service Broker API - v2.13
<v2.13https://github.com/openservicebrokerapi/servicebroker/blob/v2.13/spec.md>
- has just been released.*

This version includes a number of new features that service brokers on
Cloud Foundry can leverage, including:

- Added a schemas
<https://github.com/openservicebrokerapi/servicebroker/blob/v2.13/spec.md#schema-object>field
to services in the catalog that brokers can use to declare the
configuration parameters their service accepts for creating a service
instance, updating a service instance and creating a service binding.
- Added a context
<https://github.com/openservicebrokerapi/servicebroker/blob/v2.13/spec.md#binding>
field
to the request body for creating a service binding.
- Allow non-BasicAuth authentication mechanisms
<https://github.com/openservicebrokerapi/servicebroker/blob/v2.13/spec.md#authentication>
.
- Added a Getting Started
<https://github.com/openservicebrokerapi/servicebroker/blob/v2.13/gettingStarted.md>
page
including sample service brokers.
- Add originating identity HTTP header
<https://github.com/openservicebrokerapi/servicebroker/blob/v2.13/spec.md#originating-identity>
.

For more information, please check out the specification
<https://github.com/openservicebrokerapi/servicebroker/blob/v2.13/spec.md>
and release notes
<https://github.com/openservicebrokerapi/servicebroker/blob/v2.13/release-notes.md>.
A blog post has been published as part of this release which you can find
here
<https://www.openservicebrokerapi.org/blog/2017/09/27/open-service-broker-v2-13-has-landed>
.

Any community feedback on this release from either service broker authors
or platform authors would be greatly appreciated.

Matt


Re: Service Fabrik goes Open Source and proposing CF Incubation

Jain, Ashish <ashish.jain09@...>
 

Hi Alex,

I have replied back on the comments you had on the proposal. We look forward to any more thoughts or comments you may have.

Best regards,
Ashish

From: Jain, Ashish [mailto:ashish.jain09(a)sap.com]
Sent: Tuesday, September 26, 2017 12:04 AM
To: Discussions about Cloud Foundry projects and the system overall. <cf-dev(a)lists.cloudfoundry.org>
Cc: Chip Childers <cchilders(a)cloudfoundry.org>
Subject: [cf-dev] Re: Re: Re: Re: Re: Re: Re: Service Fabrik goes Open Source and proposing CF Incubation

Hi Therese,

Thanks for resolving all the comments ☺. We welcome others in the community to kindly review our proposal which is available @ (https://docs.google.com/document/d/1LiYxLkHoAThLXQp08Wvrit8kg07J1GdsbIkid6X145I/edit#<https://docs.google.com/document/d/1LiYxLkHoAThLXQp08Wvrit8kg07J1GdsbIkid6X145I/edit>) and look forward to answering any questions you may have on Service Fabrik.

Best regards,
Ashish


From: Therese Stowell [mailto:tstowell(a)pivotal.io]
Sent: Monday, September 25, 2017 1:34 PM
To: Discussions about Cloud Foundry projects and the system overall. <cf-dev(a)lists.cloudfoundry.org<mailto:cf-dev(a)lists.cloudfoundry.org>>
Cc: Chip Childers <cchilders(a)cloudfoundry.org<mailto:cchilders(a)cloudfoundry.org>>
Subject: [cf-dev] Re: Re: Re: Re: Re: Re: Service Fabrik goes Open Source and proposing CF Incubation

Hi Ashish,
I've resolved all my comments.
best,
Therese

On Fri, Sep 22, 2017 at 5:52 PM, Jain, Ashish <ashish.jain09(a)sap.com<mailto:ashish.jain09(a)sap.com>> wrote:
Hi Therese,

I have tried my best to add all the information as pointed by you. We look forward to anymore thoughts or comments you may have on the proposal.

Best Regards,
Ashish

From: Therese Stowell [mailto:tstowell(a)pivotal.io<mailto:tstowell(a)pivotal.io>]
Sent: Friday, September 22, 2017 3:11 PM
To: Discussions about Cloud Foundry projects and the system overall. <cf-dev(a)lists.cloudfoundry.org<mailto:cf-dev(a)lists.cloudfoundry.org>>
Cc: Chip Childers <cchilders(a)cloudfoundry.org<mailto:cchilders(a)cloudfoundry.org>>
Subject: [cf-dev] Re: Re: Re: Re: Service Fabrik goes Open Source and proposing CF Incubation

Hi Ashish,
Thanks for the prompt replies.
Could you please add the info in your comments into the main doc? I'd be happy to resolve the comments after that.
best,
Therese

On Fri, Sep 22, 2017 at 4:43 AM, Jain, Ashish <ashish.jain09(a)sap.com<mailto:ashish.jain09(a)sap.com>> wrote:
Hi Therese,

We have responded back to the comments you had on the incubation proposal. We look forward to any more thoughts or comments you may have.

Best Regards,
Ashish

From: Jain, Ashish [mailto:ashish.jain09(a)sap.com<mailto:ashish.jain09(a)sap.com>]
Sent: Thursday, September 21, 2017 11:06 PM
To: Discussions about Cloud Foundry projects and the system overall. <cf-dev(a)lists.cloudfoundry.org<mailto:cf-dev(a)lists.cloudfoundry.org>>; Chip Childers <cchilders(a)cloudfoundry.org<mailto:cchilders(a)cloudfoundry.org>>
Subject: [cf-dev] Re: Re: Service Fabrik goes Open Source and proposing CF Incubation

Thank you Dr. Max for providing us a slot in yesterday’s #CAB call. It was great to be there and present Service Fabrik to the CF community. We look forward to answering any questions which the community may have on Service Fabrik. Our incubation proposal is hosted here (https://docs.google.com/document/d/1LiYxLkHoAThLXQp08Wvrit8kg07J1GdsbIkid6X145I/edit) which provide more details on Service Fabrik.

Best Regards,
Ashish

From: Michael Maximilien [mailto:maxim(a)us.ibm.com]
Sent: Monday, August 21, 2017 9:38 PM
To: Chip Childers <cchilders(a)cloudfoundry.org<mailto:cchilders(a)cloudfoundry.org>>
Cc: CF Developers Mailing List <cf-dev(a)lists.cloudfoundry.org<mailto:cf-dev(a)lists.cloudfoundry.org>>
Subject: [cf-dev] Re: Service Fabrik goes Open Source

Absolutely! Will reach out to Ashish and other SAP friends to schedule for September.



dr.max

ibm cloud labs
sillicon valley, ca
usa
maximilien.org<http://maximilien.org>

Sent from my iPhone

On Aug 21, 2017, at 8:56 AM, Chip Childers <cchilders(a)cloudfoundry.org<mailto:cchilders(a)cloudfoundry.org>> wrote:
Neat!

cc/ Dr Max, since I think this would be really cool to have as a demo on one of the monthly CAB calls!

-chip
On Mon, Aug 21, 2017 at 11:47 AM Jain, Ashish <ashish.jain09(a)sap.com<mailto:ashish.jain09(a)sap.com>> wrote:
Dear All,
SAP Cloud Platform team proudly announces the Open Source release of Service Fabrik (SF) and related projects.
What is Service Fabrik?
Service Fabrik is Cloud Foundry broker envisioned as one-stop for provisioning & management of enterprise grade backing services (for example PostgreSQL, MongoDB, RabbitMQ, Redis) for enterprise grade Cloud Foundry applications. It supports provisioning of developer only services using Docker Swarm and production grade services via BOSH release.
Hmm, What else?
Well, it enables provisioning of highly available and scalable services on a multi-cloud infrastructure with ease and speed. Effortlessly monitor, upgrade services with patches, security updates and backup or restore mission critical data in a periodic automated way are some of its key highlights.
Ohh really, anyone using it?
We already have hundreds of BOSH based & thousands of Containers based service deployments running in production which uses Service Fabrik. We recently announced the General Availability<https://urldefense.proofpoint.com/v2/url?u=https-3A__blogs.sap.com_2017_05_16_data-2Dmanagement-2Don-2Dsap-2Dcloud-2Dplatform-2Dnew-2Denvironment-2Dnew-2Dcapabilities_&d=DwMFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=Bz4hmYy71Y4CZ6fn8PKNQA&m=dlvphpEMUkO1-OwQp4mzxEVZpmUc47xLJGHZ5tMVCNQ&s=1O14Rfb-A5rsVelHodUPgB0OM0zwqOnPySmVEZUrMXw&e=> of backing services, managed by Service Fabrik, on SAP Cloud Platform.
That seems promising where can I get all of it?
Service Fabrik code can be found here<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_SAP_service-2Dfabrik-2Dbroker&d=DwMFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=Bz4hmYy71Y4CZ6fn8PKNQA&m=dlvphpEMUkO1-OwQp4mzxEVZpmUc47xLJGHZ5tMVCNQ&s=VsZMzknjhuro0a8-bZeU5mzCbWDwOJCCJSDPGKbRt0w&e=>. Details on related GitHub repositories below
[1] service-fabrik-boshrelease<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_SAP_service-2Dfabrik-2Dboshrelease&d=DwMFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=Bz4hmYy71Y4CZ6fn8PKNQA&m=dlvphpEMUkO1-OwQp4mzxEVZpmUc47xLJGHZ5tMVCNQ&s=fTphhMYELwiyw1ZD680IvDIUzEdY2eukLLbb_Nvr0Rs&e=> - BOSH release to deploy Service Fabrik
[2] service-fabrik-lvm-volume-driver<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_SAP_service-2Dfabrik-2Dlvm-2Dvolume-2Ddriver&d=DwMFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=Bz4hmYy71Y4CZ6fn8PKNQA&m=dlvphpEMUkO1-OwQp4mzxEVZpmUc47xLJGHZ5tMVCNQ&s=Tz36M9wc7SDtQh5MRuDbKDixF40flXrYT5-zEHJtRAI&e=> - Logical volume driver for Docker based service
[3] service-fabrik-blueprint-service<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_SAP_service-2Dfabrik-2Dblueprint-2Dservice&d=DwMFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=Bz4hmYy71Y4CZ6fn8PKNQA&m=dlvphpEMUkO1-OwQp4mzxEVZpmUc47xLJGHZ5tMVCNQ&s=5hMTxH2iDvvhteywacQlF3J0iltfEIqVQV6YrRozdiA&e=> - Test service to try out Service Fabrik
[4] service-fabrik-blueprint-app<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_SAP_service-2Dfabrik-2Dblueprint-2Dapp&d=DwMFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=Bz4hmYy71Y4CZ6fn8PKNQA&m=dlvphpEMUkO1-OwQp4mzxEVZpmUc47xLJGHZ5tMVCNQ&s=qA9wLEGJfT98qYod4XOx9Zgqmc9oZozEtvO58yoHuic&e=> - Test app to try out blueprint service
[5] service-fabrik-blueprint-boshrelease<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_SAP_service-2Dfabrik-2Dblueprint-2Dboshrelease&d=DwMFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=Bz4hmYy71Y4CZ6fn8PKNQA&m=dlvphpEMUkO1-OwQp4mzxEVZpmUc47xLJGHZ5tMVCNQ&s=tkNe4E6cNhl8hvh9XEAc6WzqMZF7zxWBBWMeC5hVn9M&e=> – BOSH release for blueprint service
[6] service-fabrik-backup-restore<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_SAP_service-2Dfabrik-2Dbackup-2Drestore&d=DwMFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=Bz4hmYy71Y4CZ6fn8PKNQA&m=dlvphpEMUkO1-OwQp4mzxEVZpmUc47xLJGHZ5tMVCNQ&s=dF9tevJnXFtGDkOcLHRDxnMoqap34MSmGivv350G2ro&e=> – Library for backup & restore of service instances.

Some resources which will provide more insight on Service Fabrik are as follows:
[1] Service-Fabrik @ Silicon Valley Summit<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.youtube.com_watch-3Fv-3DyO-2DuCZekjSg&d=DwMFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=Bz4hmYy71Y4CZ6fn8PKNQA&m=dlvphpEMUkO1-OwQp4mzxEVZpmUc47xLJGHZ5tMVCNQ&s=BFYkp_czKTaohgf0qPM7PR3nEmmFR3ZGvqd2Ws13F8g&e=>
[2] Service Fabrik goes Open Source<https://urldefense.proofpoint.com/v2/url?u=https-3A__blogs.sap.com_2017_08_21_service-2Dfabrik-2Dfrom-2Dsap-2Dgoes-2Dopen-2Dsource_&d=DwMFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=Bz4hmYy71Y4CZ6fn8PKNQA&m=dlvphpEMUkO1-OwQp4mzxEVZpmUc47xLJGHZ5tMVCNQ&s=Qq8_7b80Tl8iBzCrNnb6yzZS7nlAlNmA_1_F8jsEj7Y&e=>
And We Propose to Incubate!
We have made the proposal to include Service Fabrik as Cloud Foundry incubation project, details here<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_document_d_1LiYxLkHoAThLXQp08Wvrit8kg07J1GdsbIkid6X145I_edit-3Fusp-3Dsharing&d=DwMFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=Bz4hmYy71Y4CZ6fn8PKNQA&m=dlvphpEMUkO1-OwQp4mzxEVZpmUc47xLJGHZ5tMVCNQ&s=QXOpMfKoVse8Fr0M-Ncg2g2zlItNKJmtJmIQqh6n0x8&e=>
That sounds awesome, but who rescues me?
Our team is just one click away, feel free to post an issue<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_SAP_service-2Dfabrik-2Dbroker_issues_new&d=DwMFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=Bz4hmYy71Y4CZ6fn8PKNQA&m=dlvphpEMUkO1-OwQp4mzxEVZpmUc47xLJGHZ5tMVCNQ&s=qP7RZzy6Zt3hzZft7eMTh6hilCINtSyobxCqXlcRpho&e=> and we will help you at the earliest.
What Else?
Thanks from the SAP Cloud Platform & See you soon.
--
Chip Childers
CTO, Cloud Foundry Foundation
1.267.250.0815<tel:(267)%20250-0815>


Re: CF CLI v6.32.0 Released Today - V3 app commands

Bret Mogilefsky
 

Thanks for all the hard work to cross this marker!

The docs on multi-buildpack are from September 15th and don't yet refer to
v3-push... Is an update to docs still pending?

Bret

On Tue, Sep 26, 2017 at 8:50 PM Mike Youngstrom <youngm(a)gmail.com> wrote:

Excellent update. It is great to start seeing v3 features becoming a
reality!

Mike

On Tue, Sep 26, 2017 at 7:44 PM, Koper, Dies <diesk(a)fast.au.fujitsu.com>
wrote:

The CF CLI team cut 6.32.0 today.

Deb, yum and Homebrew repos have been updated; binaries, installers and
link to release notes are available at:



https://github.com/cloudfoundry/cli#downloads


V3 app commands

This cf CLI release exposes app related features offered by the CC V3
APIs that were marked GA on 4 Aug 2017.
Features include the deployment and management of apps with multiple
processes (defined in a Procfile), staging apps with multiple buildpacks,
and uploading and staging multiple versions of a single app to enable a
near-zero downtime app update experience.
Refer to the full list of commands here
<https://docs.cloudfoundry.org/devguide/v3-commands.html> and details on
how to configure multiple buildpacks here
<http://docs.cloudfoundry.org/buildpacks/use-multiple-buildpacks.html>.

The CAPI team is working on a blog explaining the use cases of the
granular push commands and will share that on the CF Dev mailing list soon.

The new features are introduced using new commands starting with a "v3-"
suffix.

- Some commands are mostly equivalent to existing app related
commands but call the V3 APIs or expose new flags to unlock additional
features.
- Other commands are new and expose the primitives of apps, such as
operations on an app's packages and droplets.

We welcome your feedback on the new features, the user experience and the
new workflows you may adopt.
Based on that, we will look at making commonly used v3 commands the
default in a future release, with a migration plan for users targeting CF
endpoints that do not support the GA'ed V3 APIs yet.

*Please treat the "v3" commands as experimental - no guarantees are made
about their availability or compatibility in subsequent cf CLI releases.*
New commands

diesk(a)cloud-cf:~/workspace$ ./cf v3-<tab><tab>

v3-app v3-get-health-check v3-set-env

v3-apps v3-packages v3-set-health-check

v3-create-app v3-push v3-stage

v3-create-package v3-restart v3-start

v3-delete v3-restart-app-instance v3-stop

v3-droplets v3-scale v3-unset-env

v3-env v3-set-droplet

Notes on new commands

Take into consideration:

- v3-push for now supports only a subset of features of "old" push.
In particular, it does not support app manifests yet, nor any flags to set
the stack or modify the default mapped route, nor applies exclusions from a
.cfignore file.
After pushing an app with this command, please use map-route,
bind-service, v3-set-env, v3-scale, v3-set-health-check, etc. to
update its configuration.
- For some app related commands (ssh, bind-service, etc.) there is no
"v3" version yet.
Please use the "old" command for now.
- Although "v3" and "old" commands can be used together, some
combinations may give unexpected results.
For example, if "v3" commands are used to create an app with a
package but it is not staged, or v3-push is used to push an app that
fails to stage, it is not returned by the "old" apps command.

SSL_CERT_FILE/SSL_CERT_PATH for self-signed API server certificate

Because Golang 1.9 added support for the environment variables
SSL_CERT_FILE and SSL_CERT_PATH on Unix systems, it is now possible to
use these when targeting a CF API endpoint that uses a self-signed
certficate.
This is particularly useful in a CI environment without root access,
where the existing method of registering the certificate in the local
truststore <http://docs.cloudfoundry.org/cf-cli/self-signed.html> is not
possible. (#1084 <https://github.com/cloudfoundry/cli/issues/1084>)

Note that this is supported since the previous cf CLI release (6.31.0).
Refactored commands

We are in the process of creating a more consistent user experience; our
goal is to standardize UI output.
For example, warnings and errors will consistently be outputted to stderr
instead of stdout and English table and key-value headers displayed in
lowercase.
As we iterate through the list of commands, we are also focusing on
improving performance and stability.
Please review your scripts if they depend on the output of these commands.

List of improved commands in this release:

- create-route
- orgs
- spaces

Updated commands

- spaces now displays an error when the authentication tokens have
expired. (#1051 <https://github.com/cloudfoundry/cli/issues/1051>)
- spaces now displays an error when receiving an unexpected response
from the API endpoint. (#1136
<https://github.com/cloudfoundry/cli/issues/1136>)

New & updated community plugins

- cflocal <https://github.com/sclevine/cflocal> v0.14.0 - Stage and
launch CF apps, push and pull droplets, and connect to real CF services --
in Docker
- open <https://github.com/cloudfoundry-community/cf-plugin-open>
v1.2.1 - Open App URLs + Service dashboards in browser
- fastpush <https://github.com/xiwenc/cf-fastpush-plugin> v1.1.0 -
Fast, non-persistent, smart and incrementally updating of your application

Enjoy!



Regards,

Dies Koper
Cloud Foundry Product Manager - CLI





Re: CF CLI v6.32.0 Released Today - V3 app commands

Mike Youngstrom
 

Excellent update. It is great to start seeing v3 features becoming a
reality!

Mike

On Tue, Sep 26, 2017 at 7:44 PM, Koper, Dies <diesk(a)fast.au.fujitsu.com>
wrote:

The CF CLI team cut 6.32.0 today.

Deb, yum and Homebrew repos have been updated; binaries, installers and
link to release notes are available at:



https://github.com/cloudfoundry/cli#downloads


V3 app commands

This cf CLI release exposes app related features offered by the CC V3 APIs
that were marked GA on 4 Aug 2017.
Features include the deployment and management of apps with multiple
processes (defined in a Procfile), staging apps with multiple buildpacks,
and uploading and staging multiple versions of a single app to enable a
near-zero downtime app update experience.
Refer to the full list of commands here
<https://docs.cloudfoundry.org/devguide/v3-commands.html> and details on
how to configure multiple buildpacks here
<http://docs.cloudfoundry.org/buildpacks/use-multiple-buildpacks.html>.

The CAPI team is working on a blog explaining the use cases of the
granular push commands and will share that on the CF Dev mailing list soon.

The new features are introduced using new commands starting with a "v3-"
suffix.

- Some commands are mostly equivalent to existing app related commands
but call the V3 APIs or expose new flags to unlock additional features.
- Other commands are new and expose the primitives of apps, such as
operations on an app's packages and droplets.

We welcome your feedback on the new features, the user experience and the
new workflows you may adopt.
Based on that, we will look at making commonly used v3 commands the
default in a future release, with a migration plan for users targeting CF
endpoints that do not support the GA'ed V3 APIs yet.

*Please treat the "v3" commands as experimental - no guarantees are made
about their availability or compatibility in subsequent cf CLI releases.*
New commands

diesk(a)cloud-cf:~/workspace$ ./cf v3-<tab><tab>

v3-app v3-get-health-check v3-set-env

v3-apps v3-packages v3-set-health-check

v3-create-app v3-push v3-stage

v3-create-package v3-restart v3-start

v3-delete v3-restart-app-instance v3-stop

v3-droplets v3-scale v3-unset-env

v3-env v3-set-droplet

Notes on new commands

Take into consideration:

- v3-push for now supports only a subset of features of "old" push. In
particular, it does not support app manifests yet, nor any flags to set the
stack or modify the default mapped route, nor applies exclusions from a
.cfignore file.
After pushing an app with this command, please use map-route,
bind-service, v3-set-env, v3-scale, v3-set-health-check, etc. to
update its configuration.
- For some app related commands (ssh, bind-service, etc.) there is no
"v3" version yet.
Please use the "old" command for now.
- Although "v3" and "old" commands can be used together, some
combinations may give unexpected results.
For example, if "v3" commands are used to create an app with a package
but it is not staged, or v3-push is used to push an app that fails to
stage, it is not returned by the "old" apps command.

SSL_CERT_FILE/SSL_CERT_PATH for self-signed API server certificate

Because Golang 1.9 added support for the environment variables
SSL_CERT_FILE and SSL_CERT_PATH on Unix systems, it is now possible to
use these when targeting a CF API endpoint that uses a self-signed
certficate.
This is particularly useful in a CI environment without root access, where
the existing method of registering the certificate in the local truststore
<http://docs.cloudfoundry.org/cf-cli/self-signed.html> is not possible. (
#1084 <https://github.com/cloudfoundry/cli/issues/1084>)

Note that this is supported since the previous cf CLI release (6.31.0).
Refactored commands

We are in the process of creating a more consistent user experience; our
goal is to standardize UI output.
For example, warnings and errors will consistently be outputted to stderr
instead of stdout and English table and key-value headers displayed in
lowercase.
As we iterate through the list of commands, we are also focusing on
improving performance and stability.
Please review your scripts if they depend on the output of these commands.

List of improved commands in this release:

- create-route
- orgs
- spaces

Updated commands

- spaces now displays an error when the authentication tokens have
expired. (#1051 <https://github.com/cloudfoundry/cli/issues/1051>)
- spaces now displays an error when receiving an unexpected response
from the API endpoint. (#1136
<https://github.com/cloudfoundry/cli/issues/1136>)

New & updated community plugins

- cflocal <https://github.com/sclevine/cflocal> v0.14.0 - Stage and
launch CF apps, push and pull droplets, and connect to real CF services --
in Docker
- open <https://github.com/cloudfoundry-community/cf-plugin-open>
v1.2.1 - Open App URLs + Service dashboards in browser
- fastpush <https://github.com/xiwenc/cf-fastpush-plugin> v1.1.0 -
Fast, non-persistent, smart and incrementally updating of your application

Enjoy!



Regards,

Dies Koper
Cloud Foundry Product Manager - CLI





Re: Feature Proposal: Securing Service Instance Credentials

Dan Jahner
 

Hi Mike,

Yes, we are also validating an optional configuration that would allow
operators to shift the burden to applications to retrieve credentials
directly from CredHub. This configuration would be appropriate if storing
service credentials as environment variables is undesirable.

The solution for this configuration would be the same as proposed, except
without the last-mile substitution provided by the launcher. The
application - or a suitable library such as Spring CredHub Connector
<https://github.com/spring-projects/spring-credhub/tree/master/spring-credhub-cloud-connector>
- would fetch credentials from CredHub and store them in application
memory.

Please let me know if you have any other questions.

Thanks,
Dan Jahner
Product Manager, CredHub

On Tue, Sep 26, 2017 at 3:22 PM Mike Youngstrom <youngm(a)gmail.com> wrote:

So, this proposal essentially documents how CF and brokers will be able to
store credentials in CredHub and still provide applications with a
backwards compatible VCAP_SERVICES environment variable that contains those
credentials. Which I think is great pattern to continue for backwards
compatibility and for least common denominator client scenarios.

However, is there any thought being put towards concurrently considering
strategic an approach where applications get credentials directly from
CredHub as well? Or is obtaining credentials via VCAP_SERVICES considered
the only CF standard/strategic approach for an app getting service
credentials?

Does this question make sense?

Mike



On Thu, Sep 21, 2017 at 1:39 AM, Dieu Cao <dcao(a)pivotal.io> wrote:

Hello all,

We've put together a proposal for Securing Service Instance Credentials
[1]

Security Officers and Cloud Foundry / Service Operators want to meet
security best practices and their internal policies with respect to the
creation, storage, and delivery of credentials to applications for use in
accessing services while minimizing effects on developer productivity.

The proposal details a workflow and separation of responsibilities in
which
Service credentials can be stored in CredHub rather than the Cloud
Controller component of Cloud Foundry.

We'd like to be able to iterate on this document quickly, so please keep
your input and feedback in the comments of the document.

Thanks!
Dieu
CF Runtime PMC Lead


[1] https://goo.gl/p1oxh7


CF CLI v6.32.0 Released Today - V3 app commands

Koper, Dies <diesk@...>
 

The CF CLI team cut 6.32.0 today.
Deb, yum and Homebrew repos have been updated; binaries, installers and link to release notes are available at:

https://github.com/cloudfoundry/cli#downloads

V3 app commands

This cf CLI release exposes app related features offered by the CC V3 APIs that were marked GA on 4 Aug 2017.
Features include the deployment and management of apps with multiple processes (defined in a Procfile), staging apps with multiple buildpacks, and uploading and staging multiple versions of a single app to enable a near-zero downtime app update experience.
Refer to the full list of commands here<https://docs.cloudfoundry.org/devguide/v3-commands.html> and details on how to configure multiple buildpacks here<http://docs.cloudfoundry.org/buildpacks/use-multiple-buildpacks.html>.

The CAPI team is working on a blog explaining the use cases of the granular push commands and will share that on the CF Dev mailing list soon.

The new features are introduced using new commands starting with a "v3-" suffix.

* Some commands are mostly equivalent to existing app related commands but call the V3 APIs or expose new flags to unlock additional features.
* Other commands are new and expose the primitives of apps, such as operations on an app's packages and droplets.

We welcome your feedback on the new features, the user experience and the new workflows you may adopt.
Based on that, we will look at making commonly used v3 commands the default in a future release, with a migration plan for users targeting CF endpoints that do not support the GA'ed V3 APIs yet.

Please treat the "v3" commands as experimental - no guarantees are made about their availability or compatibility in subsequent cf CLI releases.

New commands

diesk(a)cloud-cf:~/workspace$ ./cf v3-<tab><tab>

v3-app v3-get-health-check v3-set-env

v3-apps v3-packages v3-set-health-check

v3-create-app v3-push v3-stage

v3-create-package v3-restart v3-start

v3-delete v3-restart-app-instance v3-stop

v3-droplets v3-scale v3-unset-env

v3-env v3-set-droplet

Notes on new commands

Take into consideration:

* v3-push for now supports only a subset of features of "old" push. In particular, it does not support app manifests yet, nor any flags to set the stack or modify the default mapped route, nor applies exclusions from a .cfignore file.
After pushing an app with this command, please use map-route, bind-service, v3-set-env, v3-scale, v3-set-health-check, etc. to update its configuration.
* For some app related commands (ssh, bind-service, etc.) there is no "v3" version yet.
Please use the "old" command for now.
* Although "v3" and "old" commands can be used together, some combinations may give unexpected results.
For example, if "v3" commands are used to create an app with a package but it is not staged, or v3-push is used to push an app that fails to stage, it is not returned by the "old" apps command.

SSL_CERT_FILE/SSL_CERT_PATH for self-signed API server certificate

Because Golang 1.9 added support for the environment variables SSL_CERT_FILE and SSL_CERT_PATH on Unix systems, it is now possible to use these when targeting a CF API endpoint that uses a self-signed certficate.
This is particularly useful in a CI environment without root access, where the existing method of registering the certificate in the local truststore<http://docs.cloudfoundry.org/cf-cli/self-signed.html> is not possible. (#1084<https://github.com/cloudfoundry/cli/issues/1084>)

Note that this is supported since the previous cf CLI release (6.31.0).

Refactored commands

We are in the process of creating a more consistent user experience; our goal is to standardize UI output.
For example, warnings and errors will consistently be outputted to stderr instead of stdout and English table and key-value headers displayed in lowercase.
As we iterate through the list of commands, we are also focusing on improving performance and stability.
Please review your scripts if they depend on the output of these commands.

List of improved commands in this release:

* create-route
* orgs
* spaces

Updated commands

* spaces now displays an error when the authentication tokens have expired. (#1051<https://github.com/cloudfoundry/cli/issues/1051>)
* spaces now displays an error when receiving an unexpected response from the API endpoint. (#1136<https://github.com/cloudfoundry/cli/issues/1136>)

New & updated community plugins

* cflocal<https://github.com/sclevine/cflocal> v0.14.0 - Stage and launch CF apps, push and pull droplets, and connect to real CF services -- in Docker
* open<https://github.com/cloudfoundry-community/cf-plugin-open> v1.2.1 - Open App URLs + Service dashboards in browser
* fastpush<https://github.com/xiwenc/cf-fastpush-plugin> v1.1.0 - Fast, non-persistent, smart and incrementally updating of your application
Enjoy!

Regards,
Dies Koper
Cloud Foundry Product Manager - CLI

2101 - 2120 of 9425