Date   

`router_z1/0' is not running after update

Sam Dai
 

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


Re: Intended UAA-specific user identity fields in JWT access token ?

Daniel Mikusa
 

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


Re: Intended UAA-specific user identity fields in JWT access token ?

Sunil Babu <cloudgrp.assist@...>
 

Check on the yml config file

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
<javascript:_e(%7B%7D,'cvml','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
<javascript:_e(%7B%7D,'cvml','bercheg(a)gmail.com');>> wrote:

Great, thanks Filip!


Guillaume.

On Thu, Mar 31, 2016 at 9:50 PM, Filip Hanik <fhanik(a)pivotal.io
<javascript:_e(%7B%7D,'cvml','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
<javascript:_e(%7B%7D,'cvml','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
<javascript:_e(%7B%7D,'cvml','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
<javascript:_e(%7B%7D,'cvml','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


Re: Intended UAA-specific user identity fields in JWT access token ?

Guillaume Berche
 

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.


Re: Services without Servers | Equivalent of AWS Lambda

Sunil Babu <cloudgrp.assist@...>
 

Hi

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

On Tuesday, April 26, 2016, Dieu Cao <dcao(a)pivotal.io> wrote:

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/

On Mon, Apr 25, 2016 at 10:22 AM, Mohamed, Owais <
Owais.Mohamed(a)covisint.com
<javascript:_e(%7B%7D,'cvml','Owais.Mohamed(a)covisint.com');>> wrote:

Hello,

Has anyone implemented or know of an implementation similar to that of
"AWS Lambda" using Cloud Foundry?

The idea is to have the ability to run small scripts on the fly without
having a particular container reserved for that script. At the same time
the script should start execution in milliseconds, so there is no time to
initialize a container.

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


Re: websockets and limitations of AWS ELB

Sunil Babu <placid.babu@...>
 

Pls use ingress and custom and from anywhere option

On Tuesday, April 26, 2016, Mike Jacobi <michael.jacobi(a)altoros.com> wrote:

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.


[ANN] kafka-firehose-nozzle

taichi nakashima
 

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)


Re: Reg combining vms in cf-231

Nithiyasri Gnanasekaran -X (ngnanase - TECH MAHINDRA LIM@Cisco) <ngnanase at cisco.com...>
 

+ 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


Re: websockets and limitations of AWS ELB

Mike Jacobi
 

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.


Re: Reg combining vms in cf-231

Nithiyasri Gnanasekaran -X (ngnanase - TECH MAHINDRA LIM@Cisco) <ngnanase at cisco.com...>
 

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


Re: websockets and limitations of AWS ELB

Sunil Babu <cloudgrp.assist@...>
 

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

On Tuesday, April 26, 2016, Shannon Coen <scoen(a)pivotal.io> wrote:

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.
--
Thanks & Regards
Sunil Babu K C
+91-81970-35608


Re: websockets and limitations of AWS ELB

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

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.


Re: Services without Servers | Equivalent of AWS Lambda

Dieu Cao <dcao@...>
 

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/

On Mon, Apr 25, 2016 at 10:22 AM, Mohamed, Owais <Owais.Mohamed(a)covisint.com
wrote:
Hello,

Has anyone implemented or know of an implementation similar to that of
"AWS Lambda" using Cloud Foundry?

The idea is to have the ability to run small scripts on the fly without
having a particular container reserved for that script. At the same time
the script should start execution in milliseconds, so there is no time to
initialize a container.

Regards,
Owais


Re: HTTP request status text is changed

Stanley Shen <meteorping@...>
 

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: {}


aligning cf push health-check default value

Koper, Dies <diesk@...>
 

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


Re: Binary Service Broker Feature Narrative

Danny Rosen
 

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

On Wed, Apr 6, 2016 at 4:07 PM, Mike Youngstrom <youngm(a)gmail.com> wrote:

Thanks for the responses Mike. See inline:

To be clear, I think we're happy to test third-party agent in our CI
pipelines to ensure they'll continue to work. I think this addresses your
"breaking change" point in a very sustainable way.
Adding thirdparty agents to the CI pipeline will help. But, if there is
ever a breaking change in a buildpack we now have a loose dependency on the
thirdparty broker being upgraded before I can potentially upgrade to a new
cf-release. It is that kind of loose dependency breakage that I'm more
concerned about.


I'd like to explore whether we can meet agent requirements with profile.d
and/or buildpack lifecycle hooks. If we find a compelling blocker, we can
revisit this and related decisions. Hopefully we can convince you as well
as agent vendors that this is a reasonable path forward.
Perhaps the buildpack lifecycle hooks you mention will be good enough of
an api. Do you have anything describing the makeup of these hooks?


* Integration customization:
One of the nice things about buildpacks is the very clear customization
path. We use app dynamics and we have custom requirements for how app
dynamics should be configured that app dynamics won't want to support.
What would the story be for customizing the app dynamics broker's code that
gets injected? It would be nice if there were a simple and consistent
mechanism in place similar to what buildpacks already provide.
This isn't a use case we considered. Can you help me understand what
kinds of customizations you're making? Specifics will help drive this
conversation.
Here is our use case. App Dynamics designates an application with a
location in its UI using an App Name, Tier Name, and Node Name. Our
organization has placed specific standard naming conventions around what
specifically the App Name and Tier Name should be. My organization also
uses ServiceNow for CI management. The App Dynamics naming standard is to
use specific field in the application's CI for App Name and Tier Name. We
only allow applications to use app dynamics if they have a service now
service bound and we configure their App Name and Tier Name with values
from the service now service's credentials. That is an example.

If you think other use cases should be prioritized, then maybe we can have
that conversation with Danny.
I wasn't suggesting that you move focus off of this problem area and
towards something else. I was just pointing out that there may be an
opportunity here to kill 2 birds with one stone if we look a little
broader, since the problem appears similar to me.

You guys are the experts but let me brain storm a little here to perhaps
help the discussion along. This proposal already introduces the new
concept of some kind of "buildpack hook" contract. What if you made it
possible for users to specify buildpack hooks an needs in addition to the
buildpack as part of the application model? (Lowest common denominator this
could be an Environment Variable) Then also allow service brokers to
supply the same type of hook via VCAP_SERVICES (as this proposal
proposes). It would be nice if broker hooks could be overridden by
application configured hooks to cover odd use cases. Thoughts?

Agent components may not be open-source (or OSS-compatible with APL2.0),
and may not be licensed for general redistribution by Foundation vendors.
We'd like to enable those companies to participate in the CF ecosystem.
I agree this is an issue. Does the binary redistribution aspect of the
proposal cover this concern? Or are there also legal issues with code that
might go into a buildpack to configure these non ASL compatible agents?

Thanks for taking the time to work this through with me.

Mike


Re: Request for Multibuildpack Use Cases

Dubois, Jan <jan.dubois@...>
 

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

On Tue, Apr 12, 2016 at 6:38 AM, David Illsley <davidillsley(a)gmail.com<mailto:davidillsley(a)gmail.com>> wrote:
In the past we've used the multi-buildpack to be able to use ruby sass to compile SCSS for non-ruby projects (node and Java). In that case we used the multi-buildpack and a .buildpacks file which worked reasonably well (and was very clear).

On Mon, Apr 11, 2016 at 1:15 AM, Danny Rosen <drosen(a)pivotal.io<mailto:drosen(a)pivotal.io>> wrote:
Hi there,

The CF Buildpacks team is considering taking on a line of work to provide more formal support for multibuildpacks. Before we start, we would be interested in learning if any community users have compelling use cases they could share with us.

For more information on multibuildpacks, see Heroku's documentation [1]

[1] - https://devcenter.heroku.com/articles/using-multiple-buildpacks-for-an-app


websockets and limitations of AWS ELB

Shannon Coen
 

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.


Re: Reg combining vms in cf-231

Amit Kumar Gupta
 

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





Re: Persistent problem with -p option for cups and uups

Don Nelson
 

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?