Date   

Re: Introducing OSS Release Integration Team

Noburou TANIGUCHI
 

Thank you for the scrupulous answer, Amit.
(I apologize this late response)



--
View this message in context: http://cf-dev.70369.x6.nabble.com/cf-dev-Introducing-OSS-Release-Integration-Team-tp757p805.html
Sent from the CF Dev mailing list archive at Nabble.com.


Re: Allow gorouter to log random headers.

Shannon Coen
 

I don't see the difference between WAKAWAKA and X-Cf-Requestid. Gorouter
would have to add some header with a uuid for the request. Your apps have
to have logic to pass this header on, so that a log search returns the
original request as well as subsequent requests between apps. Could you
please clarify?

Thank you,

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

On Tue, Jul 21, 2015 at 11:09 AM, Simon Johansson <simon(a)simonjohansson.com>
wrote:

Sure that header can be used. But then we are adding CF specific stuff
into the implementation of our services, which is something we want to
avoid at all costs.
Also Im not entirely sure if all the libraries we use for Zipkin supports
using custom headers.

All our public apps are fronted by different CDNs, which sets headers that
we might want to store for debugging, so we still need a way to pass those
trough into the log.

On Tuesday, 21 July 2015, Shannon Coen <scoen(a)pivotal.io> wrote:

Hello Simon,

The X-Cf-Requestid header already provides a uuid. Couldn't app "a" add
the value of X-Cf-Requestid to a header of your choosing? Call it WAKAWAKA
or X-Random-Header, but it doesn't need to be a platform standard. Wouldn't
a search for the value of X-Cf-Requestid then provide the desired results?

Thank you,
Shannon

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

On Tue, Jul 21, 2015 at 6:06 AM, Simon Johansson <
simon(a)simonjohansson.com> wrote:

Howdie!

We have some devs who want to be able to trace a request troughout their
applications.

user -> a -> b -> c
|
|-> d -> e

When a user makes a request to "a" uuid is generated inside the app, and
the request to "b" from "a" will set a header(call it WAKAWAKA to uuid),
"b"'s call will passthrough WAKAWAKA to "c" and "d", "d" will passthrough
WAKAWAKA to "e". Etc.

We aggregate all RTR logs into ELK so it would be super helpful to them
to be able to filter on WAKAWAKA and get all the access logs(and app logs
aswell, they mostly use GELF so its easy for them to add whatewher field
they want) from the services involved.

