Date   

Re: v3 cc api style guide feedback requested

Guillaume Berche
 

On Wed, Sep 9, 2015 at 10:39 AM, Dieu Cao <dcao(a)pivotal.io> wrote:

Hi Guillaume,

Just to ensure that it will be addressed, could you add it as github
issues on the repo? Hoping to do another pass at the remaining open issues
later this week.

-Dieu

On Mon, Sep 7, 2015 at 2:09 PM, Guillaume Berche <bercheg(a)gmail.com>
wrote:

Thanks for sharing this great spec.

Not sure if you're preferring feedback other the mailing list of GH
issue. Let me know.

General feedback:

+1 for a formal schema for the v3 api as to ease automatic client
generations (api explorer, java sdk, go sdk...) (e.g. swagger format)
Automated tests on the formal schema may also help checking the style guide
is respected. https://www.pivotaltracker.com/story/show/99237980 seems
to only consider documentation benefits so far and not yet client
generation benefits (e.g. https://github.com/swagger-api/swagger-codegen
https://github.com/swagger-api/swagger-codegen/issues/325 )

Would be nice to clarify support for non ascii characters in query
params, such as support for IRI
https://en.wikipedia.org/wiki/Internationalized_resource_identifier as
to avoid mojibake bugs such as the one presumed in
https://github.com/cloudfoundry/cli/issues/560

Would be nice to consider supporting gzip encoding for the json payload
responses as to speed up responses over internet connections
('Accept-Encoding' header)

It general it may make sense to clarify supported HTTP headers (+1 for
etag/if-modified-since support suggested at
https://github.com/cloudfoundry/cc-api-v3-style-guide/issues/2 ).

https://github.com/cloudfoundry/cc-api-v3-style-guide#pagination
*"order_by: a field on the resource to order the collection by; each
collection may choose a subset of fields that it can be sorted by "*

Would be nice to illustrate/precise if multiple sort order can be
supported, e.g. order_by=-state,-created

https://github.com/cloudfoundry/cc-api-v3-style-guide#query-parameters
Precise character escaping on query param values e.g. containing comma:
filtering on name="a,b"


https://github.com/cloudfoundry/cc-api-v3-style-guide#pagination-of-related-resources

GET /v3/apps/:guid?include=space,organization

with pluralized resource name should be GET /v3/apps/:guid?include=space
*s*,organization*s*


https://github.com/cloudfoundry/cc-api-v3-style-guide#pagination-of-related-resources
would be nice to include an example of a pagination request on a related
resource inclusion request (e.g,

/v2/spaces/ab09cd29-9420-f021-g20d-123431420768?include=apps&*include_apps_order_by*=-state,-date)

https://github.com/cloudfoundry/cc-api-v3-style-guide#proposal
Would useful to consider I18N of user-facing messages. Cf related thread
for service broker error messages at
http://cf-dev.70369.x6.nabble.com/cf-dev-Announcing-Experimental-support-for-Asynchronous-Service-Operations-tp287p1471.html
May be the CC API could accept a "Accept-Language: zh_Hans" header and
try to return localized messages when available in the accepted locale.

Thanks,

Guillaume.

On Wed, Sep 2, 2015 at 6:44 PM, Zach Robinson <zrobinson(a)pivotal.io>
wrote:

Thanks James, I've just corrected the three issues you've noted so far


tcp-routing in Lattice

Jack Cai
 

I'm playing around with the tcp-routing feature in the latest Lattice
release. I started two node.js applications in the pushed image (listening
on two ports), one mapped to an http route and the other to a tcp route. I
can connect to the http route successfully in the browser, but when I try
to connect to the tcp port in the browser, I got connection refused. It
looks like the mapped public tcp port on 192.168.11.11 is not open at all.
Any advice on how to diagnose this? Thanks in advance!

Jack


Re: Loggregator not accessible, errors in the logs

Rohit Kumar
 

Answers to your questions:

1. That error might be caused if your doppler servers aren't healthy and
therefore not listed in etcd. The traffic-controller polls etcd to discover
dopplers.
2. You do need metron and dopplers to access logs via "cf logs". The logs
are emitted by the DEA agent to metron, which forwards them to doppler
servers. Doppler servers deal with buffering logs (so that they are
accessible via the "cf logs --recent" command) and also deal with syslog
forwarding.

Thanks,
Rohit

On Wed, Sep 9, 2015 at 2:33 PM, kyle havlovitz <kylehav(a)gmail.com> wrote:

I'm seeing this message repeating over and over in the traffic controller
logs:
{"timestamp":1441830145.719944000,"process_id":32413,"source":"loggregator
trafficcontroller","log_level":"debug","message":"ServerAddressList.Run:
Unable to recursively find keys with prefix
/healthstatus/doppler","data":null,"file":"/opt/cloudfoundry/cf-release/src/loggregator/src/
github.com/cloudfoundry/loggregatorlib/servicediscovery/servicediscovery.go
","line":78,"method":"
github.com/cloudfoundry/loggregatorlib/servicediscovery.(*serverAddressList).DiscoverAddresses
"}

Here's my config:

"EtcdUrls" : ["http://localhost:4001"],
"EtcdMaxConcurrentRequests" : 10,
"WSMessageBufferSize": 100,
"OutgoingDropsondePort": 8082,
"DopplerPort": 8082,
"IncomingPort": 3456,
"OutgoingPort": 9090,
"SkipCertVerify": true,
"Index": 0,
"MaxRetainedLogMessages": 100,
"SharedSecret": "secret",
"Host": "0.0.0.0",
"SystemDomain": "local.example.com",
"ApiHost": "http://127.0.0.1:8181",

"NatsHosts": ["127.0.0.1"],
"NatsPort": 4222,
"NatsUser": "nats",
"NatsPass": "password",
"VarzUser": "varz",
"VarzPass": "password",
"VarzPort": 8888,
"MetronPort": 3457,
"Syslog" : "",
"Zone": "CRAZY_TOWN",

"UaaHost": "http://localhost:8080",
"UaaClientId": "doppler",
"UaaClientSecret": "tokensecret"
}

I have all the components running locally, using cf-release 215. I have
two questions:
1. what's causing this error?
2. if all I want out of the system are logs (via cf logs command), can I
get away with just having a traffic controller and dea agent running or do
I need metron and doppler?


Loggregator not accessible, errors in the logs

kyle havlovitz <kylehav@...>
 

I'm seeing this message repeating over and over in the traffic controller
logs:
{"timestamp":1441830145.719944000,"process_id":32413,"source":"loggregator
trafficcontroller","log_level":"debug","message":"ServerAddressList.Run:
Unable to recursively find keys with prefix
/healthstatus/doppler","data":null,"file":"/opt/cloudfoundry/cf-release/src/loggregator/src/
github.com/cloudfoundry/loggregatorlib/servicediscovery/servicediscovery.go
","line":78,"method":"
github.com/cloudfoundry/loggregatorlib/servicediscovery.(*serverAddressList).DiscoverAddresses
"}

Here's my config:

"EtcdUrls" : ["http://localhost:4001"],
"EtcdMaxConcurrentRequests" : 10,
"WSMessageBufferSize": 100,
"OutgoingDropsondePort": 8082,
"DopplerPort": 8082,
"IncomingPort": 3456,
"OutgoingPort": 9090,
"SkipCertVerify": true,
"Index": 0,
"MaxRetainedLogMessages": 100,
"SharedSecret": "secret",
"Host": "0.0.0.0",
"SystemDomain": "local.example.com",
"ApiHost": "http://127.0.0.1:8181",

"NatsHosts": ["127.0.0.1"],
"NatsPort": 4222,
"NatsUser": "nats",
"NatsPass": "password",
"VarzUser": "varz",
"VarzPass": "password",
"VarzPort": 8888,
"MetronPort": 3457,
"Syslog" : "",
"Zone": "CRAZY_TOWN",

"UaaHost": "http://localhost:8080",
"UaaClientId": "doppler",
"UaaClientSecret": "tokensecret"
}

I have all the components running locally, using cf-release 215. I have two
questions:
1. what's causing this error?
2. if all I want out of the system are logs (via cf logs command), can I
get away with just having a traffic controller and dea agent running or do
I need metron and doppler?


Re: Cloud Foundry NodeJS 4 support and release schedule

Shawn Nielsen
 

Thanks for the quick feedback on this, we appreciate your responsiveness.
We'll continue to follow the issue in the pivotal tracker.

On Wed, Sep 9, 2015 at 12:36 PM, Mike Dalessio <mdalessio(a)pivotal.io> wrote:

Hi Shawn,

Great question, thanks for asking it.

The Buildpacks team has a Tracker story in its backlog to work on Node 4:

https://www.pivotaltracker.com/story/show/102941608

Generally our turnaround time on vanilla version updates is less than a
day; however, Node 4 isn't just a regular version update, as it comes from
io.js lineage which we haven't ever officially supported; and so we're
going to proceed carefully.

The story I linked to has some specific acceptance criteria:

* Does the binary build with our current tooling? If not, we'll have to
update our tooling.
* Does the binary dynamically link openssl? (This was a specific use case
we've had to work around in the past.) If not, we'll have to make sure it
does, so that rootfs updates will be sufficient to address openssl CVEs.
* Does the binary avoid statically linking any other rootfs libraries? If
not, see above.
* Does the binary pass BRATs? If not, we'll have to fix BRATs.

Only when all of the above look good will we ship; and since we haven't
worked with io.js and family before, I don't want to make any promises
about delivery. If things go well, it could ship as early as tomorrow,
though that's probably overly optimistic.

Additionally I'll likely delay committing it into cf-release until we have
positive feedback from the community.

I'm happy to keep this thread updated with our progress; or you can follow
along at the Tracker story.

Cheers,
-mike


On Wed, Sep 9, 2015 at 11:33 AM, Shawn Nielsen <sknielse(a)gmail.com> wrote:

NodeJS version 4 was released yesterday to the community.

Generally speaking, what is the typical release schedule for buildpack
binaries after new runtime releases are announced?

More specifically, I'd be curious if you have information on release
schedule of the NodeJS 4 buildpack binaries.






consolidated routing api

Shannon Coen
 

We currently have two routing APIs in CF.
1. HTTP Routing API in cf-release:
https://github.com/cloudfoundry-incubator/routing-api
2. TCP Routing API in cf-routing-release:
https://github.com/cloudfoundry-incubator/cf-routing-release

The TCP Routing API is quite basic and we want to extend it for high
availability, authentication, etc. However, instead of enhancing the
existing TCP Routing API, we plan to add support for TCP route registration
to the Routing API in cf-release, as it already supports many of the
desired features. We'll get rid of the current API in cf-routing-release
and submodule in the Routing API from cf-release. Eventually we'll move the
Routing API (along with GoRouter and HAProxy) from cf-release into
cf-routing-release and submodule them into cf-release.

This consolidation, along with our not having any API consumer besides
GoRouter yet, gives us the opportunity to consider a common behavior for
routing API endpoints. We welcome your comments in our design doc:

https://docs.google.com/document/d/1v941oy3Y7RRI80gmLfhPZlaahElK_Q0C3pCQewK8Z3g/edit?usp=sharing

Thank you,

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.


Re: Cloud Foundry NodeJS 4 support and release schedule

Mike Dalessio
 

Hi Shawn,

Great question, thanks for asking it.

The Buildpacks team has a Tracker story in its backlog to work on Node 4:

https://www.pivotaltracker.com/story/show/102941608

Generally our turnaround time on vanilla version updates is less than a
day; however, Node 4 isn't just a regular version update, as it comes from
io.js lineage which we haven't ever officially supported; and so we're
going to proceed carefully.

The story I linked to has some specific acceptance criteria:

* Does the binary build with our current tooling? If not, we'll have to
update our tooling.
* Does the binary dynamically link openssl? (This was a specific use case
we've had to work around in the past.) If not, we'll have to make sure it
does, so that rootfs updates will be sufficient to address openssl CVEs.
* Does the binary avoid statically linking any other rootfs libraries? If
not, see above.
* Does the binary pass BRATs? If not, we'll have to fix BRATs.

Only when all of the above look good will we ship; and since we haven't
worked with io.js and family before, I don't want to make any promises
about delivery. If things go well, it could ship as early as tomorrow,
though that's probably overly optimistic.

Additionally I'll likely delay committing it into cf-release until we have
positive feedback from the community.

I'm happy to keep this thread updated with our progress; or you can follow
along at the Tracker story.

Cheers,
-mike

On Wed, Sep 9, 2015 at 11:33 AM, Shawn Nielsen <sknielse(a)gmail.com> wrote:

NodeJS version 4 was released yesterday to the community.

Generally speaking, what is the typical release schedule for buildpack
binaries after new runtime releases are announced?

More specifically, I'd be curious if you have information on release
schedule of the NodeJS 4 buildpack binaries.






Re: Cloud Foundry NodeJS 4 support and release schedule

James Thomas <jthomas.uk@...>
 

I was playing around this morning using the Heroku Node.js binaries for v4
with the existing CF Node.js buildpack.
https://github.com/jthomas/nodejs-v4-buildpack/commit/e2b6887638af1be2e472f989b3d005a0e33fb787

It worked perfectly with my test app.

On 9 September 2015 at 17:16, Juan Antonio Breña Moral <
bren(a)juanantonio.info> wrote:

Nice news!

In my side, I am working on a Node Client for Cloud foundry:
https://github.com/jabrena/cf-nodejs-client

and a webApp to deploy in a easy way applications:
https://github.com/prosociallearnEU/cf-nodejs-dashboard

Regards

Juan Antonio


--
Regards,
James Thomas


Business Contacts

Adam Park <adam.park@...>
 

Hi,



Would you be interested acquiring business databases for your sales and
marketing initiatives? I hope you are the right person to discuss about this
in your company? If not please refer me to the right person to discuss
further about our services.



Acquire Databases in excel spread sheet format:



All Business Executives Retail Executives Pharma Executives Biotech Users
E-commerce Users Technology Key Decision Makers Travel & Transportation
Users Oil and Gas Databases Insurance Agents and Brokers Hospital Databases
Doctors and Physicians Manufacturing Databases and Many more...



Let me know target specifications such as targeted Geographies, Industries,
Titles/job roles, Company Size (Revenue/Employees), etc & I will get back to
you with counts & pricing for the same.



Thanks and looking forward to hearing from you!



Best Regards,

Adam Park


Business Development



Note: You were specifically sent this email based upon your company profile.
If for some reason this was sent in error or you wish not to receive any
further messages from us please reply with subject line as "Exclude" or
click here to UNSUBSCRIBE
<mailto:infyunsubscribe(a)gmail.com?subject=UNSUBSCRIE> to exclude from all
future mailings.


Re: Cloud Foundry NodeJS 4 support and release schedule

Juan Antonio Breña Moral <bren at juanantonio.info...>
 

Nice news!

In my side, I am working on a Node Client for Cloud foundry:
https://github.com/jabrena/cf-nodejs-client

and a webApp to deploy in a easy way applications:
https://github.com/prosociallearnEU/cf-nodejs-dashboard

Regards

Juan Antonio


Cloud Foundry NodeJS 4 support and release schedule

Shawn Nielsen
 

NodeJS version 4 was released yesterday to the community.

Generally speaking, what is the typical release schedule for buildpack
binaries after new runtime releases are announced?

More specifically, I'd be curious if you have information on release
schedule of the NodeJS 4 buildpack binaries.


Re: Application only starts when a bogus service is attached

Amit Kumar Gupta
 

Okay, great!

Thanks,
Amit

On Wed, Sep 9, 2015 at 4:35 AM, Fabien LEBRERE <yop190(a)gmail.com> wrote:

Hi Amit,

Sorry, you right.
In fact, I'm an user of the CF' Ramon installation ;)

Daniel has solve my problems with the last link (JAVA_OPTS
"-Djava.security.egd=file:///dev/urandom").

Cheers
Fabien


cf push hanged in after package donwload

Xiao
 

Hi expert,my env:cf 213 vsphere 5.5
After redeploy CF in a new environment,  testing spring-music as the first app. When run cf push, get below issue:------------------------------------
$ cf pushUsing manifest file /home/david/spring-music-master/manifest.yml
Creating app spring-ca in org pivotal / space space01 as admin...OK
Creating route spring-ca-1234.192.168.2.33.xip.io...OK
Binding spring-ca-1234.192.168.2.33.xip.io to spring-ca...OK
Uploading spring-ca...Uploading app files from: /home/david/spring-music-master/build/libs/spring-music.warUploading 576.9K, 90 filesDone uploadingOK
Starting app spring-ca in org pivotal / space space01 as admin...-----> Downloaded app package (22M)
FAILEDspring-ca failed to stage within 15.000000 minutes--------------------------------------$ cf logs app spring-ca --recent dose not show valuable info
-------------------------------------
DEA config as below:dea_next:    advertise_interval_in_seconds: 5    allow_host_access: null    allow_networks: []    default_health_check_timeout: 60    deny_networks: []    directory_server_protocol: https    disk_mb: 30480    disk_overcommit_factor: 2    evacuation_bail_out_time_in_seconds: 600    heartbeat_interval_in_seconds: 10    instance_disk_inode_limit: 200000    kernel_network_tuning_enabled: true    logging_level: debug    memory_mb: 10240    memory_overcommit_factor: 3    rlimit_core: 0    staging_disk_inode_limit: 200000    staging_disk_limit_mb: 10000    staging_memory_limit_mb: 10240  description: Cloud Foundry sponsored by Pivotal  disk_quota_enabled: true--------------------------------------------------thanksDavid


Utilities PMC - 2015-09-09 Notes

Mike Dalessio
 

Hello CF Community,

Apologies for the lapse in sending timely Utilities PMC notes (see comments
below).

These notes are permanently available at:


https://github.com/cloudfoundry/pmc-notes/blob/master/Utilities/2015-09-09-utilities.md

-mike

---

# Utilities PMC Notes 2015-09-09

## Table of Contents

1. Update on "Offline" PMC Discussion
2. CLI
3. Java Utilities


## Update on "Offline" PMC Discussions

In the previous PMC meeting, held on 2015-07-28, the Utilities PMC agreed
to tentatively stop conducting regular synchronous meetings, and instead
move to an "offline" model where discussions and, if necessary, voting
would be conducted on the public cf-dev@ mailing list.

As part of this change, the PMC Lead (that's me!) committed to sending
regular status updates to the mailing list in lieu of meeting notes. In
this aspect, I failed over the last month, and I apologize for the
resulting lack of transparency.

Going forward, I'll return to a two-week cycle of email updates for this
PMC.

Please reach out to me or Chip if you have concerns over continuing the
"offline" model for the Utilities PMC.


## CLI

[CLI v6.12.3][] was released on August 31st, which notably includes many
community PRs and remove of codegangsta in preparation for an epic to
revamp `cf help`.

[CLI v6.12.3]: https://github.com/cloudfoundry/cli/releases/tag/v6.12.3

CLI has scheduled an inception on 2015-09-09 in San Francisco, Greg Oehmen
will be sending out details later this week.


## Java Utilities

Work continues on moving the Eclipse tools for Cloud Foundry to the Eclipse
Foundation. Immediate goal is inclusion in the Luna SR1 release.

The team is planning an inception for "v2" of `cf-java-client`. Immediate
goals will include support for CCv3 and to improve upon decisions made
during the initial implementation. We expect the inception planning process
to take some time, while some high-level design work is done to build
abstractions on top of a large number of API endpoints.


Re: UAA restart invalidates a valid token

Filip Hanik
 

After the fix, having override: true should not revoke the tokens. If it
still does, then it's a bug and we would like to know. thanks

On Wed, Sep 9, 2015 at 8:37 AM, Kayode Odeyemi <dreyemi(a)gmail.com> wrote:

Awesome.

option 2 is definitely the cause of the problem.

Thank you very much.

On Wed, Sep 9, 2015 at 4:32 PM, Filip Hanik <fhanik(a)pivotal.io> wrote:

We introduced a feature called 'revokable tokens'. A token would
automatically be revoked if a client changed it's secret. All tokens issued
previously would be automatically revoked.

In earlier versions of the UAA, if you have clients in your manifest, and
override flag set to true, even though the secret didn't change in the
manifest, the hashed secret was regenerated and thus this would expire all
the tokens.

you have a couple of different options
1. Update your UAA - this was fixed in
https://www.pivotaltracker.com/n/projects/997278/stories/97682912
2. Set override to false for your boot strapped clients and users



On Wed, Sep 9, 2015 at 8:22 AM, Kayode Odeyemi <dreyemi(a)gmail.com> wrote:

Hi,

What could cause a valid token to become invalid on UAA restart?

I've noticed this overtime, that a token (of client_credentials grant
type) which has a validity of 315360000 and has been used for
authentication and authorization of users and resource servers, suddenly
returns invalid_token when validated after a UAA restart.

{
"error": "invalid_token",
"error_description":
"eyJhbGciOiJIUzI1NiJ9.eyJqdGkiOiI2M2JlZjY0Yi0yZDgzLTRhOTEtOGRlOS00NjI1YWM1N2NiNjMiLCJzdWIiOiJ1c2VyYWNjb3VudCIsImF1dGhvcml0aWVzIjpbImNsaWVudHMucmVhZCIsInNjaW0udXNlcmlkcyIsImNsaWVudHMuc2VjcmV0IiwidWFhLnJlc291cmNlIiwic2NpbS5tZSIsIm9wZW5pZCIsInVhYS5hZG1pbiIsInNjaW0ucmVhZCIsInBhc3N3b3JkLndyaXRlIiwiY2xvdWRfY29udHJvbGxlci5yZWFkIiwiY2xvdWRfY29udHJvbGxlci53cml0ZSIsIm9hdXRoLmFwcHJvdmFscyIsImNsaWVudHMud3JpdGUiLCJzY2ltLndyaXRlIl0sInNjb3BlIjpbImNsaWVudHMucmVhZCIsInNjaW0udXNlcmlkcyIsImNsaWVudHMuc2VjcmV0IiwidWFhLnJlc291cmNlIiwic2NpbS5tZSIsIm9wZW5pZCIsInVhYS5hZG1pbiIsInNjaW0ucmVhZCIsInBhc3N3b3JkLndyaXRlIiwiY2xvdWRfY29udHJvbGxlci5yZWFkIiwiY2xvdWRfY29udHJvbGxlci53cml0ZSIsIm9hdXRoLmFwcHJvdmFscyIsImNsaWVudHMud3JpdGUiLCJzY2ltLndyaXRlIl0sImNsaWVudF9pZCI6InVzZXJhY2NvdW50IiwiY2lkIjoidXNlcmFjY291bnQiLCJhenAiOiJ1c2VyYWNjb3VudCIsImdyYW50X3R5cGUiOiJjbGllbnRfY3JlZGVudGlhbHMiLCJyZXZfc2lnIjoiNWQ4Yjg5NGUiLCJpYXQiOjE0NDEzNTk0NzUsImV4cCI6MTc1NjcxOTQ3NSwiaXNzIjoiaHR0cDovL2xvY2FsaG9zdDo4MDgwL3VhYS9vYXV0aC90b2tlbiIsInppZCI6InVhYSIsImF1ZCI6WyJ1c2VyYWNjb3VudCIsImNsaWVudHMiLCJzY2ltIiwidWFhIiwib3BlbmlkIiwicGFzc3dvcmQiLCJjbG91ZF9jb250cm9sbGVyIiwib2F1dGgiXX0.qnOvyxBNKkDADZ2ODyQfZ98nj7cqoSGMIouduERU3Vg"
}

Any ideas please?


Re: UAA restart invalidates a valid token

Paul Bakare
 

Awesome.

option 2 is definitely the cause of the problem.

Thank you very much.

On Wed, Sep 9, 2015 at 4:32 PM, Filip Hanik <fhanik(a)pivotal.io> wrote:

We introduced a feature called 'revokable tokens'. A token would
automatically be revoked if a client changed it's secret. All tokens issued
previously would be automatically revoked.

In earlier versions of the UAA, if you have clients in your manifest, and
override flag set to true, even though the secret didn't change in the
manifest, the hashed secret was regenerated and thus this would expire all
the tokens.

you have a couple of different options
1. Update your UAA - this was fixed in
https://www.pivotaltracker.com/n/projects/997278/stories/97682912
2. Set override to false for your boot strapped clients and users



On Wed, Sep 9, 2015 at 8:22 AM, Kayode Odeyemi <dreyemi(a)gmail.com> wrote:

Hi,

What could cause a valid token to become invalid on UAA restart?

I've noticed this overtime, that a token (of client_credentials grant
type) which has a validity of 315360000 and has been used for
authentication and authorization of users and resource servers, suddenly
returns invalid_token when validated after a UAA restart.

{
"error": "invalid_token",
"error_description":
"eyJhbGciOiJIUzI1NiJ9.eyJqdGkiOiI2M2JlZjY0Yi0yZDgzLTRhOTEtOGRlOS00NjI1YWM1N2NiNjMiLCJzdWIiOiJ1c2VyYWNjb3VudCIsImF1dGhvcml0aWVzIjpbImNsaWVudHMucmVhZCIsInNjaW0udXNlcmlkcyIsImNsaWVudHMuc2VjcmV0IiwidWFhLnJlc291cmNlIiwic2NpbS5tZSIsIm9wZW5pZCIsInVhYS5hZG1pbiIsInNjaW0ucmVhZCIsInBhc3N3b3JkLndyaXRlIiwiY2xvdWRfY29udHJvbGxlci5yZWFkIiwiY2xvdWRfY29udHJvbGxlci53cml0ZSIsIm9hdXRoLmFwcHJvdmFscyIsImNsaWVudHMud3JpdGUiLCJzY2ltLndyaXRlIl0sInNjb3BlIjpbImNsaWVudHMucmVhZCIsInNjaW0udXNlcmlkcyIsImNsaWVudHMuc2VjcmV0IiwidWFhLnJlc291cmNlIiwic2NpbS5tZSIsIm9wZW5pZCIsInVhYS5hZG1pbiIsInNjaW0ucmVhZCIsInBhc3N3b3JkLndyaXRlIiwiY2xvdWRfY29udHJvbGxlci5yZWFkIiwiY2xvdWRfY29udHJvbGxlci53cml0ZSIsIm9hdXRoLmFwcHJvdmFscyIsImNsaWVudHMud3JpdGUiLCJzY2ltLndyaXRlIl0sImNsaWVudF9pZCI6InVzZXJhY2NvdW50IiwiY2lkIjoidXNlcmFjY291bnQiLCJhenAiOiJ1c2VyYWNjb3VudCIsImdyYW50X3R5cGUiOiJjbGllbnRfY3JlZGVudGlhbHMiLCJyZXZfc2lnIjoiNWQ4Yjg5NGUiLCJpYXQiOjE0NDEzNTk0NzUsImV4cCI6MTc1NjcxOTQ3NSwiaXNzIjoiaHR0cDovL2xvY2FsaG9zdDo4MDgwL3VhYS9vYXV0aC90b2tlbiIsInppZCI6InVhYSIsImF1ZCI6WyJ1c2VyYWNjb3VudCIsImNsaWVudHMiLCJzY2ltIiwidWFhIiwib3BlbmlkIiwicGFzc3dvcmQiLCJjbG91ZF9jb250cm9sbGVyIiwib2F1dGgiXX0.qnOvyxBNKkDADZ2ODyQfZ98nj7cqoSGMIouduERU3Vg"
}

Any ideas please?


Buildpacks PMC - 2015-09-09 Notes

Mike Dalessio
 

Hello CF community,

Apologies for the lapse in sending timely Buildpacks PMC notes (see
comments below).

These notes are permanently available at:


https://github.com/cloudfoundry/pmc-notes/blob/master/Buildpacks/2015-09-09-buildpacks.md

-mike

-----

# Buildpacks PMC Notes as of 2015-09-09

## Table of Contents

1. Update on "Offline" PMC Discussion
2. Update on Stacks
3. Update on Buildpacks
1. General
2. go-buildpack
3. php-buildpack
4. ruby-buildpack
5. java-buildpack
4. Post-mortem on java-buildpack Certificate Expiration Incident


## Update on "Offline" PMC Discussions

In the previous PMC meeting, held on 2015-07-27, the Buildpacks PMC agreed
to tentatively stop conducting regular synchronous meetings, and instead
move to an "offline" model where discussions and, if necessary, voting
would be conducted on the public cf-dev@ mailing list.

As part of this change, the PMC Lead (that's me!) committed to sending
regular status updates to the mailing list in lieu of meeting notes. In
this aspect, I failed over the last month, and I apologize for the
resulting lack of transparency.

Going forward, I'll return to a two-week cycle of email updates for this
PMC.

Please reach out to me or Chip if you have concerns over continuing the
"offline" model for the Buildpacks PMC.


## Update on Stacks

[cflinuxfs2 v1.2.0][] through [cflinuxfs2 v1.7.0][] were released ([all
cflinuxfs2 releases][]), reflecting the team's focus on regular releases
and short turnaround times for CVEs.

[cflinuxfs2 v1.2.0]:
https://github.com/cloudfoundry/stacks/releases/tag/1.2.0
[cflinuxfs2 v1.7.0]:
https://github.com/cloudfoundry/stacks/releases/tag/1.7.0
[all cflinuxfs2 releases]: https://github.com/cloudfoundry/stacks/releases

One notable addition to the rootfs is the utility [jq][]. `jq` is commonly
vendored in custom buildpacks to parse CF environment variables (such as
`VCAP_SERVICES`). It's also used in the `go` buildpack to parse
`Godeps.json`. Adding `jq` to the rootfs is intended for use by future
buildpacks, to obviate the need to vendor a binary version of it.

[jq]: https://stedolan.github.io/jq/

Another notable change was introduced in [cflinuxfs2 v1.4.0][], which makes
it incompatible with Warden from cf212 and earlier. This change was
unfortunately necessary to support Garden and Diego. The release notes
contain instructions on how to modify Warden and cf-release if you need to
backport later rootfses into earlier cf-releases.

[cflinuxfs2 v1.4.0]:
https://github.com/cloudfoundry/stacks/releases/tag/1.4.0


## Update on Buildpacks

### General

Research continues on how to improve the state of extensibility for
Buildpacks. Tracker stories and their results are available in the
["architecture" epic][].

["architecture" epic]: https://www.pivotaltracker.com/epic/show/1898760


### go-buildpack

[go-buildpack v1.6.0][] and [go-buildpack v1.5.0][] were released. These
versions notably add support for golang 1.5.1, remove support for golang
1.1.x, update [godep][], and remove the vendored python interpreter.

[go-buildpack v1.6.0]:
https://github.com/cloudfoundry/go-buildpack/releases/tag/v1.6.0
[go-buildpack v1.5.0]:
https://github.com/cloudfoundry/go-buildpack/releases/tag/v1.5.0
[godep]: https://github.com/tools/godep


### php-buildpack

[php-buildpack 4.1.2][] was released. This version notably makes a
non-backwards compatible change to composer detection, updates nginx to
1.9.3, and bumps the supported PHP versions to 5.6.12, 5.5.28 and 5.4.44.

[php-buildpack 4.1.2]:
https://github.com/cloudfoundry/php-buildpack/releases/tag/v4.1.2

We expect to release 4.1.3 this week with further updates to supported PHP
versions and nginx version.

A short survey was sent to cf-dev@ this week to evaluate whether, and how,
to support HHVM going forward. Please respond if you're a PHP user.
([survey link][])

[survey link]:
https://docs.google.com/forms/d/1WBupympWFRMQnoGZAgQLKmUZugreVldj3xDhyn9kpWM/viewform?usp=send_form

Finally, a note that PHP 5.4.x will reach End Of Life on 2015-09-14 (that's
next week). Beginning with php-buildpack v4.1.3, deprecation warnings will
be emitted upon staging apps that use PHP 5.4. We intend to remove PHP
5.4.x support from the php-buildpack within a month after EOL.


### ruby-buildpack

[ruby-buildpack v1.6.2][] through [ruby-buildpack v1.6.7][] were released.
Notably, these versions add support for JRuby 9.0.1.0 and 1.7.22, Ruby
2.2.3, 2.1.7 and 2.0.0-p647, openjdk 1.8.0_51, and sets the default Ruby
version to 2.2.3.

[ruby-buildpack v1.6.7]:
https://github.com/cloudfoundry/ruby-buildpack/releases/tag/v1.6.7
[ruby-buildpack v1.6.2]:
https://github.com/cloudfoundry/ruby-buildpack/releases/tag/v1.6.2



### java-buildpack

[java-buildpack v3.1.1][] was released on July 30th, which updates
dependencies.

The java-buildpack team has also committed changes to `master` to add
zero-touch support for Safenet Luna HSMs, and to make a number of
improvements to the Java memory calculator.

[java-buildpack v3.1.1]:
https://github.com/cloudfoundry/java-buildpack/releases/tag/v3.1.1


## Post-mortem on java-buildpack Certificate Expiration Incident

On 2015-08-31, between 1300 UTC and 1554 UTC, applications failed to stage
that rely on an "online" (or "uncached") version of the java-buildpack, or
an "online" version of the ruby-buildpack who are using JRuby.

The root cause of this incident was the expiration of the SSL certificate
for `download.run.pivotal.io`, which is a domain used to front the
artifacts downloaded by the java-buildpack.

Two aspects of this incident were focused on during a post-mortem on
2015-09-09, to which Chip and Sam were invited.

1. __The certificate was allowed to expire__
2. __An open-source buildpack is relying on a Pivotal-managed domain and
SSL certificate__

The first aspect resulted in Pivotal-internal action items to centralize
cert management and to require an escalation policy for each cert. These
are perhaps uninteresting to most readers, but I'm happy to provide more
detail on request.

The second aspect is being addressed in part by [this Tracker story][] to
move to a Foundation-managed domain and cert.

[this Tracker story]:
https://www.pivotaltracker.com/n/projects/788065/stories/102935172

Ben Hale and I will be working with Chip and the Foundation to remove the
dependency on this domain as quickly as we can; and Pivotal is committing
to maintaining that domain and cert so existing buildpacks will continue to
work until users are migrated to updated versions.

One open question that was raised during the post-mortem: How can we better
communicate urgent issues like this to the CF community? The cf-dev@ list
tends to be a bit noisy, and isn't commonly used for urgent communications.
If anyone has ideas for how we can better respond as a community, I'd love
to hear your ideas.


Re: UAA restart invalidates a valid token

Filip Hanik
 

We introduced a feature called 'revokable tokens'. A token would
automatically be revoked if a client changed it's secret. All tokens issued
previously would be automatically revoked.

In earlier versions of the UAA, if you have clients in your manifest, and
override flag set to true, even though the secret didn't change in the
manifest, the hashed secret was regenerated and thus this would expire all
the tokens.

you have a couple of different options
1. Update your UAA - this was fixed in
https://www.pivotaltracker.com/n/projects/997278/stories/97682912
2. Set override to false for your boot strapped clients and users

On Wed, Sep 9, 2015 at 8:22 AM, Kayode Odeyemi <dreyemi(a)gmail.com> wrote:

Hi,

What could cause a valid token to become invalid on UAA restart?

I've noticed this overtime, that a token (of client_credentials grant
type) which has a validity of 315360000 and has been used for
authentication and authorization of users and resource servers, suddenly
returns invalid_token when validated after a UAA restart.

{
"error": "invalid_token",
"error_description":
"eyJhbGciOiJIUzI1NiJ9.eyJqdGkiOiI2M2JlZjY0Yi0yZDgzLTRhOTEtOGRlOS00NjI1YWM1N2NiNjMiLCJzdWIiOiJ1c2VyYWNjb3VudCIsImF1dGhvcml0aWVzIjpbImNsaWVudHMucmVhZCIsInNjaW0udXNlcmlkcyIsImNsaWVudHMuc2VjcmV0IiwidWFhLnJlc291cmNlIiwic2NpbS5tZSIsIm9wZW5pZCIsInVhYS5hZG1pbiIsInNjaW0ucmVhZCIsInBhc3N3b3JkLndyaXRlIiwiY2xvdWRfY29udHJvbGxlci5yZWFkIiwiY2xvdWRfY29udHJvbGxlci53cml0ZSIsIm9hdXRoLmFwcHJvdmFscyIsImNsaWVudHMud3JpdGUiLCJzY2ltLndyaXRlIl0sInNjb3BlIjpbImNsaWVudHMucmVhZCIsInNjaW0udXNlcmlkcyIsImNsaWVudHMuc2VjcmV0IiwidWFhLnJlc291cmNlIiwic2NpbS5tZSIsIm9wZW5pZCIsInVhYS5hZG1pbiIsInNjaW0ucmVhZCIsInBhc3N3b3JkLndyaXRlIiwiY2xvdWRfY29udHJvbGxlci5yZWFkIiwiY2xvdWRfY29udHJvbGxlci53cml0ZSIsIm9hdXRoLmFwcHJvdmFscyIsImNsaWVudHMud3JpdGUiLCJzY2ltLndyaXRlIl0sImNsaWVudF9pZCI6InVzZXJhY2NvdW50IiwiY2lkIjoidXNlcmFjY291bnQiLCJhenAiOiJ1c2VyYWNjb3VudCIsImdyYW50X3R5cGUiOiJjbGllbnRfY3JlZGVudGlhbHMiLCJyZXZfc2lnIjoiNWQ4Yjg5NGUiLCJpYXQiOjE0NDEzNTk0NzUsImV4cCI6MTc1NjcxOTQ3NSwiaXNzIjoiaHR0cDovL2xvY2FsaG9zdDo4MDgwL3VhYS9vYXV0aC90b2tlbiIsInppZCI6InVhYSIsImF1ZCI6WyJ1c2VyYWNjb3VudCIsImNsaWVudHMiLCJzY2ltIiwidWFhIiwib3BlbmlkIiwicGFzc3dvcmQiLCJjbG91ZF9jb250cm9sbGVyIiwib2F1dGgiXX0.qnOvyxBNKkDADZ2ODyQfZ98nj7cqoSGMIouduERU3Vg"
}

Any ideas please?


UAA restart invalidates a valid token

Paul Bakare
 

Hi,

What could cause a valid token to become invalid on UAA restart?

I've noticed this overtime, that a token (of client_credentials grant type)
which has a validity of 315360000 and has been used for authentication and
authorization of users and resource servers, suddenly returns invalid_token
when validated after a UAA restart.

{
"error": "invalid_token",
"error_description":
"eyJhbGciOiJIUzI1NiJ9.eyJqdGkiOiI2M2JlZjY0Yi0yZDgzLTRhOTEtOGRlOS00NjI1YWM1N2NiNjMiLCJzdWIiOiJ1c2VyYWNjb3VudCIsImF1dGhvcml0aWVzIjpbImNsaWVudHMucmVhZCIsInNjaW0udXNlcmlkcyIsImNsaWVudHMuc2VjcmV0IiwidWFhLnJlc291cmNlIiwic2NpbS5tZSIsIm9wZW5pZCIsInVhYS5hZG1pbiIsInNjaW0ucmVhZCIsInBhc3N3b3JkLndyaXRlIiwiY2xvdWRfY29udHJvbGxlci5yZWFkIiwiY2xvdWRfY29udHJvbGxlci53cml0ZSIsIm9hdXRoLmFwcHJvdmFscyIsImNsaWVudHMud3JpdGUiLCJzY2ltLndyaXRlIl0sInNjb3BlIjpbImNsaWVudHMucmVhZCIsInNjaW0udXNlcmlkcyIsImNsaWVudHMuc2VjcmV0IiwidWFhLnJlc291cmNlIiwic2NpbS5tZSIsIm9wZW5pZCIsInVhYS5hZG1pbiIsInNjaW0ucmVhZCIsInBhc3N3b3JkLndyaXRlIiwiY2xvdWRfY29udHJvbGxlci5yZWFkIiwiY2xvdWRfY29udHJvbGxlci53cml0ZSIsIm9hdXRoLmFwcHJvdmFscyIsImNsaWVudHMud3JpdGUiLCJzY2ltLndyaXRlIl0sImNsaWVudF9pZCI6InVzZXJhY2NvdW50IiwiY2lkIjoidXNlcmFjY291bnQiLCJhenAiOiJ1c2VyYWNjb3VudCIsImdyYW50X3R5cGUiOiJjbGllbnRfY3JlZGVudGlhbHMiLCJyZXZfc2lnIjoiNWQ4Yjg5NGUiLCJpYXQiOjE0NDEzNTk0NzUsImV4cCI6MTc1NjcxOTQ3NSwiaXNzIjoiaHR0cDovL2xvY2FsaG9zdDo4MDgwL3VhYS9vYXV0aC90b2tlbiIsInppZCI6InVhYSIsImF1ZCI6WyJ1c2VyYWNjb3VudCIsImNsaWVudHMiLCJzY2ltIiwidWFhIiwib3BlbmlkIiwicGFzc3dvcmQiLCJjbG91ZF9jb250cm9sbGVyIiwib2F1dGgiXX0.qnOvyxBNKkDADZ2ODyQfZ98nj7cqoSGMIouduERU3Vg"
}

Any ideas please?


Re: Application only starts when a bogus service is attached

Fabien LEBRERE
 

Hi Amit,

Sorry, you right.
In fact, I'm an user of the CF' Ramon installation ;)

Daniel has solve my problems with the last link (JAVA_OPTS "-Djava.security.egd=file:///dev/urandom").

Cheers
Fabien

7821 - 7840 of 9425