Hello,

I just installed CF release v235, I used command
"./scripts/generate-bosh-lite-dev-manifest"
to generate a cf.yml, I enabled routing_api by setting "routing_api: enabled:
true" in cf.yml, when

I run the following commands:

bosh create release --force &&

bosh -n upload release &&

bosh -n deploy

There is the following error: Error 400007: `router_z1/0' is not running
after update

The detailed error message is as below:

E, [2016-04-27 15:59:31 #8426] [task:6] ERROR -- DirectorJobRunner:
`router_z1/0' is not running after update

/var/vcap/packages/director/gem_home/ruby/2.1.0/gems/bosh-director-1.3074.0/lib/bosh/director/instance_updater.rb:93:in
`update'

/var/vcap/packages/director/gem_home/ruby/2.1.0/gems/bosh-director-1.3074.0/lib/bosh/director/job_updater.rb:74:in
`block (2 levels) in update_canary_instance'

/var/vcap/packages/director/gem_home/ruby/2.1.0/gems/bosh_common-1.3074.0/lib/common/thread_formatter.rb:49:in
`with_thread_name'

/var/vcap/packages/director/gem_home/ruby/2.1.0/gems/bosh-director-1.3074.0/lib/bosh/director/job_updater.rb:72:in
`block in update_canary_instance'

/var/vcap/packages/director/gem_home/ruby/2.1.0/gems/bosh-director-1.3074.0/lib/bosh/director/event_log.rb:97:in
`call'

/var/vcap/packages/director/gem_home/ruby/2.1.0/gems/bosh-director-1.3074.0/lib/bosh/director/event_log.rb:97:in
`advance_and_track'

/var/vcap/packages/director/gem_home/ruby/2.1.0/gems/bosh-director-1.3074.0/lib/bosh/director/job_updater.rb:71:in
`update_canary_instance'

/var/vcap/packages/director/gem_home/ruby/2.1.0/gems/bosh-director-1.3074.0/lib/bosh/director/job_updater.rb:65:in
`block (2 levels) in update_canaries'

/var/vcap/packages/director/gem_home/ruby/2.1.0/gems/bosh_common-1.3074.0/lib/common/thread_pool.rb:77:in
`call'

/var/vcap/packages/director/gem_home/ruby/2.1.0/gems/bosh_common-1.3074.0/lib/common/thread_pool.rb:77:in
`block (2 levels) in create_thread'

/var/vcap/packages/director/gem_home/ruby/2.1.0/gems/bosh_common-1.3074.0/lib/common/thread_pool.rb:63:in
`loop'

/var/vcap/packages/director/gem_home/ruby/2.1.0/gems/bosh_common-1.3074.0/lib/common/thread_pool.rb:63:in
`block in create_thread'

/var/vcap/packages/director/gem_home/ruby/2.1.0/gems/logging-1.8.2/lib/logging/diagnostic_context.rb:323:in
`call'

/var/vcap/packages/director/gem_home/ruby/2.1.0/gems/logging-1.8.2/lib/logging/diagnostic_context.rb:323:in
`block in create_with_logging_context'

Thanks,

Sam

On Wed, Apr 27, 2016 at 10:36 AM, Sunil Babu <cloudgrp.assist(a)gmail.com>
wrote:

Check on the yml config file

How is this comment related to this email thread or helpful?

Dan

On Wednesday, April 27, 2016, Guillaume Berche <bercheg(a)gmail.com> wrote:

thanks Filip for the update.

I'm curious to know if the various CF components using UAA (e.g. cc) are
already using openid-connect to access PII and thus is the cf-release
default value for the excluded claims could indeed email and user_name, or
whether this is planned and can be watch in their respective backlog (I yet
have to check).

Seems the default value is empty for now in cf-release
http://bosh.io/jobs/uaa?source=github.com/cloudfoundry/cf-release&version=236

Guillaume.


Guillaume.

On Tue, Apr 19, 2016 at 4:16 PM, Filip Hanik <fhanik(a)pivotal.io> wrote:

Guillaume,

We just realized that you can remove any PII, personally identifiable
information, from tokens without us having to add new features

You just configure

jwt:
token:
claims:
exclude:
- authorities
- email
- user_name

in your uaa.yml file. Similar config exists for cf-release
We're closing the story as a "no change needed".


On Fri, Apr 1, 2016 at 1:12 AM, Guillaume Berche <bercheg(a)gmail.com>
wrote:

Great, thanks Filip!


Guillaume.

On Thu, Mar 31, 2016 at 9:50 PM, Filip Hanik <fhanik(a)pivotal.io> wrote:

yes, they are always returned.

introducing an option sounds like a good idea for the systems that
wish to turn it off, thanks for the idea.

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

Filip


On Thu, Mar 31, 2016 at 1:39 PM, Guillaume Berche <bercheg(a)gmail.com>
wrote:

Thanks Filip for your answer. Wouldn't it make sense to progressively
change this behavior, possibly controlled by a configuration option to give
clients time to handle this incompatible change?