I had a quick peek at the gorouter(
https://github.com/cloudfoundry/gorouter/blob/76668f5818ea8c089ff52a14fcdfbf703c8e8767/access_log/access_log_record.go#L40)
and it seems like this should be a simple PR.

1. To gorouter.yml add
passthrough_headers:
- WAKAWAKA
- X-Random-Header

2. In makeRecord at the bottom add something like(in psuedo)

data = {}
for header in passthrough_headers:
header_val = r.FormatRequestHeader("X-Forwarded-For")
if header_val:
passthrough_headers[header] = header_val

if data:
fmt.Fprintf(b, data.to_stringified_json())

That would yield a log line like
blurgh.dev.cf.private.domain.com - [21/07/2015:10:17:05 +0000] "GET
/statements?ascending=true&since=2015-06-30T14%3A10%3A03.078Z&skipStatementId=30a88204-0779-4385-9859-e4aabd30baf0
HTTP/1.1" 200 0 17 "-" "NING/1.0" 10.230.31.2:46204 x_forwarded_for:"-"
vcap_request_id:1e58195a-cde6-4afd-7f03-43061c9ea91c
response_time:0.004927106 app_id:9784cd03-050d-4b74-9e90-5f17134a3f08
{"WAKAWAKA": "Space is the place", "X-Random-Header": "Once upon a midnight
dreary, while I pondered weak and weary"}

The reason for a stringified JSON is to make it easy to parse with
logstash or other loganalysis tools.

Before I spend time implementing, is this something you would merge?

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


Re: Allow gorouter to log random headers.

Simon Johansson <simon@...>
 

Sure that header can be used. But then we are adding CF specific stuff into
the implementation of our services, which is something we want to avoid at
all costs.
Also Im not entirely sure if all the libraries we use for Zipkin supports
using custom headers.

All our public apps are fronted by different CDNs, which sets headers that
we might want to store for debugging, so we still need a way to pass those
trough into the log.

On Tuesday, 21 July 2015, Shannon Coen <scoen(a)pivotal.io> wrote:

Hello Simon,

The X-Cf-Requestid header already provides a uuid. Couldn't app "a" add
the value of X-Cf-Requestid to a header of your choosing? Call it WAKAWAKA
or X-Random-Header, but it doesn't need to be a platform standard. Wouldn't
a search for the value of X-Cf-Requestid then provide the desired results?

Thank you,
Shannon

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

On Tue, Jul 21, 2015 at 6:06 AM, Simon Johansson <simon(a)simonjohansson.com
wrote:
Howdie!

We have some devs who want to be able to trace a request troughout their
applications.

user -> a -> b -> c
|
|-> d -> e

When a user makes a request to "a" uuid is generated inside the app, and
the request to "b" from "a" will set a header(call it WAKAWAKA to uuid),
"b"'s call will passthrough WAKAWAKA to "c" and "d", "d" will passthrough
WAKAWAKA to "e". Etc.

We aggregate all RTR logs into ELK so it would be super helpful to them
to be able to filter on WAKAWAKA and get all the access logs(and app logs
aswell, they mostly use GELF so its easy for them to add whatewher field
they want) from the services involved.

I had a quick peek at the gorouter(
https://github.com/cloudfoundry/gorouter/blob/76668f5818ea8c089ff52a14fcdfbf703c8e8767/access_log/access_log_record.go#L40)
and it seems like this should be a simple PR.

1. To gorouter.yml add
passthrough_headers:
- WAKAWAKA
- X-Random-Header

2. In makeRecord at the bottom add something like(in psuedo)

data = {}
for header in passthrough_headers:
header_val = r.FormatRequestHeader("X-Forwarded-For")
if header_val:
passthrough_headers[header] = header_val

if data:
fmt.Fprintf(b, data.to_stringified_json())

That would yield a log line like
blurgh.dev.cf.private.domain.com - [21/07/2015:10:17:05 +0000] "GET
/statements?ascending=true&since=2015-06-30T14%3A10%3A03.078Z&skipStatementId=30a88204-0779-4385-9859-e4aabd30baf0
HTTP/1.1" 200 0 17 "-" "NING/1.0" 10.230.31.2:46204 x_forwarded_for:"-"
vcap_request_id:1e58195a-cde6-4afd-7f03-43061c9ea91c
response_time:0.004927106 app_id:9784cd03-050d-4b74-9e90-5f17134a3f08
{"WAKAWAKA": "Space is the place", "X-Random-Header": "Once upon a midnight
dreary, while I pondered weak and weary"}

The reason for a stringified JSON is to make it easy to parse with
logstash or other loganalysis tools.

Before I spend time implementing, is this something you would merge?

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


Re: Allow gorouter to log random headers.

Shannon Coen
 

Hello Simon,

The X-Cf-Requestid header already provides a uuid. Couldn't app "a" add the
value of X-Cf-Requestid to a header of your choosing? Call it WAKAWAKA or
X-Random-Header, but it doesn't need to be a platform standard. Wouldn't a
search for the value of X-Cf-Requestid then provide the desired results?

Thank you,
Shannon

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

On Tue, Jul 21, 2015 at 6:06 AM, Simon Johansson <simon(a)simonjohansson.com>
wrote:

Howdie!

We have some devs who want to be able to trace a request troughout their
applications.

user -> a -> b -> c
|
|-> d -> e

When a user makes a request to "a" uuid is generated inside the app, and
the request to "b" from "a" will set a header(call it WAKAWAKA to uuid),
"b"'s call will passthrough WAKAWAKA to "c" and "d", "d" will passthrough
WAKAWAKA to "e". Etc.

We aggregate all RTR logs into ELK so it would be super helpful to them to
be able to filter on WAKAWAKA and get all the access logs(and app logs
aswell, they mostly use GELF so its easy for them to add whatewher field
they want) from the services involved.

I had a quick peek at the gorouter(
https://github.com/cloudfoundry/gorouter/blob/76668f5818ea8c089ff52a14fcdfbf703c8e8767/access_log/access_log_record.go#L40)
and it seems like this should be a simple PR.

1. To gorouter.yml add
passthrough_headers:
- WAKAWAKA
- X-Random-Header

2. In makeRecord at the bottom add something like(in psuedo)

data = {}
for header in passthrough_headers:
header_val = r.FormatRequestHeader("X-Forwarded-For")
if header_val:
passthrough_headers[header] = header_val

if data:
fmt.Fprintf(b, data.to_stringified_json())

That would yield a log line like
blurgh.dev.cf.private.domain.com - [21/07/2015:10:17:05 +0000] "GET
/statements?ascending=true&since=2015-06-30T14%3A10%3A03.078Z&skipStatementId=30a88204-0779-4385-9859-e4aabd30baf0
HTTP/1.1" 200 0 17 "-" "NING/1.0" 10.230.31.2:46204 x_forwarded_for:"-"
vcap_request_id:1e58195a-cde6-4afd-7f03-43061c9ea91c
response_time:0.004927106 app_id:9784cd03-050d-4b74-9e90-5f17134a3f08
{"WAKAWAKA": "Space is the place", "X-Random-Header": "Once upon a midnight
dreary, while I pondered weak and weary"}

The reason for a stringified JSON is to make it easy to parse with
logstash or other loganalysis tools.

Before I spend time implementing, is this something you would merge?

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


Re: Diego log grouping

MJ
 

The CF messages ingest OK into Splunk; None of the Diego messages ingest, not even the first line of their payload.

The problematic deployment:


· CF v212

· Stemcell 3012 (bosh-stemcell-3012-vsphere-esxi-ubuntu-trusty-go_agent.tgz)

· Diego 1304


An single CF syslog message payload:

2015-07-21T00:26:51.619730+00:00 10.5.139.228 vcap.hm9000.listener [job=hm9000_z1 index=1] {"timestamp":1437438411.619571447,"process_id":9750,"source":"vcap.hm9000.listener","log_level":"info","message":"Saved Heartbeats - {\"Duration\":\"217.887334ms\",\"Heartbeats to Save\":\"3\"}","data":null}

An single Diego syslog message payload:

2015-07-21T00:27:02.389177+00:00 10.5.139.241 vcap.receptor [job=cell_z1 index=1] {"timestamp":"1437438422.389095783","source":"receptor","message":"receptor.task-handler.get-all.succeeded-fetching-tasks-from-store","log_level":1,"data":{"domain":"","session":"3.3949"}}
<13>2015-07-21T00:27:02.389399+00:00 10.5.139.241 vcap.receptor [job=cell_z1 index=1] {"timestamp":"1437438422.389337301","source":"receptor","message":"receptor.request.done","log_level":1,"data":{"method":"GET","request":"/v1/tasks","session":"20204"}}
<13>2015-07-21T00:27:02.389982+00:00 10.5.139.241 vcap.receptor [job=cell_z1 index=1] {"timestamp":"1437438422.389916658","source":"receptor","message":"receptor.request.serving","log_level":1,"data":{"method":"GET","request":"/v1/desired_lrps","session":"20205"}}
<13>2015-07-21T00:27:02.620949+00:00 10.5.139.241 vcap.receptor [job=cell_z1 index=1] {"timestamp":"1437438422.620829105","source":"receptor","message":"receptor.request.done","log_level":1,"data":{"method":"GET","request":"/v1/desired_lrps","session":"20205"}}
<13>2015-07-21T00:27:02.621660+00:00 10.5.139.241 vcap.receptor [job=cell_z1 index=1] {"timestamp":"1437438422.621593714","source":"receptor","message":"receptor.request.serving","log_level":1,"data":{"method":"GET","request":"/v1/actual_lrps","session":"20206"}}
<13>2015-07-21T00:27:03.145810+00:00 10.5.139.241 vcap.receptor [job=cell_z1 index=1] {"timestamp":"1437438423.145678282","source":"receptor","message":"receptor.request.done","log_level":1,"data":{"method":"GET","request":"/v1/actual_lrps","session":"20206"}}
<13>2015-07-21T00:27:03.146939+00:00 10.5.139.241 vcap.receptor [job=cell_z1 index=1] {"timestamp":"1437438423.146871328","source":"receptor","message":"receptor.request.serving","log_level":1,"data":{"method":"GET","request":"/v1/domains","session":"20207"}}
<13>2015-07-21T00:27:03.192371+00:00 10.5.139.241 vcap.receptor [job=cell_z1 index=1] {"timestamp":"1437438423.192266226","source":"receptor","message":"receptor.request.done","log_level":1,"data":{"method":"GET","request":"/v1/domains","session":"20207"}}
<12>2015-07-21T00:27:03.692338+00:00 10.5.139.241 vmsvc [job=cell_z1 index=1] [ warning] [guestinfo] Failed to get vmstats.
<13>2015-07-21T00:27:03.936841+00:00 10.5.139.241 vcap.rep [job=cell_z1 index=1] {"timestamp":"1437438423.935924530","source":"rep","message":"rep.running-bulker.sync.starting","log_level":1,"data":{"session":"11.7938"}}
<13>2015-07-21T00:27:03.937079+00:00 10.5.139.241 vcap.rep [job=cell_z1 index=1] {"timestamp":"1437438423.936018705","source":"rep","message":"rep.running-bulker.sync.batch-operations.started","log_level":1,"data":{"session":"11.7938.1"}}
<13>2015-07-21T00:27:03.937110+00:00 10.5.139.241 vcap.rep [job=cell_z1 index=1] {"timestamp":"1437438423.936035156","source":"rep","message":"rep.running-bulker.sync.batch-operations.getting-containers-lrps-and-tasks","log_level":1,"data":{"session":"11.7938.1"}}
<13>2015-07-21T00:27:03.937132+00:00 10.5.139.241 vcap.rep [job=cell_z1 index=1] {"timestamp":"1437438423.936167717","source":"rep","message":"rep.running-bulker.sync.batch-operations.fetching-tasks-from-store","log_level":1,"data":{"session":"11.7938.1"}}
<13>2015-07-21T00:27:03.968190+00:00 10.5.139.241 vcap.rep [job=cell_z1 index=1] {"timestamp":"1437438423.968116999","source":"rep","message":"rep.running-bulker.sync.batch-operations.succeeded-fetching-tasks-from-store","log_level":1,"data":{"session":"11.7938.1"}}
<13>2015-07-21T00:27:06.495263+00:00 10.5.139.241 vcap.rep [job=cell_z1 index=1] {"timestamp":"1437438426.495136499","source":"rep","message":"rep.running-bulker.sync.batch-operations.succeeded-getting-containers-lrps-and-tasks","log_level":1,"data":{"session":"11.7938.1"}}
<13>2015-07-21T00:27:06.495341+00:00 10.5.139.241 vcap.rep [job=cell_z1 index=1] {"timestamp":"1437438426.495275497","source":"rep","message":"rep.running-bulker.sync.batch-operations.succeeded","log_level":1,"data":{"batch-size":0,"session":"11.7938.1"}}

Another (single) Diego syslog message payload:

2015-07-21T00:27:10.310490+00:00 10.5.139.246 vcap.route-emitter [job=route_emitter_z1 index=0] {"timestamp":"1437438430.310252428","source":"route-emitter","message":"route-emitter.watcher.sync.emitting-messages","log_level":1,"data":{"messages":{"RegistrationMessages":null,"UnregistrationMessages":null},"session":"5.10080"}}
<13>2015-07-21T00:27:10.312037+00:00 10.5.139.246 vcap.route-emitter [job=route_emitter_z1 index=0] {"timestamp":"1437438430.311890841","source":"route-emitter","message":"route-emitter.watcher.sync.complete","log_level":1,"data":{"session":"5.10080"}}
<12>2015-07-21T00:27:11.049315+00:00 10.5.139.246 vmsvc [job=route_emitter_z1 index=0] [ warning] [guestinfo] Failed to get vmstats.

-Mike

From: cf-dev-bounces(a)lists.cloudfoundry.org [mailto:cf-dev-bounces(a)lists.cloudfoundry.org] On Behalf Of Eric Malm
Sent: Tuesday, July 21, 2015 12:01 AM
To: Discussions about Cloud Foundry projects and the system overall.
Subject: Re: [cf-dev] Diego log grouping

Hi, Mike,

Thanks for the report! From your packet captures or on-VM logs, do you have an example of the log line groups that Splunk is failing to ingest? Is it all the log lines, or just ones coming from particular Diego components?

The github.com/tedsuo/ifrit<http://github.com/tedsuo/ifrit> dependency hasn't changed in diego-release between 1099 and 1304, but it's possible that our use of it in diego-release has. Likewise, the github.com/pivotal-golang/lager<http://github.com/pivotal-golang/lager> package that's emitting logs has changed in only trivial ways between those releases. We have upgraded the release to use Go 1.4.2 instead of 1.4, though.

Also, what stemcell versions are you using in the deployments? I'm assuming that if CF is deployed alongside these Diego deployments, it's at the corresponding recommended final version (v207 and v212, respectively). If so, are there any problems with the syslog messages coming from those deployments?

Thanks,
Eric, CF Runtime Diego PM



On Mon, Jul 20, 2015 at 6:51 PM, Mike Jacobi <jacobi(a)adobe.com<mailto:jacobi(a)adobe.com>> wrote:
We have a Diego 1099 deployment and syslog_daemon_config configured. We see a 1:1 mapping for Diego platform messages to syslog messages. In other words, for each syslog message that hits the wire, there is one platform message as its payload. This works well with Splunk, which is ultimately where the messages end up.

We have another deployment, but on Diego 1304, with its syslog_daemon_config identical to the other, but Splunk is *not* ingesting its logs. We ran a packet capture and discovered that this deployment is grouping its log messages in a 1:n manner: For each syslog message on the wire, we have multiple platform messages within, separated by newlines. I suspect this is the reason the logs aren’t being ingested.

I took a quick glance at the code and it seems like this might be due to ifrit/grouper, but I can’t say for sure.

Has anyone run into this issue?

Thanks,
Mike


_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org<mailto:cf-dev(a)lists.cloudfoundry.org>
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


Allow gorouter to log random headers.

Simon Johansson <simon@...>
 

Howdie!

We have some devs who want to be able to trace a request troughout their
applications.

user -> a -> b -> c
|
|-> d -> e

When a user makes a request to "a" uuid is generated inside the app, and
the request to "b" from "a" will set a header(call it WAKAWAKA to uuid),
"b"'s call will passthrough WAKAWAKA to "c" and "d", "d" will passthrough
WAKAWAKA to "e". Etc.

We aggregate all RTR logs into ELK so it would be super helpful to them to
be able to filter on WAKAWAKA and get all the access logs(and app logs
aswell, they mostly use GELF so its easy for them to add whatewher field
they want) from the services involved.

I had a quick peek at the gorouter(
https://github.com/cloudfoundry/gorouter/blob/76668f5818ea8c089ff52a14fcdfbf703c8e8767/access_log/access_log_record.go#L40)
and it seems like this should be a simple PR.

1. To gorouter.yml add
passthrough_headers:
- WAKAWAKA
- X-Random-Header

2. In makeRecord at the bottom add something like(in psuedo)

data = {}
for header in passthrough_headers:
header_val = r.FormatRequestHeader("X-Forwarded-For")
if header_val:
passthrough_headers[header] = header_val

if data:
fmt.Fprintf(b, data.to_stringified_json())

That would yield a log line like
blurgh.dev.cf.private.domain.com - [21/07/2015:10:17:05 +0000] "GET
/statements?ascending=true&since=2015-06-30T14%3A10%3A03.078Z&skipStatementId=30a88204-0779-4385-9859-e4aabd30baf0
HTTP/1.1" 200 0 17 "-" "NING/1.0" 10.230.31.2:46204 x_forwarded_for:"-"
vcap_request_id:1e58195a-cde6-4afd-7f03-43061c9ea91c
response_time:0.004927106 app_id:9784cd03-050d-4b74-9e90-5f17134a3f08
{"WAKAWAKA": "Space is the place", "X-Random-Header": "Once upon a midnight
dreary, while I pondered weak and weary"}

The reason for a stringified JSON is to make it easy to parse with logstash
or other loganalysis tools.

Before I spend time implementing, is this something you would merge?


Re: revrse proxy in CF

Felix Friedrich
 

Thanks, it works now!


Felix

On Tue, Jul 21, 2015, at 10:21 AM, Dieu Cao wrote:
That's odd. I've fixed the link so it should be readable/commentable
again.

-Dieu
CF CAPI PM

On Tue, Jul 21, 2015 at 12:59 AM, Felix Friedrich <felix(a)fri.edri.ch>
wrote:

Hello,

the document "Context Path Routing" [1] does not seem to be public
accessible.


Felix




[1]

https://docs.google.com/document/d/1H_adSiY7wGR85av9YfxxPRylSO8Q8U0ANJJTg6wpYRQ/edit





On Tue, Jul 7, 2015, at 05:22 AM, Sumanth Yamala wrote:
Thanks Chris. Will keep you posted on how it goes.

Sumanth

From: cf-dev-bounces(a)lists.cloudfoundry.org
[mailto:cf-dev-bounces(a)lists.cloudfoundry.org] On Behalf Of Christopher
Piraino
Sent: Monday, July 06, 2015 8:16 PM
To: Discussions about Cloud Foundry projects and the system overall.
Subject: Re: [cf-dev] revrse proxy in CF

Hi Sumanth,

We recently added support for "Context Path
Routing"<
https://docs.google.com/document/d/1H_adSiY7wGR85av9YfxxPRylSO8Q8U0ANJJTg6wpYRQ

in both the GoRouter and CC
API<http://apidocs.cloudfoundry.org/212/routes/creating_a_route.html>. I
do not believe the cf CLI has implemented this feature yet.

This feature was added to address this exact use-case, we would love to
receive feedback on it. Note that there is a current bug related to the
use of context paths and session
affinity<https://www.pivotaltracker.com/story/show/98068176> that we
have
in our backlog.

Let me know if that helps!

Best,
Chris Piraino, CF Routing Team

On Mon, Jul 6, 2015 at 2:41 PM, Sumanth Yamala
<Sumanth.Yamala(a)sas.com<mailto:Sumanth.Yamala(a)sas.com>> wrote:
The main goal is to have a mapping from a top level url like
abc.com/app1<http://abc.com/app1> abc.com/app2<http://abc.com/app2>
getting mapped to the actual routes given by cf to the respective apps.
So I was thinking of adding a reverse proxy in front of the router,
similar to what you have done. Can this be accomplished with the go
router or do we need a reverse proxy?

Thanks
Sumanth

From:
cf-dev-bounces(a)lists.cloudfoundry.org<mailto:
cf-dev-bounces(a)lists.cloudfoundry.org>
[mailto:cf-dev-bounces(a)lists.cloudfoundry.org<mailto:
cf-dev-bounces(a)lists.cloudfoundry.org>]
On Behalf Of John Wong
Sent: Monday, July 06, 2015 4:32 PM
To: Discussions about Cloud Foundry projects and the system overall.
Subject: Re: [cf-dev] revrse proxy in CF

What is the goal of your reversed proxy? Did you mean load balance of
multiple instances of an app (cf push APPNAME -i 3 ==== having 3
instances of APPNAME)?

Gorouter knows how to dispatch to app 1 or app2, for as long as cf is
setup properly and that there is a url mapping.

Where I work we also configure Nginx to handle the incoming traffic and
then proxy to gorouter.

On Mon, Jul 6, 2015 at 4:23 PM, Sumanth Yamala
<Sumanth.Yamala(a)sas.com<mailto:Sumanth.Yamala(a)sas.com>> wrote:
Hi,

In an environment with multiple micro services being deployed in CF. Does
the “go router” have the functionality of reverse proxy or should I
configure httpd to sit in front of the go router.

Thanks,
Sumanth

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org<mailto:cf-dev(a)lists.cloudfoundry.org>
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org<mailto:cf-dev(a)lists.cloudfoundry.org>
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


Re: revrse proxy in CF

Dieu Cao <dcao@...>
 

That's odd. I've fixed the link so it should be readable/commentable again.

-Dieu
CF CAPI PM

On Tue, Jul 21, 2015 at 12:59 AM, Felix Friedrich <felix(a)fri.edri.ch> wrote:

Hello,

the document "Context Path Routing" [1] does not seem to be public
accessible.


Felix




[1]

https://docs.google.com/document/d/1H_adSiY7wGR85av9YfxxPRylSO8Q8U0ANJJTg6wpYRQ/edit





On Tue, Jul 7, 2015, at 05:22 AM, Sumanth Yamala wrote:
Thanks Chris. Will keep you posted on how it goes.

Sumanth

From: cf-dev-bounces(a)lists.cloudfoundry.org
[mailto:cf-dev-bounces(a)lists.cloudfoundry.org] On Behalf Of Christopher
Piraino
Sent: Monday, July 06, 2015 8:16 PM
To: Discussions about Cloud Foundry projects and the system overall.
Subject: Re: [cf-dev] revrse proxy in CF

Hi Sumanth,

We recently added support for "Context Path
Routing"<
https://docs.google.com/document/d/1H_adSiY7wGR85av9YfxxPRylSO8Q8U0ANJJTg6wpYRQ

in both the GoRouter and CC
API<http://apidocs.cloudfoundry.org/212/routes/creating_a_route.html>. I
do not believe the cf CLI has implemented this feature yet.

This feature was added to address this exact use-case, we would love to
receive feedback on it. Note that there is a current bug related to the
use of context paths and session
affinity<https://www.pivotaltracker.com/story/show/98068176> that we
have
in our backlog.

Let me know if that helps!

Best,
Chris Piraino, CF Routing Team

On Mon, Jul 6, 2015 at 2:41 PM, Sumanth Yamala
<Sumanth.Yamala(a)sas.com<mailto:Sumanth.Yamala(a)sas.com>> wrote:
The main goal is to have a mapping from a top level url like
abc.com/app1<http://abc.com/app1> abc.com/app2<http://abc.com/app2>
getting mapped to the actual routes given by cf to the respective apps.
So I was thinking of adding a reverse proxy in front of the router,
similar to what you have done. Can this be accomplished with the go
router or do we need a reverse proxy?

Thanks
Sumanth

From:
cf-dev-bounces(a)lists.cloudfoundry.org<mailto:
cf-dev-bounces(a)lists.cloudfoundry.org>
[mailto:cf-dev-bounces(a)lists.cloudfoundry.org<mailto:
cf-dev-bounces(a)lists.cloudfoundry.org>]
On Behalf Of John Wong
Sent: Monday, July 06, 2015 4:32 PM
To: Discussions about Cloud Foundry projects and the system overall.
Subject: Re: [cf-dev] revrse proxy in CF

What is the goal of your reversed proxy? Did you mean load balance of
multiple instances of an app (cf push APPNAME -i 3 ==== having 3
instances of APPNAME)?

Gorouter knows how to dispatch to app 1 or app2, for as long as cf is
setup properly and that there is a url mapping.

Where I work we also configure Nginx to handle the incoming traffic and
then proxy to gorouter.

On Mon, Jul 6, 2015 at 4:23 PM, Sumanth Yamala
<Sumanth.Yamala(a)sas.com<mailto:Sumanth.Yamala(a)sas.com>> wrote:
Hi,

In an environment with multiple micro services being deployed in CF. Does
the “go router” have the functionality of reverse proxy or should I
configure httpd to sit in front of the go router.

Thanks,
Sumanth

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org<mailto:cf-dev(a)lists.cloudfoundry.org>
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org<mailto:cf-dev(a)lists.cloudfoundry.org>
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


Re: 3 etcd nodes don't work well in single zone

Tony
 

Hi Amit,

It’s me again.

Could you please see log files in the attachment?

We got these errors:

Etcd:
./etcd/etcd.stderr.log:
etcdhttp: unexpected error: etcdserver: request timed out
(but it might be not a bug according to https://github.com/coreos/etcd/issues/3133)

Hm9000
./hm9000/hm9000_analyzer.log , hm9000_apiserver.log and hm9000_sender.log
"error","message":"Store is not fresh - Error:Actual state is not fresh"


Today we tried to run it with 2 etcd instances but not 3, to detect the problem more clearly.

Also, we tried to change properties of etcd:

properties:

etcd:
election_timeout_in_milliseconds: 3000 (also tried 5000)
heartbeat_interval_in_milliseconds: 50 (also tried 500, 1000)
log_sync_timeout_in_seconds: 30

It seems that heartbeat_interval_in_milliseconds works
(got ?/2 about 4 times as many as 2/2, when it is 50, and
Got ?/2 about 1.7 times as many as 2/2, when it is 1000).

We may try 2000 or 3000 tomorrow though we think it is too big compared with the default value 50.

Do you have any idea about it?

Thanks,

Tony Li

From: Tony [via CF Dev] [mailto:ml-node+s70369n788h4(a)n6.nabble.com]
Sent: Tuesday, 21 July 2015 9:54 AM
To: Li, Tony
Subject: Re: [cf-dev] 3 etcd nodes don't work well in single zone

Hi Amit,

Thanks for your reply.
Yes, we still get stuck here.

And let's me introduce George who is checking this issue in detail. He will send log and report with more details to you soon.

BTW, We know how to get logs from bosh vms. Thank you very much.

Regards,
Tony
________________________________
If you reply to this email, your message will be added to the discussion below:
http://cf-dev.70369.x6.nabble.com/cf-dev-3-etcd-nodes-don-t-work-well-in-single-zone-tp746p788.html
To unsubscribe from [cf-dev] 3 etcd nodes don't work well in single zone, click here<http://cf-dev.70369.x6.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=746&code=VG9ueWxAZmFzdC5hdS5mdWppdHN1LmNvbXw3NDZ8LTQ5MjU5Njk1Nw==>.
NAML<http://cf-dev.70369.x6.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
Disclaimer

The information in this e-mail is confidential and may contain content that is subject to copyright and/or is commercial-in-confidence and is intended only for the use of the above named addressee. If you are not the intended recipient, you are hereby notified that dissemination, copying or use of the information is strictly prohibited. If you have received this e-mail in error, please telephone Fujitsu Australia Software Technology Pty Ltd on + 61 2 9452 9000 or by reply e-mail to the sender and delete the document and all copies thereof.


Whereas Fujitsu Australia Software Technology Pty Ltd would not knowingly transmit a virus within an email communication, it is the receiver’s responsibility to scan all communication and any files attached for computer viruses and other defects. Fujitsu Australia Software Technology Pty Ltd does not accept liability for any loss or damage (whether direct, indirect, consequential or economic) however caused, and whether by negligence or otherwise, which may result directly or indirectly from this communication or any files attached.


If you do not wish to receive commercial and/or marketing email messages from Fujitsu Australia Software Technology Pty Ltd, please email unsubscribe(a)fast.au.fujitsu.com


logs.zip (47K) <http://cf-dev.70369.x6.nabble.com/attachment/797/0/logs.zip>




--
View this message in context: http://cf-dev.70369.x6.nabble.com/cf-dev-3-etcd-nodes-don-t-work-well-in-single-zone-tp746p797.html
Sent from the CF Dev mailing list archive at Nabble.com.


Re: revrse proxy in CF

Felix Friedrich
 

Hello,

the document "Context Path Routing" [1] does not seem to be public
accessible.


Felix




[1]
https://docs.google.com/document/d/1H_adSiY7wGR85av9YfxxPRylSO8Q8U0ANJJTg6wpYRQ/edit

On Tue, Jul 7, 2015, at 05:22 AM, Sumanth Yamala wrote:
Thanks Chris. Will keep you posted on how it goes.

Sumanth

From: cf-dev-bounces(a)lists.cloudfoundry.org
[mailto:cf-dev-bounces(a)lists.cloudfoundry.org] On Behalf Of Christopher
Piraino
Sent: Monday, July 06, 2015 8:16 PM
To: Discussions about Cloud Foundry projects and the system overall.
Subject: Re: [cf-dev] revrse proxy in CF

Hi Sumanth,

We recently added support for "Context Path
Routing"<https://docs.google.com/document/d/1H_adSiY7wGR85av9YfxxPRylSO8Q8U0ANJJTg6wpYRQ>
in both the GoRouter and CC
API<http://apidocs.cloudfoundry.org/212/routes/creating_a_route.html>. I
do not believe the cf CLI has implemented this feature yet.

This feature was added to address this exact use-case, we would love to
receive feedback on it. Note that there is a current bug related to the
use of context paths and session
affinity<https://www.pivotaltracker.com/story/show/98068176> that we have
in our backlog.

Let me know if that helps!

Best,
Chris Piraino, CF Routing Team

On Mon, Jul 6, 2015 at 2:41 PM, Sumanth Yamala
<Sumanth.Yamala(a)sas.com<mailto:Sumanth.Yamala(a)sas.com>> wrote:
The main goal is to have a mapping from a top level url like
abc.com/app1<http://abc.com/app1> abc.com/app2<http://abc.com/app2>
getting mapped to the actual routes given by cf to the respective apps.
So I was thinking of adding a reverse proxy in front of the router,
similar to what you have done. Can this be accomplished with the go
router or do we need a reverse proxy?

Thanks
Sumanth

From:
cf-dev-bounces(a)lists.cloudfoundry.org<mailto:cf-dev-bounces(a)lists.cloudfoundry.org>
[mailto:cf-dev-bounces(a)lists.cloudfoundry.org<mailto:cf-dev-bounces(a)lists.cloudfoundry.org>]
On Behalf Of John Wong
Sent: Monday, July 06, 2015 4:32 PM
To: Discussions about Cloud Foundry projects and the system overall.
Subject: Re: [cf-dev] revrse proxy in CF

What is the goal of your reversed proxy? Did you mean load balance of
multiple instances of an app (cf push APPNAME -i 3 ==== having 3
instances of APPNAME)?

Gorouter knows how to dispatch to app 1 or app2, for as long as cf is
setup properly and that there is a url mapping.

Where I work we also configure Nginx to handle the incoming traffic and
then proxy to gorouter.

On Mon, Jul 6, 2015 at 4:23 PM, Sumanth Yamala
<Sumanth.Yamala(a)sas.com<mailto:Sumanth.Yamala(a)sas.com>> wrote:
Hi,

In an environment with multiple micro services being deployed in CF. Does
the “go router” have the functionality of reverse proxy or should I
configure httpd to sit in front of the go router.

Thanks,
Sumanth

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org<mailto:cf-dev(a)lists.cloudfoundry.org>
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org<mailto:cf-dev(a)lists.cloudfoundry.org>
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


Re: Can't login into api

James Bayer
 

what are these values?
https://github.com/cloudfoundry/cf-release/blob/master/jobs/cloud_controller_ng/spec#L63-L66

On Mon, Jul 20, 2015 at 7:46 PM, Gwenn Etourneau <getourneau(a)pivotal.io>
wrote:

It seems the routers and Haproxy works as you get the 404 from the routers
"404 Not Found: Requested route ('api.subdomain.domain') does not exist."
Maybe something wrong in the manifest especially around system or apps
domain

On Mon, Jul 20, 2015 at 6:26 PM, Schwerdtfeger, Christian <
christian.schwerdtfeger(a)n4group.de> wrote:

Hello together,

i've deployed Cloudfoundry into AWS like following:

- bosh aws create like descriped here:
http://docs.cloudfoundry.org/deploying/ec2/bootstrap-aws-vpc.html
- Installation of bosh like descriped on this page:
http://bosh.io/docs/deploy-microbosh-to-aws.html
- installed cloudfoundry using cf-boshworkspace (
https://github.com/cloudfoundry-community/cf-boshworkspace)

My deployment uses the cf-tiny-scalable.yml deployment of
cf-boshworkspace and is starting secondary AZ nodes for backbone, api and
runner.

With some minor modifications i've got the installation to run through
without error.
After that i tried to "curl api.subdomain.domain/info" and get "404 Not
Found: Requested route ('api.subdomain.domain') does not exist."

Does someone of you have a glue where to search the error? The output of
"monit status" on nodes "public_haproxy_z1/0" and "api_z1/0" seems to be
okay. All processes are marked as "running" and "monitored".

Thank you
Christian

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


--
Thank you,

James Bayer


Re: Diego log grouping

Eric Malm <emalm@...>
 

Hi, Mike,

Thanks for the report! From your packet captures or on-VM logs, do you have
an example of the log line groups that Splunk is failing to ingest? Is it
all the log lines, or just ones coming from particular Diego components?

The github.com/tedsuo/ifrit dependency hasn't changed in diego-release
between 1099 and 1304, but it's possible that our use of it in
diego-release has. Likewise, the github.com/pivotal-golang/lager package
that's emitting logs has changed in only trivial ways between those
releases. We have upgraded the release to use Go 1.4.2 instead of 1.4,
though.

Also, what stemcell versions are you using in the deployments? I'm assuming
that if CF is deployed alongside these Diego deployments, it's at the
corresponding recommended final version (v207 and v212, respectively). If
so, are there any problems with the syslog messages coming from those
deployments?

Thanks,
Eric, CF Runtime Diego PM

On Mon, Jul 20, 2015 at 6:51 PM, Mike Jacobi <jacobi(a)adobe.com> wrote:

We have a Diego 1099 deployment and syslog_daemon_config configured. We
see a 1:1 mapping for Diego platform messages to syslog messages. In other
words, for each syslog message that hits the wire, there is one platform
message as its payload. This works well with Splunk, which is ultimately
where the messages end up.



We have another deployment, but on Diego 1304, with its
syslog_daemon_config identical to the other, but Splunk is **not**
ingesting its logs. We ran a packet capture and discovered that this
deployment is grouping its log messages in a 1:n manner: For each syslog
message on the wire, we have multiple platform messages within, separated
by newlines. I suspect this is the reason the logs aren’t being ingested.



I took a quick glance at the code and it seems like this might be due to
ifrit/grouper, but I can’t say for sure.



Has anyone run into this issue?



Thanks,

Mike



_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


Re: [ANN] Buildpack releases: ruby, php, python, nodejs, staticfile

James Bayer
 

great work buildpacks team! it's great to have the binaries built by the CF
build process.

On Mon, Jul 20, 2015 at 3:47 PM, Mike Dalessio <mdalessio(a)pivotal.io> wrote:

Hello CF community,

I'd like to announce update releases of the ruby, php, python, nodejs and
staticfile buildpacks.

*CF Binaries*

Primarily these releases were made to ship CF-specific binaries, as
discussed earlier on this mailing list, hence the minor version bump for
ruby, python, and nodejs.

The PHP buildpack also rolls in a restructuring of the manifest file,
meaning that instead of enumerating hundreds of PHP and HTTPD modules, the
module files are included in the "parent" tarball. As a result, previous
manifests are unlikely to work, and you'll notice that we've removed the
manifest-including-unsupported.yml file from the repository, and bumped
the major version to indicate a backwards-incompatible change.

*Security*

You'll also note a CVE related to the Rubygems client packaged by JRuby
was addressed in the ruby buildpack with the update of JRuby from 1.7.19 to
1.7.21.
------------------------------
Rubyv1.6.0 - 2015-07-20

https://github.com/cloudfoundry/ruby-buildpack/releases/tag/v1.6.0

- Include CF built binaries (
https://www.pivotaltracker.com/story/show/97136960)

Packaged binaries:

| name | version | cf_stacks |
|----------------------------|------------------------------|------------|
| ruby | 2.0.0 | cflinuxfs2 |
| ruby | 2.1.5 | cflinuxfs2 |
| ruby | 2.1.6 | cflinuxfs2 |
| ruby | 2.2.1 | cflinuxfs2 |
| ruby | 2.2.2 | cflinuxfs2 |
| jruby | ruby-1.9.3-jruby-1.7.21 | cflinuxfs2 |
| jruby | ruby-2.0.0-jruby-1.7.21 | cflinuxfs2 |
| jruby | ruby-2.2.2-jruby-9.0.0.0.rc2 | cflinuxfs2 |
| node | 0.12.7 | cflinuxfs2 |
| bundler | 1.9.7 | cflinuxfs2 |
| libyaml | 0.1.6 | cflinuxfs2 |
| openjdk1.8-latest | - | cflinuxfs2 |
| rails3_serve_static_assets | - | cflinuxfs2 |
| rails_log_stdout | - | cflinuxfs2 |

v1.5.2 - 2015-07-13

https://github.com/cloudfoundry/ruby-buildpack/releases/tag/v1.5.2

-

Update 1.7.* jrubies to 1.7.21 in response to CVE-2015-4020 Add
support for JRuby 9.0.0.0.rc2 Remove support for JRuby 9.0.0.0.rc1 (
https://www.pivotaltracker.com/story/show/98856174)
-

Add support for node version 0.12.7 (
https://www.pivotaltracker.com/story/show/98855140)

Packaged binaries:

| name | version | cf_stacks |
|----------------------------|------------------------------|------------|
| ruby | 2.0.0 | cflinuxfs2 |
| ruby | 2.1.5 | cflinuxfs2 |
| ruby | 2.1.6 | cflinuxfs2 |
| ruby | 2.2.1 | cflinuxfs2 |
| ruby | 2.2.2 | cflinuxfs2 |
| jruby | ruby-1.9.3-jruby-1.7.21 | cflinuxfs2 |
| jruby | ruby-2.0.0-jruby-1.7.21 | cflinuxfs2 |
| jruby | ruby-2.2.2-jruby-9.0.0.0.rc2 | cflinuxfs2 |
| node | 0.12.7 | cflinuxfs2 |
| bundler | 1.9.7 | cflinuxfs2 |
| libyaml | 0.1.6 | cflinuxfs2 |
| openjdk1.8-latest | - | cflinuxfs2 |
| rails3_serve_static_assets | - | cflinuxfs2 |
| rails_log_stdout | - | cflinuxfs2 |

PHPv4.0.0 - 2015-07-20

https://github.com/cloudfoundry/php-buildpack/releases/tag/v4.0.0

-

upgrade PHP 5.6.11, 5.5.27, and 5.4.43 (
https://www.pivotaltracker.com/story/show/98855368)
-

Package all PHP modules in a single tarball

Instead of downloading PHP modules individually, include all modules
in a single tarball to make the manifest more manageable. (
https://www.pivotaltracker.com/story/show/95473520)
-

Package all httpd modules in a single tarball

Instead of downloading httpd modules individually, include all modules
in a single tarball to make the manifest more manageable. (
https://www.pivotaltracker.com/story/show/95473520)
-

Add nginx 1.9.2, upgrade to 1.6.3; drop 1.7.x (
https://www.pivotaltracker.com/story/show/98855608)
-

Include current stack in unsupported stack message (
https://www.pivotaltracker.com/story/show/98579464)

Packaged binaries:

| name | version | cf_stacks |
|----------|---------------|------------|
| php | 5.4.42 | cflinuxfs2 |
| php | 5.4.43 | cflinuxfs2 |
| php | 5.5.26 | cflinuxfs2 |
| php | 5.5.27 | cflinuxfs2 |
| php | 5.6.10 | cflinuxfs2 |
| php | 5.6.11 | cflinuxfs2 |
| hhvm | 3.5.0 | cflinuxfs2 |
| hhvm | 3.5.1 | cflinuxfs2 |
| hhvm | 3.6.0 | cflinuxfs2 |
| hhvm | 3.6.1 | cflinuxfs2 |
| composer | 1.0.0-alpha10 | cflinuxfs2 |
| httpd | 2.4.12 | cflinuxfs2 |
| newrelic | 4.20.2.95 | cflinuxfs2 |
| nginx | 1.6.3 | cflinuxfs2 |
| nginx | 1.8.0 | cflinuxfs2 |
| nginx | 1.9.2 | cflinuxfs2 |

Pythonv1.5.0 - 2015-07-20

https://github.com/cloudfoundry/python-buildpack/releases/tag/v1.5.0

-

Include CF built binaries (
https://www.pivotaltracker.com/story/show/97136960)
-

Include current stack in unsupported stack message (
https://www.pivotaltracker.com/story/show/98579464)
-

Update pip to 7.1.0
-

Update setuptools to 18.0.1
-

Set xtrace if $BUILDPACK_XTRACE set

Packaged binaries:

| name | version | cf_stacks |
|-------------|---------|------------|
| python | 2.7.10 | cflinuxfs2 |
| python | 2.7.9 | cflinuxfs2 |
| python | 3.3.5 | cflinuxfs2 |
| python | 3.3.6 | cflinuxfs2 |
| python | 3.4.2 | cflinuxfs2 |
| python | 3.4.3 | cflinuxfs2 |
| libffi | 3.1 | cflinuxfs2 |
| libmemcache | 1.0.18 | cflinuxfs2 |

NodeJSv1.5.0 - 2015-07-20

https://github.com/cloudfoundry/nodejs-buildpack/releases/tag/v1.5.0

-

remove versions 0.8.x and 0.9.x from manifest (
https://www.pivotaltracker.com/story/show/97770112)
-

Include CF built binaries (
https://www.pivotaltracker.com/story/show/97136960)

Packaged binaries:

| name | version | cf_stacks |
|------|---------|------------|
| node | 0.10.38 | cflinuxfs2 |
| node | 0.10.40 | cflinuxfs2 |
| node | 0.11.15 | cflinuxfs2 |
| node | 0.11.16 | cflinuxfs2 |
| node | 0.12.6 | cflinuxfs2 |
| node | 0.12.7 | cflinuxfs2 |

v1.4.2 -- 2015-07-13

https://github.com/cloudfoundry/nodejs-buildpack/releases/tag/v1.4.2

- Security upgrade to nodejs 0.12.7 Add support for node version
0.10.40 Remove support for node version 0.10.37 (
https://www.pivotaltracker.com/story/show/98855140)

Packaged binaries:

| name | version | cf_stacks |
|------|---------|------------|
| node | 0.10.38 | cflinuxfs2 |
| node | 0.10.40 | cflinuxfs2 |
| node | 0.11.15 | cflinuxfs2 |
| node | 0.11.16 | cflinuxfs2 |
| node | 0.12.4 | cflinuxfs2 |
| node | 0.12.6 | cflinuxfs2 |
| node | 0.12.7 | cflinuxfs2 |
| node | 0.8.27 | cflinuxfs2 |
| node | 0.8.28 | cflinuxfs2 |
| node | 0.9.11 | cflinuxfs2 |
| node | 0.9.12 | cflinuxfs2 |

StaticFilev1.2.1 - 2015-07-17

https://github.com/cloudfoundry/staticfile-buildpack/releases/tag/v1.2.1

-

Adding helpful message for unsupported stack (
https://www.pivotaltracker.com/story/show/98579464)
-

Compress nginx response body for more MIME types (
https://www.pivotaltracker.com/story/show/98128132)
-

Update nginx to version 1.8.0 (
https://www.pivotaltracker.com/story/show/97663450)

Packaged binaries:

| name | version | cf_stacks |
|-------|---------|------------|
| nginx | 1.8.0 | cflinuxfs2 |



.

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

--
Thank you,

James Bayer


Re: Can't login into api

Gwenn Etourneau
 

It seems the routers and Haproxy works as you get the 404 from the routers "404
Not Found: Requested route ('api.subdomain.domain') does not exist."
Maybe something wrong in the manifest especially around system or apps
domain

On Mon, Jul 20, 2015 at 6:26 PM, Schwerdtfeger, Christian <
christian.schwerdtfeger(a)n4group.de> wrote:

Hello together,

i've deployed Cloudfoundry into AWS like following:

- bosh aws create like descriped here:
http://docs.cloudfoundry.org/deploying/ec2/bootstrap-aws-vpc.html
- Installation of bosh like descriped on this page:
http://bosh.io/docs/deploy-microbosh-to-aws.html
- installed cloudfoundry using cf-boshworkspace (
https://github.com/cloudfoundry-community/cf-boshworkspace)

My deployment uses the cf-tiny-scalable.yml deployment of cf-boshworkspace
and is starting secondary AZ nodes for backbone, api and runner.

With some minor modifications i've got the installation to run through
without error.
After that i tried to "curl api.subdomain.domain/info" and get "404 Not
Found: Requested route ('api.subdomain.domain') does not exist."

Does someone of you have a glue where to search the error? The output of
"monit status" on nodes "public_haproxy_z1/0" and "api_z1/0" seems to be
okay. All processes are marked as "running" and "monitored".

Thank you
Christian

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


Re: Merge Request for

Gwenn Etourneau
 

I merge it.
This repos since unmaintained since some month.

On Tue, Jul 21, 2015 at 1:32 AM, Jeff Sloyer <jsloyer(a)gmail.com> wrote:

Hello,

I have submitted a PR (
https://github.com/cloudfoundry-community/cf-meteor-buildpack/pull/3) for
the Meteor buildpack, what is the process for it getting reviewed and
merged?



_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


Re: Send a message to all application instances

Gwenn Etourneau
 

It depends, but what James suggest is to use an external service for
PUB/SUB.
All your application listen on it and they will get notifify.

On Tue, Jul 21, 2015 at 5:15 AM, Peter Dotchev <dotchev(a)gmail.com> wrote:

Hi James,

But how does this service deliver the messages to all app instances? is it
via HTTP?

Best regards,
Peter D


On Mon, Jul 20, 2015 at 11:11 AM, James Bayer <jbayer(a)pivotal.io> wrote:

a common way is to use a pub/sub pattern with a cf service the app binds
to. the service could be something like rabbitmq or redis that supports the
pub/sub pattern.

On Sun, Jul 19, 2015 at 11:35 PM, Peter Dotchev <dotchev(a)gmail.com>
wrote:

Hello,

I could not find a way to send/broadcast a message to all instances of a
given application in Cloud Foundry.
How can I notify all app instances of certain events?
If I just send a HTTP request, CF router will dispatch it to a single
instance of the app.
What solutions do you use in such cases.

Best regards,
Peter D.


_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


--
Thank you,

James Bayer

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


Diego log grouping

MJ
 

We have a Diego 1099 deployment and syslog_daemon_config configured. We see a 1:1 mapping for Diego platform messages to syslog messages. In other words, for each syslog message that hits the wire, there is one platform message as its payload. This works well with Splunk, which is ultimately where the messages end up.

We have another deployment, but on Diego 1304, with its syslog_daemon_config identical to the other, but Splunk is *not* ingesting its logs. We ran a packet capture and discovered that this deployment is grouping its log messages in a 1:n manner: For each syslog message on the wire, we have multiple platform messages within, separated by newlines. I suspect this is the reason the logs aren't being ingested.

I took a quick glance at the code and it seems like this might be due to ifrit/grouper, but I can't say for sure.

Has anyone run into this issue?

Thanks,
Mike


Re: 3 etcd nodes don't work well in single zone

Tony
 

Hi Amit,

Thanks for your reply.
Yes, we still get stuck here.

And let's me introduce George who is checking this issue in detail. He will
send log and report with more details to you soon.

BTW, We know how to get logs from bosh vms. Thank you very much.

Regards,
Tony



--
View this message in context: http://cf-dev.70369.x6.nabble.com/cf-dev-3-etcd-nodes-don-t-work-well-in-single-zone-tp746p788.html
Sent from the CF Dev mailing list archive at Nabble.com.


[ANN] Buildpack releases: ruby, php, python, nodejs, staticfile

Mike Dalessio
 

Hello CF community,

I'd like to announce update releases of the ruby, php, python, nodejs and
staticfile buildpacks.

*CF Binaries*

Primarily these releases were made to ship CF-specific binaries, as
discussed earlier on this mailing list, hence the minor version bump for
ruby, python, and nodejs.

The PHP buildpack also rolls in a restructuring of the manifest file,
meaning that instead of enumerating hundreds of PHP and HTTPD modules, the
module files are included in the "parent" tarball. As a result, previous
manifests are unlikely to work, and you'll notice that we've removed the
manifest-including-unsupported.yml file from the repository, and bumped the
major version to indicate a backwards-incompatible change.

*Security*

You'll also note a CVE related to the Rubygems client packaged by JRuby was
addressed in the ruby buildpack with the update of JRuby from 1.7.19 to
1.7.21.
------------------------------
Rubyv1.6.0 - 2015-07-20

https://github.com/cloudfoundry/ruby-buildpack/releases/tag/v1.6.0

- Include CF built binaries (
https://www.pivotaltracker.com/story/show/97136960)

Packaged binaries:

| name | version | cf_stacks |
|----------------------------|------------------------------|------------|
| ruby | 2.0.0 | cflinuxfs2 |
| ruby | 2.1.5 | cflinuxfs2 |
| ruby | 2.1.6 | cflinuxfs2 |
| ruby | 2.2.1 | cflinuxfs2 |
| ruby | 2.2.2 | cflinuxfs2 |
| jruby | ruby-1.9.3-jruby-1.7.21 | cflinuxfs2 |
| jruby | ruby-2.0.0-jruby-1.7.21 | cflinuxfs2 |
| jruby | ruby-2.2.2-jruby-9.0.0.0.rc2 | cflinuxfs2 |
| node | 0.12.7 | cflinuxfs2 |
| bundler | 1.9.7 | cflinuxfs2 |
| libyaml | 0.1.6 | cflinuxfs2 |
| openjdk1.8-latest | - | cflinuxfs2 |
| rails3_serve_static_assets | - | cflinuxfs2 |
| rails_log_stdout | - | cflinuxfs2 |

v1.5.2 - 2015-07-13

https://github.com/cloudfoundry/ruby-buildpack/releases/tag/v1.5.2

-

Update 1.7.* jrubies to 1.7.21 in response to CVE-2015-4020 Add support
for JRuby 9.0.0.0.rc2 Remove support for JRuby 9.0.0.0.rc1 (
https://www.pivotaltracker.com/story/show/98856174)
-

Add support for node version 0.12.7 (
https://www.pivotaltracker.com/story/show/98855140)

Packaged binaries:

| name | version | cf_stacks |
|----------------------------|------------------------------|------------|
| ruby | 2.0.0 | cflinuxfs2 |
| ruby | 2.1.5 | cflinuxfs2 |
| ruby | 2.1.6 | cflinuxfs2 |
| ruby | 2.2.1 | cflinuxfs2 |
| ruby | 2.2.2 | cflinuxfs2 |
| jruby | ruby-1.9.3-jruby-1.7.21 | cflinuxfs2 |
| jruby | ruby-2.0.0-jruby-1.7.21 | cflinuxfs2 |
| jruby | ruby-2.2.2-jruby-9.0.0.0.rc2 | cflinuxfs2 |
| node | 0.12.7 | cflinuxfs2 |
| bundler | 1.9.7 | cflinuxfs2 |
| libyaml | 0.1.6 | cflinuxfs2 |
| openjdk1.8-latest | - | cflinuxfs2 |
| rails3_serve_static_assets | - | cflinuxfs2 |
| rails_log_stdout | - | cflinuxfs2 |

PHPv4.0.0 - 2015-07-20

https://github.com/cloudfoundry/php-buildpack/releases/tag/v4.0.0

-

upgrade PHP 5.6.11, 5.5.27, and 5.4.43 (
https://www.pivotaltracker.com/story/show/98855368)
-

Package all PHP modules in a single tarball

Instead of downloading PHP modules individually, include all modules in
a single tarball to make the manifest more manageable. (
https://www.pivotaltracker.com/story/show/95473520)
-

Package all httpd modules in a single tarball

Instead of downloading httpd modules individually, include all modules
in a single tarball to make the manifest more manageable. (
https://www.pivotaltracker.com/story/show/95473520)
-

Add nginx 1.9.2, upgrade to 1.6.3; drop 1.7.x (
https://www.pivotaltracker.com/story/show/98855608)
-

Include current stack in unsupported stack message (
https://www.pivotaltracker.com/story/show/98579464)

Packaged binaries:

| name | version | cf_stacks |
|----------|---------------|------------|
| php | 5.4.42 | cflinuxfs2 |
| php | 5.4.43 | cflinuxfs2 |
| php | 5.5.26 | cflinuxfs2 |
| php | 5.5.27 | cflinuxfs2 |
| php | 5.6.10 | cflinuxfs2 |
| php | 5.6.11 | cflinuxfs2 |
| hhvm | 3.5.0 | cflinuxfs2 |
| hhvm | 3.5.1 | cflinuxfs2 |
| hhvm | 3.6.0 | cflinuxfs2 |
| hhvm | 3.6.1 | cflinuxfs2 |
| composer | 1.0.0-alpha10 | cflinuxfs2 |
| httpd | 2.4.12 | cflinuxfs2 |
| newrelic | 4.20.2.95 | cflinuxfs2 |
| nginx | 1.6.3 | cflinuxfs2 |
| nginx | 1.8.0 | cflinuxfs2 |
| nginx | 1.9.2 | cflinuxfs2 |

Pythonv1.5.0 - 2015-07-20

https://github.com/cloudfoundry/python-buildpack/releases/tag/v1.5.0

-

Include CF built binaries (
https://www.pivotaltracker.com/story/show/97136960)
-

Include current stack in unsupported stack message (
https://www.pivotaltracker.com/story/show/98579464)
-

Update pip to 7.1.0
-

Update setuptools to 18.0.1
-

Set xtrace if $BUILDPACK_XTRACE set

Packaged binaries:

| name | version | cf_stacks |
|-------------|---------|------------|
| python | 2.7.10 | cflinuxfs2 |
| python | 2.7.9 | cflinuxfs2 |
| python | 3.3.5 | cflinuxfs2 |
| python | 3.3.6 | cflinuxfs2 |
| python | 3.4.2 | cflinuxfs2 |
| python | 3.4.3 | cflinuxfs2 |
| libffi | 3.1 | cflinuxfs2 |
| libmemcache | 1.0.18 | cflinuxfs2 |

NodeJSv1.5.0 - 2015-07-20

https://github.com/cloudfoundry/nodejs-buildpack/releases/tag/v1.5.0

-

remove versions 0.8.x and 0.9.x from manifest (
https://www.pivotaltracker.com/story/show/97770112)
-

Include CF built binaries (
https://www.pivotaltracker.com/story/show/97136960)

Packaged binaries:

| name | version | cf_stacks |
|------|---------|------------|
| node | 0.10.38 | cflinuxfs2 |
| node | 0.10.40 | cflinuxfs2 |
| node | 0.11.15 | cflinuxfs2 |
| node | 0.11.16 | cflinuxfs2 |
| node | 0.12.6 | cflinuxfs2 |
| node | 0.12.7 | cflinuxfs2 |

v1.4.2 -- 2015-07-13

https://github.com/cloudfoundry/nodejs-buildpack/releases/tag/v1.4.2

- Security upgrade to nodejs 0.12.7 Add support for node version 0.10.40
Remove support for node version 0.10.37 (
https://www.pivotaltracker.com/story/show/98855140)

Packaged binaries:

| name | version | cf_stacks |
|------|---------|------------|
| node | 0.10.38 | cflinuxfs2 |
| node | 0.10.40 | cflinuxfs2 |
| node | 0.11.15 | cflinuxfs2 |
| node | 0.11.16 | cflinuxfs2 |
| node | 0.12.4 | cflinuxfs2 |
| node | 0.12.6 | cflinuxfs2 |
| node | 0.12.7 | cflinuxfs2 |
| node | 0.8.27 | cflinuxfs2 |
| node | 0.8.28 | cflinuxfs2 |
| node | 0.9.11 | cflinuxfs2 |
| node | 0.9.12 | cflinuxfs2 |

StaticFilev1.2.1 - 2015-07-17

https://github.com/cloudfoundry/staticfile-buildpack/releases/tag/v1.2.1

-

Adding helpful message for unsupported stack (
https://www.pivotaltracker.com/story/show/98579464)
-

Compress nginx response body for more MIME types (
https://www.pivotaltracker.com/story/show/98128132)
-

Update nginx to version 1.8.0 (
https://www.pivotaltracker.com/story/show/97663450)

Packaged binaries:

| name | version | cf_stacks |
|-------|---------|------------|
| nginx | 1.8.0 | cflinuxfs2 |



.


Re: 3 etcd nodes don't work well in single zone

Amit Kumar Gupta
 

Hi Tony,

Are you still having this issue?

Having 3 etcd nodes in a single zone should work perfectly fine. Can you
include logs from your HM9k nodes and your etcd nodes covering a few minutes
where the messed up instance reporting issue is happening. Please let me
know if you need guidance in getting logs of a BOSH VM.

Amit



-----
Amit, CF OSS Release Integration PM
Pivotal Software, Inc.
--
View this message in context: http://cf-dev.70369.x6.nabble.com/cf-dev-3-etcd-nodes-don-t-work-well-in-single-zone-tp746p786.html
Sent from the CF Dev mailing list archive at Nabble.com.

8561 - 8580 of 9398