Scanning quickly through the code I suspect the username and email
fields are systematically returned in the access token, regardless of the
presence of the openid scope (I still have to double check by actually
testing it), therefore disclosing some user identity without his/her
consent.

Guillaume.

On Thu, Mar 31, 2016 at 3:03 PM, Filip Hanik <fhanik(a)pivotal.io>
wrote:

The access token used to double down as an identity token before
OpenID Connect was standardized, now that we have implemented id_token, we
don't really need it. but removing it would cause an backwards incompatible
change.


Filip


On Thu, Mar 31, 2016 at 6:50 AM, Guillaume Berche <bercheg(a)gmail.com

wrote:

Hi,

I wonder the rationale for apparenty uaa-specific [0] user-related
fields in the access token (username, email [1]) while they are now
returned in a standard maneer in the openidconnect id token.

Is it something that would change in the future ([2] seemed similar
decoupling) ? Or is it a standard practice that avoids clients to request
the idtoken to get access to basic user identity ?

Thanks in advance,

Guillaume.

ps: please let me know if such questions are better suited for a GH
issue on the UAA repo.

[0]
https://github.com/cloudfoundry/uaa/blob/master/docs/UAA-Tokens.md#getting-started

Some of these fields are described in the JSON web tokens

specification. However, the vendor may add additional fields, or
attributes, to the token itself.

[1]
https://github.com/cloudfoundry/uaa/blob/9b5c13d793ebfe358e26559cedc6b528a557b43f/server/src/main/java/org/cloudfoundry/identity/uaa/oauth/UaaTokenServices.java#L493-L497
[2] https://www.pivotaltracker.com/story/show/102090344

Guillaume.

--
Thanks & Regards
Sunil Babu K C
+91-81970-35608

Check on the yml config file

--
Thanks & Regards
Sunil Babu K C
+91-81970-35608

thanks Filip for the update.

I'm curious to know if the various CF components using UAA (e.g. cc) are
already using openid-connect to access PII and thus is the cf-release
default value for the excluded claims could indeed email and user_name, or
whether this is planned and can be watch in their respective backlog (I yet
have to check).

Seems the default value is empty for now in cf-release
http://bosh.io/jobs/uaa?source=github.com/cloudfoundry/cf-release&version=236

Guillaume.


Guillaume.

Hi

Aws lambda is event driven as an initiation happens the job is executed

--
Thanks & Regards
Sunil Babu K C
+91-81970-35608

Pls use ingress and custom and from anywhere option

Hi,

In Rakuten, we use Apache Kafka for collecting all CF component logs, application logs, or system metrics (I described about it on our blog http://techblog.rakuten.co.jp/2016/01/28/rakuten-paas-kafka/ ).

We open sourced one of key components for this logging stack, kafka-firehose-nozzle (https://github.com/rakutentech/kafka-firehose-nozzle), to consume log from firehose and forward to Kafka. I hope this will help CF user who wants to integrate CF loggregator with Kafka.

While writing this, we also wrote small golang package for building nozzle, https://github.com/rakutentech/go-nozzle. This helps you writing a new nozzle.

If you have interest, please check each repository. And PR or issues are always welcome :)

Thanks.
--

Taichi Nakashima (https://github.com/tcnksm)

+ Gentle Reminder

From: Nithiyasri Gnanasekaran -X (ngnanase - TECH MAHINDRA LIM at Cisco)
Sent: Tuesday, April 26, 2016 5:17 PM
To: 'Amit Gupta' <agupta(a)pivotal.io>
Cc: Discussions about Cloud Foundry projects and the system overall. <cf-dev(a)lists.cloudfoundry.org>; Jayarajan Ramapurath Kozhummal (jayark) <jayark(a)cisco.com>
Subject: RE: Reg combining vms in cf-231

Hi Amit

Thanks for your reply…
Now I could combine all the jobs of cf-231 into one vm, but blobstore process alone shows the following error:

2016/04/26 11:04:29 [emerg] 23408#0: listen() to 0.0.0.0:80, backlog 511 failed (98: Address already in use)
2016/04/26 11:05:17 [emerg] 23952#0: listen() to 0.0.0.0:80, backlog 511 failed (98: Address already in use)

Attached is the yml file
So I had modified the blobstore:port to 82 and redeployed.. But this change is not reflecting in the VM and again getting the same error.
Pls let me know if I have to modify anyother property

This is a kind of showstopper for us.

Regards
Nithiyasri



From: Amit Gupta [mailto:agupta(a)pivotal.io]
Sent: Monday, April 25, 2016 9:57 PM
To: Nithiyasri Gnanasekaran -X (ngnanase - TECH MAHINDRA LIM at Cisco) <ngnanase(a)cisco.com<mailto:ngnanase(a)cisco.com>>
Cc: Discussions about Cloud Foundry projects and the system overall. <cf-dev(a)lists.cloudfoundry.org<mailto:cf-dev(a)lists.cloudfoundry.org>>; Jayarajan Ramapurath Kozhummal (jayark) <jayark(a)cisco.com<mailto:jayark(a)cisco.com>>
Subject: Re: Reg combining vms in cf-231

Your first job has consul services, so you'll need to colocate the consul_agent there too. You also don't have any consul servers running anywhere.

On Mon, Apr 25, 2016 at 7:25 AM, Nithiyasri Gnanasekaran -X (ngnanase - TECH MAHINDRA LIM at Cisco) <ngnanase(a)cisco.com<mailto:ngnanase(a)cisco.com>> wrote:
Hi Amit
I am using cf-231 release.
In the spiff generated yml, I could combine api_worker and cloud_controller jobs into one, dea-spare with router.
But when I remove consul as a separate VM and combine it with api_worker and cloud_controller . The consul process is not starting in router and haproxy.
If I have a separate consul vm, this problem doesn’t occur.

Following is the consul process error in router.

error during start: timeout exceeded
2016/04/25 08:57:06 [ERR] agent.client: Failed to decode response header: EOF
++ logger -p user.info<http://user.info> -t vcap.consul-agent
++ tee -a /var/vcap/sys/log/consul_agent/consul_agent.stdout.log
error during start: timeout exceeded
2016/04/25 08:58:15 [ERR] agent.client: Failed to decode response header: EOF
++ logger -p user.info<http://user.info> -t vcap.consul-agent
++ tee -a /var/vcap/sys/log/consul_agent/consul_agent.stdout.log

Pls let me know how can I fix this.

Regards
Nithiyasri

I've used TCP/8080 but with a TLS listener as a work-around for this issue. It wasn't ideal, but it solved the problem and we had limited options as TCP/8080 was one of the few egress ports allowed. I think a better approach is adding a second ELB as you noted.

Hi Amit

Thanks for your reply…
Now I could combine all the jobs of cf-231 into one vm, but blobstore process alone shows the following error:

2016/04/26 11:04:29 [emerg] 23408#0: listen() to 0.0.0.0:80, backlog 511 failed (98: Address already in use)
2016/04/26 11:05:17 [emerg] 23952#0: listen() to 0.0.0.0:80, backlog 511 failed (98: Address already in use)

Attached is the yml file
So I had modified the blobstore:port to 82 and redeployed.. But this change is not reflecting in the VM and again getting the same error.
Pls let me know if I have to modify anyother property

This is a kind of showstopper for us.

Regards
Nithiyasri



From: Amit Gupta [mailto:agupta(a)pivotal.io]
Sent: Monday, April 25, 2016 9:57 PM
To: Nithiyasri Gnanasekaran -X (ngnanase - TECH MAHINDRA LIM at Cisco) <ngnanase(a)cisco.com>
Cc: Discussions about Cloud Foundry projects and the system overall. <cf-dev(a)lists.cloudfoundry.org>; Jayarajan Ramapurath Kozhummal (jayark) <jayark(a)cisco.com>
Subject: Re: Reg combining vms in cf-231

Your first job has consul services, so you'll need to colocate the consul_agent there too. You also don't have any consul servers running anywhere.

On Mon, Apr 25, 2016 at 7:25 AM, Nithiyasri Gnanasekaran -X (ngnanase - TECH MAHINDRA LIM at Cisco) <ngnanase(a)cisco.com<mailto:ngnanase(a)cisco.com>> wrote:
Hi Amit
I am using cf-231 release.
In the spiff generated yml, I could combine api_worker and cloud_controller jobs into one, dea-spare with router.
But when I remove consul as a separate VM and combine it with api_worker and cloud_controller . The consul process is not starting in router and haproxy.
If I have a separate consul vm, this problem doesn’t occur.

Following is the consul process error in router.

error during start: timeout exceeded
2016/04/25 08:57:06 [ERR] agent.client: Failed to decode response header: EOF
++ logger -p user.info<http://user.info> -t vcap.consul-agent
++ tee -a /var/vcap/sys/log/consul_agent/consul_agent.stdout.log
error during start: timeout exceeded
2016/04/25 08:58:15 [ERR] agent.client: Failed to decode response header: EOF
++ logger -p user.info<http://user.info> -t vcap.consul-agent
++ tee -a /var/vcap/sys/log/consul_agent/consul_agent.stdout.log

Pls let me know how can I fix this.

Regards
Nithiyasri

Hi

Check with 8080 port

Pls let me know is it https u r using as the port mentioned is secure one

In addition u can use Soap port in the protocol and port range definition

Other option is to use udp or icmp in addition to the prtocols used so that
from the pool of ports socket request will be. Handled

Regards
Sunil

--
Thanks & Regards
Sunil Babu K C
+91-81970-35608

Hi Shannon,

Same problem statement and solution/workaround here. Changing such a corporate setup usually is much more time consuming (if successful at all) compared to the changes in CF setup as you describe them below.

Regards,
Bernd

Bernd Krannich
Products & Innovation Technology
SAP SE
Dietmar-Hopp-Allee 16
69190 Walldorf Germany
mailto:bernd.krannich(a)sap.com
www.sap.com<applewebdata://52CF34BC-FCAD-4C8A-90F6-8A24A9EFD5CC/www.sap.com>

Pflichtangaben/Mandatory Disclosure Statements: http://www.sap.com/company/legal/impressum.epx

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

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

From: Shannon Coen <scoen(a)pivotal.io<mailto:scoen(a)pivotal.io>>
Reply-To: "Discussions about Cloud Foundry projects and the system overall." <cf-dev(a)lists.cloudfoundry.org<mailto:cf-dev(a)lists.cloudfoundry.org>>
Date: Monday 25 April 2016 at 23:00
To: Cloud Foundry Dev <cf-dev(a)lists.cloudfoundry.org<mailto:cf-dev(a)lists.cloudfoundry.org>>
Subject: [cf-dev] websockets and limitations of AWS ELB

I'm interested to hear from operators how you're supporting websockets for CF on AWS, both for user tailing of app logs from Loggregator, and for apps running on CF that take websocket requests.

Websockets are supported in CF by having a HTTP request containing the Upgrade header reach Gorouter, which will establish a TCP connection to the backend (app instance). Since we need Gorouter to handle the upgrade, your ELB must be configured to listen on a port in TCP mode. However, in TCP mode an ELB wouldn't be able to append the required X-Forwarded-For and X-Forwarded-Proto headers. Assuming you'll keep HTTP over TLS on port 443, you'll need to open an additional port on the ELB for websockets.

To support apps on PWS that take websocket requests, we've added port 4443 to the ELB in TCP mode. In response to feedback that this port is blocked to corporate firewalls, we run a second ELB just for Loggregator, listening on 443 in TCP mode. The domain name for Loggregator's route resolves to this second ELB.

How are you working around this limitation? Do your users have issues with configuring clients to make websocket requests on a non-standard port?

Thank you,

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

I'm not sure of your precise use cases, but I'd suggest looking into the
implementation of Tasks [1] based on the v3 cloud controller api [2].
With tasks you can spin up containers on the fly fairly quickly, I wouldn't
promise within milliseconds, but I've observed within a couple of seconds,
and that task can be run in the context of your application code base.

[1]
https://docs.google.com/document/d/1CCHDUa2UWRjXkxEdksX4M9BGQ8hBqiMys46wxeF5XE4/edit?usp=sharing
[2] http://v3-apidocs.cloudfoundry.org/

An simple servlet can reproduce my problem on standard bosh lite CF.

1. push to the app the bosh lite
cf push test -p ./test.war

2. access the servlet deployed on CF

wget http://test.[my-domain]/test
--2016-04-26 09:18:49-- http://test.[my-domain]/test
Resolving test.[my-domain]... 54.10.100.100
Connecting to test.[my-domain]|54.10.100.100|:80... connected.
HTTP request sent, awaiting response... 414 Request URI Too Long
2016-04-26 09:18:51 ERROR 414: Request URI Too Long.

3. check the servlet on non CF

wget http://localhost:8080/test/test
--2016-04-26 09:20:55-- http://localhost:8080/test/test
Resolving localhost... ::1, 127.0.0.1
Connecting to localhost|::1|:8080... connected.
HTTP request sent, awaiting response... 414 my customized 414 error message
2016-04-26 09:20:55 ERROR 414: my customized 414 error message.


"my customized 414 error message" is my customized error message for 414
status in my case, but it's always "Request URI Too Long" on CF instance
now.

And the servlet is very simple:
{code}

protected void doGet(HttpServletRequest request,
HttpServletResponse response) throws ServletException, IOException {

// TODO Auto-generated method stub

response.sendError(414,"my customized 414 error message");

}

{code}









On Mon, Apr 25, 2016 at 10:54 PM, Stanley Shen <meteorping(a)gmail.com> wrote:

Actually one CF instance is bosh lite one deployed on AWS, I didn't change
things related to haproxy.
I also can reproduce it on this bosh lite instance.

- default_networks:
- name: cf1
static_ips: null
instances: 1
name: ha_proxy_z1
networks:
- name: cf1
static_ips:
- 10.244.0.34
properties:
ha_proxy:
ssl_pem: |+
-----BEGIN CERTIFICATE-----
MIICsjCCAZoCCQC+xvE/1ZQgFzANBgkqhkiG9w0BAQUFADAaMRgwFgYDVQQDFA8q
LmJvc2gtbGl0ZS5jb20wIBcNMTUxMDA4MjIwNDQ3WhgPMjI4OTA3MjIyMjA0NDda
MBoxGDAWBgNVBAMUDyouYm9zaC1saXRlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQAD
ggEPADCCAQoCggEBAK09Q520xrKx75uew3mAS+y4uyRPZPEjt/pYdBl40PXIwaqO
X7LGoc9lNZS/eAPX6xeVFmZbLZReQ5+Fm0moeLzsh58W9jjkWWk7oGISmxfoQz9B
X9Eh0NHCrtKXMrCPlr+2RI/qLinJDqn87UEZqwX+84JU8hBZ8RD8D7YnfuDteySV
SYOEUjkiN/pIWmbJQY1sjEyk1zH1Hiy8kmnait2sX8Td2S/aV6EJBgODOstzEtnf
HFDIfoTJxbSK/0TbF6qBaSl0CLaOop9FX2ULEZUgAuIW4dG2k/xnpMLdz7A0ZsSU
Haw9okZ5wNuYk1RSqhnqw+9KUWgXwV6RlMvtXMkCAwEAATANBgkqhkiG9w0BAQUF
AAOCAQEAShOqAFLIc93yIjhcnN7L4ZXFo+CvOgklJqFeBbwRshsEptbaddDJYmRr
ZXzOE7MiTOBM8YzKqtHvl/ZguXmIAXSZlnq6kuJHdPtcZOqu1x2GAvWWOzn9Xl4m
T3RmwF3NgiX0jgNMkkm8i8jfT7uN9BnHxMv65b9yKeM0sRFN5XigA43DDQnfF3j4
FQ9jwpmS7zOx2wn6FayOgoE4rgJfV/9637ZprQOMfUbZPKgQQplDn6bvK13rj9g9
zCC9W0fy29l7VDuAOOSI5xzsoYyH6DfX7oySxn291hidSCb/buadNG4dgI4keMGw
u5K8QQYmlSY91IJtuRRITYXGmIiPpg==
-----END CERTIFICATE-----
-----BEGIN RSA PRIVATE KEY-----
MIIEogIBAAKCAQEArT1DnbTGsrHvm57DeYBL7Li7JE9k8SO3+lh0GXjQ9cjBqo5f
ssahz2U1lL94A9frF5UWZlstlF5Dn4WbSah4vOyHnxb2OORZaTugYhKbF+hDP0Ff
0SHQ0cKu0pcysI+Wv7ZEj+ouKckOqfztQRmrBf7zglTyEFnxEPwPtid+4O17JJVJ
g4RSOSI3+khaZslBjWyMTKTXMfUeLLySadqK3axfxN3ZL9pXoQkGA4M6y3MS2d8c
UMh+hMnFtIr/RNsXqoFpKXQIto6in0VfZQsRlSAC4hbh0baT/Gekwt3PsDRmxJQd
rD2iRnnA25iTVFKqGerD70pRaBfBXpGUy+1cyQIDAQABAoIBACXzdt2UnbbF3jzU
QfRbE8bvDSg+MFnXPlWcjQqLehNuAGcxu2s5snbxsBQ/Abat1XWcFoUj0k9feyb2
KPew7YpNssQ6ToRWGfRAuLjjZJCPNDQmSSxSYSGiqZO+xb8CJb8n2ctBPQ2wWwMI
Qp1xVxMAMC5MF59XZMUYwwRfkJ8LawB90+S9BjHcU3GqoPECLFkgEeIj3mrnmpAD
vhIeYvQj2W5JCpxLUA+7lnyoqnx8OTOXvBPAsKwO1Hx88yCitnxXro7i0ZAw4ErH
zrnMgWkFDvRiS3ta/QS2RcBBiZHKX/gRRT/AvqJ+Erveu0BcZ9AVy1UpPB0w9rBK
PTxS2BECgYEA3MLd6Og+xQpw4UNhy9EjeDE/b/rZK4w/vfD3WE5J3Nm4HGdSA6Q4
YmQYVg+VuCLR+HHsk58LxEf+cU0MNgDJR1/rFZRmociF+G0i7/7DuhFm891wWWGW
Iz7XeGWHi+LIeYWkteuflrkmvy/7xqArgcNqnirGhba6706MZz0G0YUCgYEAyOR5
aF7qRpLXHgMOPOzJKC4ceWA5rY8rcdJZFI7aNq5MJF9o+fNNt8YRJ1hQTzs5K/R+
HwBJel8J6CoPQo9WUXnj0md4M67sCZSBqWANMO/J0f4VkbLS/lwch+ZPS8jt3Z4z
umYW4QnloIKXxORfySo7r9DzZSgmxuDE8PVWn3UCgYAFTwpXF36q7l1YjW5EoHrh
4Q1NfBLM4UqHHsxT604LaZDr3fAy9jgE5bNQHn/TNcMm3lZ6FlEKH1EXGGs6wToV
5VCZ7D+rlE7kcntsmgvK5bA8HQ8elyItJs23r3la+9EmWvhjB4+G6FzuLBE57ZAe
RrzBoPW1MXe9WX423VjUoQKBgGea5T49jSc+fbDdtI8ZMxkExuyWAskOyEIYUJa4
obOHqn8rsZEOuKspfBlFg42JJpATtKO6WyrALvTMFDiogcTdTvBpKmXFNbgvHbvD
bKorUHN7TZZpmkVSLeisj4KvKnWcLGNaWTxQBVwFXc5OVVQC8utWoOAvl+gDba4z
aSwtAoGANdquHRNbigPj2y0cRoexYJwKgpfGEK4HXitsKZUUg09gVfagM1HynVFz
RA0LVac0oJZFdMYZyU/PXCySS237xUD2/0oySYJIK9E0C4ZxKD+DoAk5Z097z0LM
7rxStMCBWB2x4ommvEnpdgntEKkl4buIDatvmbdmdwkY3+X65Ks=
-----END RSA PRIVATE KEY-----
metron_agent:
zone: z1
router:
servers:
z1:
- 10.244.0.22
z2: []
resource_pool: router_z1
templates:
- name: haproxy
release: cf
- name: metron_agent
release: cf
- name: consul_agent
release: cf
update: {}

On 25 April 2016 at 22:54, Stanley Shen <meteorping(a)gmail.com> wrote:

Actually one CF instance is bosh lite one deployed on AWS, I didn't change
things related to haproxy.
I also can reproduce it on this bosh lite instance.

- default_networks:
- name: cf1
static_ips: null
instances: 1
name: ha_proxy_z1
networks:
- name: cf1
static_ips:
- 10.244.0.34
properties:
ha_proxy:
ssl_pem: |+
-----BEGIN CERTIFICATE-----
MIICsjCCAZoCCQC+xvE/1ZQgFzANBgkqhkiG9w0BAQUFADAaMRgwFgYDVQQDFA8q
LmJvc2gtbGl0ZS5jb20wIBcNMTUxMDA4MjIwNDQ3WhgPMjI4OTA3MjIyMjA0NDda
MBoxGDAWBgNVBAMUDyouYm9zaC1saXRlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQAD
ggEPADCCAQoCggEBAK09Q520xrKx75uew3mAS+y4uyRPZPEjt/pYdBl40PXIwaqO
X7LGoc9lNZS/eAPX6xeVFmZbLZReQ5+Fm0moeLzsh58W9jjkWWk7oGISmxfoQz9B
X9Eh0NHCrtKXMrCPlr+2RI/qLinJDqn87UEZqwX+84JU8hBZ8RD8D7YnfuDteySV
SYOEUjkiN/pIWmbJQY1sjEyk1zH1Hiy8kmnait2sX8Td2S/aV6EJBgODOstzEtnf
HFDIfoTJxbSK/0TbF6qBaSl0CLaOop9FX2ULEZUgAuIW4dG2k/xnpMLdz7A0ZsSU
Haw9okZ5wNuYk1RSqhnqw+9KUWgXwV6RlMvtXMkCAwEAATANBgkqhkiG9w0BAQUF
AAOCAQEAShOqAFLIc93yIjhcnN7L4ZXFo+CvOgklJqFeBbwRshsEptbaddDJYmRr
ZXzOE7MiTOBM8YzKqtHvl/ZguXmIAXSZlnq6kuJHdPtcZOqu1x2GAvWWOzn9Xl4m
T3RmwF3NgiX0jgNMkkm8i8jfT7uN9BnHxMv65b9yKeM0sRFN5XigA43DDQnfF3j4
FQ9jwpmS7zOx2wn6FayOgoE4rgJfV/9637ZprQOMfUbZPKgQQplDn6bvK13rj9g9
zCC9W0fy29l7VDuAOOSI5xzsoYyH6DfX7oySxn291hidSCb/buadNG4dgI4keMGw
u5K8QQYmlSY91IJtuRRITYXGmIiPpg==
-----END CERTIFICATE-----
-----BEGIN RSA PRIVATE KEY-----
MIIEogIBAAKCAQEArT1DnbTGsrHvm57DeYBL7Li7JE9k8SO3+lh0GXjQ9cjBqo5f
ssahz2U1lL94A9frF5UWZlstlF5Dn4WbSah4vOyHnxb2OORZaTugYhKbF+hDP0Ff
0SHQ0cKu0pcysI+Wv7ZEj+ouKckOqfztQRmrBf7zglTyEFnxEPwPtid+4O17JJVJ
g4RSOSI3+khaZslBjWyMTKTXMfUeLLySadqK3axfxN3ZL9pXoQkGA4M6y3MS2d8c
UMh+hMnFtIr/RNsXqoFpKXQIto6in0VfZQsRlSAC4hbh0baT/Gekwt3PsDRmxJQd
rD2iRnnA25iTVFKqGerD70pRaBfBXpGUy+1cyQIDAQABAoIBACXzdt2UnbbF3jzU
QfRbE8bvDSg+MFnXPlWcjQqLehNuAGcxu2s5snbxsBQ/Abat1XWcFoUj0k9feyb2
KPew7YpNssQ6ToRWGfRAuLjjZJCPNDQmSSxSYSGiqZO+xb8CJb8n2ctBPQ2wWwMI
Qp1xVxMAMC5MF59XZMUYwwRfkJ8LawB90+S9BjHcU3GqoPECLFkgEeIj3mrnmpAD
vhIeYvQj2W5JCpxLUA+7lnyoqnx8OTOXvBPAsKwO1Hx88yCitnxXro7i0ZAw4ErH
zrnMgWkFDvRiS3ta/QS2RcBBiZHKX/gRRT/AvqJ+Erveu0BcZ9AVy1UpPB0w9rBK
PTxS2BECgYEA3MLd6Og+xQpw4UNhy9EjeDE/b/rZK4w/vfD3WE5J3Nm4HGdSA6Q4
YmQYVg+VuCLR+HHsk58LxEf+cU0MNgDJR1/rFZRmociF+G0i7/7DuhFm891wWWGW
Iz7XeGWHi+LIeYWkteuflrkmvy/7xqArgcNqnirGhba6706MZz0G0YUCgYEAyOR5
aF7qRpLXHgMOPOzJKC4ceWA5rY8rcdJZFI7aNq5MJF9o+fNNt8YRJ1hQTzs5K/R+
HwBJel8J6CoPQo9WUXnj0md4M67sCZSBqWANMO/J0f4VkbLS/lwch+ZPS8jt3Z4z
umYW4QnloIKXxORfySo7r9DzZSgmxuDE8PVWn3UCgYAFTwpXF36q7l1YjW5EoHrh
4Q1NfBLM4UqHHsxT604LaZDr3fAy9jgE5bNQHn/TNcMm3lZ6FlEKH1EXGGs6wToV
5VCZ7D+rlE7kcntsmgvK5bA8HQ8elyItJs23r3la+9EmWvhjB4+G6FzuLBE57ZAe
RrzBoPW1MXe9WX423VjUoQKBgGea5T49jSc+fbDdtI8ZMxkExuyWAskOyEIYUJa4
obOHqn8rsZEOuKspfBlFg42JJpATtKO6WyrALvTMFDiogcTdTvBpKmXFNbgvHbvD
bKorUHN7TZZpmkVSLeisj4KvKnWcLGNaWTxQBVwFXc5OVVQC8utWoOAvl+gDba4z
aSwtAoGANdquHRNbigPj2y0cRoexYJwKgpfGEK4HXitsKZUUg09gVfagM1HynVFz
RA0LVac0oJZFdMYZyU/PXCySS237xUD2/0oySYJIK9E0C4ZxKD+DoAk5Z097z0LM
7rxStMCBWB2x4ommvEnpdgntEKkl4buIDatvmbdmdwkY3+X65Ks=
-----END RSA PRIVATE KEY-----
metron_agent:
zone: z1
router:
servers:
z1:
- 10.244.0.22
z2: []
resource_pool: router_z1
templates:
- name: haproxy
release: cf
- name: metron_agent
release: cf
- name: consul_agent
release: cf
update: {}

Hi CLI users,

With apps deployed to DEAs, a health check is performed at application start-up targeting the app's port, unless you specified `--no-route`, in which case the process is monitored.
With Diego, the health check is performed continuously and the type of check was exposed through an option to the `cf push` command.
This option defaults to `port`, which isn't always appropriate for apps pushed without a route, such as worker apps.

We propose fixing the `--health-check-type` option's default value to align with the behaviour seen for DEAs, i.e. to use "none" if option `--no-route` is used:

--health-check-type, -u Application health check type (Default: 'none' if '--no-route' is set, otherwise 'port')`
Would anyone object to such change?

Cheers,
Dies Koper
Cloud Foundry CLI PM

Following up on this thread, we plan on spending some time this week to
discuss the functionality of the Binary Service Broker. If you have any
additional feedback regarding the project we urge you to comment on the
feature narrative [1
<https://docs.google.com/document/d/145aOpNoq7BpuB3VOzUIDh-HBx0l3v4NHLYfW8xt2zK0/edit?usp=gmail>
]

[1] -
https://docs.google.com/document/d/145aOpNoq7BpuB3VOzUIDh-HBx0l3v4NHLYfW8xt2zK0/edit?usp=gmail

The problem right now is that the buildpack names are no longer available during staging. All the code is available (because the stager needs to call `bin/detect` for each buildpack in turn), but it uses a hash as the directory name.

I made a quick experiment that grabs the mapping from buildpack names to filesystem location directly out of the CCDB and stuffs it into a CF_BUILDPACKS environment variable. With that in place, it is a trivial change to extend the multi-buildpack to support admin buildpacks as well. I've put some more information into the README.md:

https://github.com/jandubois/cf-buildpack-multi

I haven't tested this with the legacy DEA; I only checked it with Diego.

I would be happy to work on patches for CC and Stager to implement support for CF_BUILDPACKS if this approach is considered useful by the community, and acceptable to buildpack team.

Please let me know what you think about this approach!

Cheers,
-Jan


From: Jack Cai <greensight(a)gmail.com<mailto:greensight(a)gmail.com>>
Reply-To: "Discussions about Cloud Foundry projects and the system overall." <cf-dev(a)lists.cloudfoundry.org<mailto:cf-dev(a)lists.cloudfoundry.org>>
Date: Tuesday, April 12, 2016 at 9:36
To: "Discussions about Cloud Foundry projects and the system overall." <cf-dev(a)lists.cloudfoundry.org<mailto:cf-dev(a)lists.cloudfoundry.org>>
Subject: [cf-dev] Re: Re: Request for Multibuildpack Use Cases

It would be more useful if the multi-buildpack can reference an admin buildpack in addition to a remote git-hosted buildpack. :-)

Jack

I'm interested to hear from operators how you're supporting websockets for
CF on AWS, both for user tailing of app logs from Loggregator, and for apps
running on CF that take websocket requests.

Websockets are supported in CF by having a HTTP request containing the
Upgrade header reach Gorouter, which will establish a TCP connection to the
backend (app instance). Since we need Gorouter to handle the upgrade, your
ELB must be configured to listen on a port in TCP mode. However, in TCP
mode an ELB wouldn't be able to append the required X-Forwarded-For and
X-Forwarded-Proto headers. Assuming you'll keep HTTP over TLS on port 443,
you'll need to open an additional port on the ELB for websockets.

To support apps on PWS that take websocket requests, we've added port 4443
to the ELB in TCP mode. In response to feedback that this port is blocked
to corporate firewalls, we run a second ELB just for Loggregator, listening
on 443 in TCP mode. The domain name for Loggregator's route resolves to
this second ELB.

How are you working around this limitation? Do your users have issues with
configuring clients to make websocket requests on a non-standard port?

Thank you,

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

Separate VM not necessary, you need a consul server cluster though, can't
just have consul agents in client mode. Your server cluster can be
colocated with other VMs, and the servers can act as clients broadcasting
services.

On Mon, Apr 25, 2016 at 10:37 AM, Nithiyasri Gnanasekaran -X (ngnanase -
TECH MAHINDRA LIM at Cisco) <ngnanase(a)cisco.com> wrote:

Forgot to mention that I collocated consul_agent with api_worker and also
enabled it in server mode and removed it as a separate vm.

Even after this, the consul_agent process was not coming up in router..



*From:* Nithiyasri Gnanasekaran -X (ngnanase - TECH MAHINDRA LIM at
Cisco)
*Sent:* Monday, April 25, 2016 10:55 PM
*To:* 'Amit Gupta' <agupta(a)pivotal.io>
*Cc:* Discussions about Cloud Foundry projects and the system overall. <
cf-dev(a)lists.cloudfoundry.org>
*Subject:* RE: Reg combining vms in cf-231



Hi Amit



Pls let me know if consul as a separate vm is necessary for cf-231
deployment, though we collocate consul_agent in every other job of cf-231



Regards

Nithiyasri



*From:* Amit Gupta [mailto:agupta(a)pivotal.io <agupta(a)pivotal.io>]
*Sent:* Monday, April 25, 2016 9:57 PM
*To:* Nithiyasri Gnanasekaran -X (ngnanase - TECH MAHINDRA LIM at Cisco) <
ngnanase(a)cisco.com>
*Cc:* Discussions about Cloud Foundry projects and the system overall. <
cf-dev(a)lists.cloudfoundry.org>; Jayarajan Ramapurath Kozhummal (jayark) <
jayark(a)cisco.com>
*Subject:* Re: Reg combining vms in cf-231



Your first job has consul services, so you'll need to colocate the
consul_agent there too. You also don't have any consul servers running
anywhere.



On Mon, Apr 25, 2016 at 7:25 AM, Nithiyasri Gnanasekaran -X (ngnanase -
TECH MAHINDRA LIM at Cisco) <ngnanase(a)cisco.com> wrote:

Hi Amit

I am using cf-231 release.

In the spiff generated yml, I could combine api_worker and
cloud_controller jobs into one, dea-spare with router.

But when I remove consul as a separate VM and combine it with api_worker
and cloud_controller . The consul process is not starting in router and
haproxy.

If I have a separate consul vm, this problem doesn’t occur.



Following is the consul process error in router.



error during start: timeout exceeded

2016/04/25 08:57:06 [ERR] agent.client: Failed to decode response header:
EOF

++ logger -p user.info -t vcap.consul-agent

++ tee -a /var/vcap/sys/log/consul_agent/consul_agent.stdout.log

error during start: timeout exceeded

2016/04/25 08:58:15 [ERR] agent.client: Failed to decode response header:
EOF

++ logger -p user.info -t vcap.consul-agent

++ tee -a /var/vcap/sys/log/consul_agent/consul_agent.stdout.log



Pls let me know how can I fix this.



Regards

Nithiyasri

Pls change the lookup location and it work's

On Monday, April 25, 2016, Don Nelson <dieseldonx(a)gmail.com&gt; wrote:

What does that mean?