Date   

Response.write issue on bluemix

Gayathri Raghavendra prasad <graghav@...>
 

Hello,

I wrote a simple app which writes continuous chunks of data using
response.write. The code is below. This works fine when I run it locally
but the output never shows when the app runs on bluemix.
The CF version on Bluemix : CF210.2 . Will appreciate any help on why this
behavior.

var app = require('express')(),
http = require('http');

app.get('/', function(req, res){
var timer = setInterval(function () {
res.write('Hellooo\n\n')

res.write('Hiii\n\n')

}, 2000)

res.on('close', function () {
clearInterval(timer)
})

});
http.createServer(app).listen(process.env.VCAP_APP_PORT || '2000',
function(){
console.log('Express server listening on port
'+(process.env.VCAP_APP_PORT || '2000'));
});

Thanks,
Gayathri


CF CLI Version 6.12.1

Greg Oehmen
 

The CF CLI team released version 6.12.1 on 7/6/2015. Release notes,
download instructions and binaries are available at:

https://github.com/cloudfoundry/cli/releases


Highlights of this release include:

Plugin API -
https://github.com/cloudfoundry/cli/blob/master/plugin_examples/DOC.md

Full Support for Service keys / Async Service Operations -
http://docs.cloudfoundry.org/services/asynchronous-operations.html

Full Support for Arbitrary Parameters for Service Instance Provisioning -
https://docs.google.com/document/d/1QYHH3T4Dy1tjLj-FrkrVhgfgCzQCyIlTCIPBe9RMFAs/edit


General UX Refinements


-

Allow `cf app` to display buildpack
-

Add Buildpack to `cf create-app-manifest`
-

Added support for “--no-hostname” attribute in `cf create-app-manifest`
command
-

Removed ‘as admin’.. clause from create-user since it is confusing
-

Added fields to CLI MSI installer to show app/publisher name in windows
-

Removed Windows incompatible language test
-

Enabled full word ‘yes’ for confirmation when lang is not en_US
-

Enabled file reference containing JSON when creating a service instance
-

Support for godeps newest noaa package - new noaa.Close() method
-

Support for loggregator/Noaa endpoint Changes
-

Fixed bug: CLI upload fails at 2nd push with `EmptyDirError`
-

Fixed bug: index out of range panic when getting stats for Diego app
while Diego stats endpoint is down
-

Fixed bug: do not create zip when no file to upload during cf push
-

Fixed bug: cf start uses old loggregator to tail logs, instead of noaa



Improvements to text output/error messaging


-

Fixed `cf push -p` help verbiage
-

Improved restage tip to include name of app
-

Rewrote cf update-service help text error to be more descriptive
-

Highlighted restage command in uups tip
-

Updated tip for updating UPSIs - UPSIs now propagate their credentials
on update, so no need to unbind and rebind them.
-

Added error handling for when diego /instances is up but /noaa is down.



Pull Requests

#470 <https://github.com/cloudfoundry/cli/pull/470> - Fix flaky test for go
1.4 where map iteration order is randomized.

#366 <https://github.com/cloudfoundry/cli/pull/366> -Fixed error message
when there is a mismatch in the order of arguments for create-buildpack


Additions to the CF-Community Plugin Repo:

cf-download - v1.0.0 Plugin for downloading your application contents
after staging

Scaleover - v.0.1.0 Roll traffic from one app to another by scaling
over time

Diego-SSH - v.0.1.2 Access Diego containers with SSH





Greg Oehmen
Cloud Foundry Product Manager


Deprecating cloudfoundry/errors repo

Dan Wendorf
 

Hi Cloud Foundry,

The Cloud Controller NG repo has errors as a submodule under the assumption
that other teams/projects may wish to share our error yml files. The CC
team would like to deprecate that repository and fold it into CC directly.
If we do this, it may affect any teams that are using cloudfoundry/errors.

Are you one of those teams? Please let us know if you have any use cases
for the errors repository before we deprecate it sometime in the next week.


Thanks,
Dan Wendorf & Liz Dahlstrom and the Cloud Controller team


CAB call for July 2015 - moved to 7/15 @ 8a PDT

Michael Maximilien
 

Hi, all,

After conferring with James and Chip, we've agreed to move the call to next week Wednesday @ same time (8a PDT).

This helps folks who have extended their July 4th holiday in U.S. and hopefully is not inconvenient to others.

Finally, reminders:

1. Note the call information is relatively new (same as last time). Please take note:

USA 888-426-6840; 215-861-6239 | Participant code: 1985291
Other countries: http://goo.gl/RnNfc1

2. Please add to the agenda of you have something to discuss. I will send reminders again early next week.

Agenda: https://docs.google.com/document/d/1SCOlAquyUmNM-AQnekCOXiwhLs6gveTxAcduvDcW_xI/edit

3. If you own any of the recurring meetings please update with above.

Thanks much. Best,

dr.max
ibm cloud labs
silicon valley, ca

dr.max
ibm cloud labs
silicon valley, ca

Sent from my iPhone


Re: cf restage and downtime

Mike Youngstrom <youngm@...>
 

Good to hear. Thanks Dieu!

On Mon, Jul 6, 2015 at 11:44 PM, Dieu Cao <dcao(a)pivotal.io> wrote:

Yes, we think that with the initial scope of work for the v3 cc api that
we'll have the primitives to be able to orchestrate a rolling deploy. In
v3, we've already separated out the staging step so that a new package can
be uploaded and staged without affecting the running app.

-Dieu

On Mon, Jul 6, 2015 at 9:00 PM, Mike Youngstrom <youngm(a)gmail.com> wrote:

At one point Diego was slated to look at support for rolling
restart/restage. Is that still being considered in Diego's roadmap? Also,
if there are CC API changes involved it would be nice to keep those in mind
as the V3 API evolves.

Mike

On Mon, Jul 6, 2015 at 1:09 PM, Dieu Cao <dcao(a)pivotal.io> wrote:

Hi Peter,

Actually `cf restage` does cause down time. It will stop existing
instances, stage the new app bits with the buildpack, and start new
instances.
It's possible that your app may start quickly enough that you aren't
seeing down time.
It's recommended, that for now, you should use a blue-green deployment
strategy to ensure there is no down time to your users.
If you just need your app to pick up environment variables that aren't
required during staging, you could also just restart your app instead of
restaging with each change.

-Dieu

On Fri, Jul 3, 2015 at 9:17 AM, Peter Dotchev <dotchev(a)gmail.com> wrote:

Hello,

We use some user-provided services to provide some configurations to
our apps.
Sometime we need to update the configurations but without downtime.
So we update these configs using cf update-user-provided-service
command and then we have to restage bound apps.
I have noticed that cf restage causes no downtime as it first starts
the new instances and only then stops the old ones.
This is ok for us, but I could not find any documentation of this
behaviour. Can we rely on this to stay like that in the future or would it
be better to use blue-green deployment (more manual work)?

Best regards,
Petar

_______________________________________________
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

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


Did anybody deploy a wiki as app to CF?

Stephan Weber
 

Hi,

Did anybody deploy a wiki as app to CF?
Which one?
Can you point me to a ‘how-to’?

Best regards, Stephan


Re: cf restage and downtime

Dieu Cao <dcao@...>
 

Yes, we think that with the initial scope of work for the v3 cc api that
we'll have the primitives to be able to orchestrate a rolling deploy. In
v3, we've already separated out the staging step so that a new package can
be uploaded and staged without affecting the running app.

-Dieu

On Mon, Jul 6, 2015 at 9:00 PM, Mike Youngstrom <youngm(a)gmail.com> wrote:

At one point Diego was slated to look at support for rolling
restart/restage. Is that still being considered in Diego's roadmap? Also,
if there are CC API changes involved it would be nice to keep those in mind
as the V3 API evolves.

Mike

On Mon, Jul 6, 2015 at 1:09 PM, Dieu Cao <dcao(a)pivotal.io> wrote:

Hi Peter,

Actually `cf restage` does cause down time. It will stop existing
instances, stage the new app bits with the buildpack, and start new
instances.
It's possible that your app may start quickly enough that you aren't
seeing down time.
It's recommended, that for now, you should use a blue-green deployment
strategy to ensure there is no down time to your users.
If you just need your app to pick up environment variables that aren't
required during staging, you could also just restart your app instead of
restaging with each change.

-Dieu

On Fri, Jul 3, 2015 at 9:17 AM, Peter Dotchev <dotchev(a)gmail.com> wrote:

Hello,

We use some user-provided services to provide some configurations to our
apps.
Sometime we need to update the configurations but without downtime.
So we update these configs using cf update-user-provided-service command
and then we have to restage bound apps.
I have noticed that cf restage causes no downtime as it first starts the
new instances and only then stops the old ones.
This is ok for us, but I could not find any documentation of this
behaviour. Can we rely on this to stay like that in the future or would it
be better to use blue-green deployment (more manual work)?

Best regards,
Petar

_______________________________________________
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: cf restage and downtime

Mike Youngstrom <youngm@...>
 

At one point Diego was slated to look at support for rolling
restart/restage. Is that still being considered in Diego's roadmap? Also,
if there are CC API changes involved it would be nice to keep those in mind
as the V3 API evolves.

Mike

On Mon, Jul 6, 2015 at 1:09 PM, Dieu Cao <dcao(a)pivotal.io> wrote:

Hi Peter,

Actually `cf restage` does cause down time. It will stop existing
instances, stage the new app bits with the buildpack, and start new
instances.
It's possible that your app may start quickly enough that you aren't
seeing down time.
It's recommended, that for now, you should use a blue-green deployment
strategy to ensure there is no down time to your users.
If you just need your app to pick up environment variables that aren't
required during staging, you could also just restart your app instead of
restaging with each change.

-Dieu

On Fri, Jul 3, 2015 at 9:17 AM, Peter Dotchev <dotchev(a)gmail.com> wrote:

Hello,

We use some user-provided services to provide some configurations to our
apps.
Sometime we need to update the configurations but without downtime.
So we update these configs using cf update-user-provided-service command
and then we have to restage bound apps.
I have noticed that cf restage causes no downtime as it first starts the
new instances and only then stops the old ones.
This is ok for us, but I could not find any documentation of this
behaviour. Can we rely on this to stay like that in the future or would it
be better to use blue-green deployment (more manual work)?

Best regards,
Petar

_______________________________________________
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

Sumanth Yamala
 

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


Re: revrse proxy in CF

Christopher Piraino <cpiraino@...>
 

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>
wrote:

The main goal is to have a mapping from a top level url like
abc.com/app1 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] *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>
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
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

Sumanth Yamala
 

The main goal is to have a mapping from a top level url like abc.com/app1 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] 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


Re: revrse proxy in CF

John Wong
 

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>
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
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


revrse proxy in CF

Sumanth Yamala
 

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


Re: cf restage and downtime

Dieu Cao <dcao@...>
 

Hi Peter,

Actually `cf restage` does cause down time. It will stop existing
instances, stage the new app bits with the buildpack, and start new
instances.
It's possible that your app may start quickly enough that you aren't seeing
down time.
It's recommended, that for now, you should use a blue-green deployment
strategy to ensure there is no down time to your users.
If you just need your app to pick up environment variables that aren't
required during staging, you could also just restart your app instead of
restaging with each change.

-Dieu

On Fri, Jul 3, 2015 at 9:17 AM, Peter Dotchev <dotchev(a)gmail.com> wrote:

Hello,

We use some user-provided services to provide some configurations to our
apps.
Sometime we need to update the configurations but without downtime.
So we update these configs using cf update-user-provided-service command
and then we have to restage bound apps.
I have noticed that cf restage causes no downtime as it first starts the
new instances and only then stops the old ones.
This is ok for us, but I could not find any documentation of this
behaviour. Can we rely on this to stay like that in the future or would it
be better to use blue-green deployment (more manual work)?

Best regards,
Petar

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


Re: Loggregator Runtime error: invalid memory address or nil pointer dereference

Erik Jasiak <ejasiak@...>
 

Hi again Gianluca,

To follow up from the previous email - we have added this to our
investigation into a possible handshake problem between TC and our library;
we'll be investigating either way. Thank you for the issue notification!

Erik

On Wed, Jul 1, 2015 at 8:00 AM, Gianluca Volpe <gvolpe1968(a)gmail.com> wrote:

hi

does anyone faced the same issue ?

it seems to be quite important

thx



---------- Forwarded message ----------
From: Gianluca Volpe <gvolpe1968(a)gmail.com>
Date: 2015-06-23 12:30 GMT+02:00
Subject: Loggregator Runtime error: invalid memory address or nil pointer
dereference
To: cf-dev(a)lists.cloudfoundry.org


The
/var/vcap/sys/log/loggregator_trafficcontroller/loggregator_trafficcontroller.stderr.log
file has frequent occurrences of this type of snippet


2015/06/16 18:16:13 http: panic serving <routerIP>:<port>: runtime error:
invalid memory address or nil pointer dereference
goroutine 1614338 [running]:
net/http.func·011()
/usr/local/go/src/pkg/net/http/server.go:1100 +0xb7
runtime.panic(0x7c1a40, 0xa4a993)
/usr/local/go/src/pkg/runtime/panic.c:248 +0x18d

github.com/cloudfoundry/loggregatorlib/server/handlers.(*httpHandler).ServeHTTP(0xc209a61e30,
0x7f5171a3b288, 0xc20abf5ae0, 0xc20b12bad0)

/var/vcap/data/compile/loggregator_trafficcontroller/loggregator/src/
github.com/cloudfoundry/loggregatorlib/server/handlers/http_handler.go:29
+0x2f5
trafficcontroller/dopplerproxy.(*Proxy).serveWithDoppler(0xc2080ac0d0,
0x7f5171a3b288, 0xc20abf5ae0, 0xc20b12bad0, 0xc20aaacd6b, 0xa,
0xc20aaacd46, 0x24, 0x0, 0x12a05f200, ...)

/var/vcap/data/compile/loggregator_trafficcontroller/loggregator/src/trafficcontroller/dopplerproxy/doppler_proxy.go:181
+0x152
trafficcontroller/dopplerproxy.(*Proxy).serveAppLogs(0xc2080ac0d0,
0x7f5171a3b288, 0xc20abf5ae0, 0xc20b12bad0)

/var/vcap/data/compile/loggregator_trafficcontroller/loggregator/src/trafficcontroller/dopplerproxy/doppler_proxy.go:170
+0x849
trafficcontroller/dopplerproxy.(*Proxy).ServeHTTP(0xc2080ac0d0,
0x7f5171a3b288, 0xc20abf5ae0, 0xc20b12b930)

/var/vcap/data/compile/loggregator_trafficcontroller/loggregator/src/trafficcontroller/dopplerproxy/doppler_proxy.go:86
+0x4d9
net/http.serverHandler.ServeHTTP(0xc2080046c0, 0x7f5171a3b288,
0xc20abf5ae0, 0xc20b12b930)
/usr/local/go/src/pkg/net/http/server.go:1673 +0x19f
net/http.(*conn).serve(0xc20a8c6f00)
/usr/local/go/src/pkg/net/http/server.go:1174 +0xa7e
created by net/http.(*Server).Serve
/usr/local/go/src/pkg/net/http/server.go:1721 +0x313
2015/06/22 11:28:58 http: panic serving <routerIP>:<port>: runtime error:
invalid memory address or nil pointer dereference
goroutine 2034572 [running]:
net/http.func·011()
/usr/local/go/src/pkg/net/http/server.go:1100 +0xb7
runtime.panic(0x7c1a40, 0xa4a993)
/usr/local/go/src/pkg/runtime/panic.c:248 +0x18d

github.com/cloudfoundry/loggregatorlib/server/handlers.(*httpHandler).ServeHTTP(0xc20bf2d820,
0x7f5171a3b288, 0xc20d33a000, 0xc20c8c9c70)

/var/vcap/data/compile/loggregator_trafficcontroller/loggregator/src/
github.com/cloudfoundry/loggregatorlib/server/handlers/http_handler.go:29
+0x2f5
trafficcontroller/dopplerproxy.(*Proxy).serveWithDoppler(0xc2080ac0d0,
0x7f5171a3b288, 0xc20d33a000, 0xc20c8c9c70, 0xc20c96e1eb, 0xa,
0xc20c96e1c6, 0x24, 0x0, 0x12a05f200, ...)

/var/vcap/data/compile/loggregator_trafficcontroller/loggregator/src/trafficcontroller/dopplerproxy/doppler_proxy.go:181
+0x152
trafficcontroller/dopplerproxy.(*Proxy).serveAppLogs(0xc2080ac0d0,
0x7f5171a3b288, 0xc20d33a000, 0xc20c8c9c70)

/var/vcap/data/compile/loggregator_trafficcontroller/loggregator/src/trafficcontroller/dopplerproxy/doppler_proxy.go:170
+0x849
trafficcontroller/dopplerproxy.(*Proxy).ServeHTTP(0xc2080ac0d0,
0x7f5171a3b288, 0xc20d33a000, 0xc20c8c9ad0)

/var/vcap/data/compile/loggregator_trafficcontroller/loggregator/src/trafficcontroller/dopplerproxy/doppler_proxy.go:86
+0x4d9
net/http.serverHandler.ServeHTTP(0xc2080046c0, 0x7f5171a3b288,
0xc20d33a000, 0xc20c8c9ad0)
/usr/local/go/src/pkg/net/http/server.go:1673 +0x19f
net/http.(*conn).serve(0xc20c9cc680)
/usr/local/go/src/pkg/net/http/server.go:1174 +0xa7e
created by net/http.(*Server).Serve
/usr/local/go/src/pkg/net/http/server.go:1721 +0x313


thx
GV


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


Re: loggregator tc repeating error "websocket: close 1005"

Erik Jasiak <ejasiak@...>
 

Hi Gianluca - apologies for the delay; everyone here has been out on
holiday (and/or watching the world cup.)

We were originally investigating this issue as part of a separate bug - but
again, apologies: that probably wasn't clear.

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

We've since broken out a separate issue, that we believe is related, where
we're seeing a failed interchange between a TC and a client -
https://www.pivotaltracker.com/story/show/98465742

Finally, it looks like you added a separate (but possibly related) issue
over the weekend:
https://www.pivotaltracker.com/story/show/98353520

All in all, we think we have a bad handshake, and are actively digging into
it. If you happen to have any more info feel free to follow up; again
apologies for the delay in reply, and thank you for digging into this!

Much appreciated,
Erik

On Fri, Jul 3, 2015 at 3:21 AM, Gianluca Volpe <gvolpe1968(a)gmail.com> wrote:

hi Erik

did you have the chance to open the chore on this case?

if yes, are there any news about?

thx for your help

Gianluca

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


Deploying diego on openstack

Pramod Mandagere
 

Hi All,
All the documentation and github code (manifest stubs) deal with deploying
diego with bosh-lite. Are there any pointer/docs for generating an
openstack manifest for diego deployment using microbosh?
If some one has an example deployment, can u post a sample manifest,
Regards,


Re: SSH access to CF app instances on Diego

Guillaume Berche
 

Following up on James's description of the "papertrail" ssh audit traces
that the diego-ssh support is adding.

This is very useful to have these traces. Can you confirm these traces are
provided through loggregator (and don't appear in the cc events) ? I'm
however wondering how reliable can the loggregator-based logs be (as
loggregator is lossy and not designed to support reliable transport of
logs). While I understand there have been recent efforts to reduce the
lossy rate of loggregator, I'm wondering how easy it would be for a CF user
to cover its tracks (i.e. its "diego ssh" log entries), e.g. simply
flooding the loggregator with user traffic (having RTR and diego compete
for throughput into loggregator for a given app).

Thanks,

Guillaume.

On Thu, Jul 2, 2015 at 10:18 PM, James Myers <jmyers(a)pivotal.io> wrote:


From a security stand point, if you can ssh into a container, it means you
have write access to the application in CloudFoundry. Thus you can already
push new bits/change the application in question. All of the "papertrail"
functionality around pushing/changing applications exists for SSH as well
(we record events, output log lines, make it visible to users that action
was taken on the application), and thus concerned operators would be able
to determine if someone modifying the application in question.


Re: SSH access to CF app instances on Diego

Guillaume Berche
 

Hi,

please find my feedback to this thread

*short version:*
1- need preserve good CF experience with HTTP only (direct SSH flow is
still blocked and a pain in many organisations) => +1 to preserve "cf
files" or fine tune diego plug to have ssh over HTTP to work out of the box
2- default "recycle tainted containers by default" policy seems good to me
3- needs to be completed with more control of the recycling policy (UX
such as "quarantine" or GAE "lock/unlock" )
4- development use-cases need to be better supported (dev/prod parity) not
sure ssh/scp is the right path though

*long version:*

*1- cf files and ssh over HTTP*

As previously mentionned into [1], CF exposing apis over HTTP api made a
great job to be easily consummed through HTTP proxies that some companies
still use, making CF experience seemless to consumme public paas, or
private paas among corporate entities. It seems important to me to preserve
good CF experience with HTTP only.

If SSH interactive access, scp and port forwarding become the mainstream
solution to operate and troubleshoot apps (supporting "cf files",
replacement for the previous DEBUG and CONSOLE ports), it will be useful
for users behind such firewalls to be able to configure diego ssh plugin to
use HTTP/SOCKS proxies to reach public CF instances. As the diego ssh cli
plugin supports using the regular local host ssh binaries, this may
potentially be done by tweaking the .ssh config file to add flags
associated to host ssh.${domain} to go through proxies (possibly double
tunnels as described into [2]). However, for new users in such network
context, especially on windows operating system, the set up work before
using a CF public instance starts to add up?

*2- default "recycle tainted containers by default" seems good to me*

Given that apps deployed on CF comply to 12 factor apps, there instance may
be restarted at anytime (e.g. during a CF new release deployment or
stemcell upgrade). So the default policy "recycle tainted containers by
default" is not a surprise.

*3- need to be completed with more control of the recycling policy (UX such
as "quarantine" or GAE "lock/unlock" )*

There are some specific use-cases where the "recycle tainted containers by
default" policy would be problematic when running applications in
production:

An application instance is malfunctionning (e.g. hanging) and an
interactive debugging is necessary. The app-ops ssh into the container and
starts taking some diagnostic steps (e.g sending kill -SIGTERM signals to
take thread dumps, or locally changes log levels).

If ever the ssh connection breaks/timeout, the "recycle tainted containers
by default, preventing the current diagnostc to complete.

Another similar use case: a production application is suspected to be
compromised by an attacker. App-ops need to capture evidences and
understand better how the abuse was done. There isn't enough information in
streamed logs, and there is a need to get into the container to inspect the
ephemeral FS and the processes and memory. This may require more than one
simultanenous SSH connection, and may span on multiple hours

In both use-cases above, while the application is 12 factor compliant and
the "recycle tainted containers by default" policy would be opted in on the
corresponding space, there would be a need to transiently turn the mode off.

In term of user experience, this may appear as an explicit user request to
"quarantine" the tainted app instances (or the whoe app) so that CF does
not attempt to restart them. Or it may appear as the google app engine
"lock/unlock"

a call to a new "unlock" command to a CF app instance would be necessary to
get SSH access to it. CF then considers this instance as
"tained"/untrusted, as it may have deviated from the pushed content, and
does not act to it anymore (i.e. does not monitor its bound $PORT or root
process exit, which may be handy to diagnose it as wish). When the "lock"
command is requested on this instance, Cf destroys this tainted instance,
and recreates a fresh new "trusted" one.

*4- development use-cases need to be better supported (dev/prod parity) not
sure ssh/scp is the right path though*

I agree with James Myers that development use-cases should be better
supported.

First, CF should strive to support dev-prod parity [4]. However currently,
there is not anymore a version of CF that a developper can run on his
laptop (e.g. when doing offline development during commute) that would
behave like prod and embed buildpacks. There used to have "CF on a single
VM". Heroku or GAE have emulators. Cloud rocker [5] is close, but it still
takes 10s or more to have changes made on the app be reflected into a
running app.

There are some legitimate use cases during development for modifying
sources of the application and have those changes be taken in effect
immediately. Lots of app development framework supports those development
modes (even those that promote test-driven practices), and getting a fast
feedback is important. Having dev-prod parity means supporting these use
cases while preserving prod behavior (having the VCAP_SERVICES and
VCAP_APPLICATION and the buildpack processing applied on the same stack
(cflinux2)). Being able to run offline would be even better.

I however believe that providing SSH/SCP access to change the file system
to a running app instance may not be the appropriate response, given the FS
and the app instance is still ephemeral. Who would want to modify files
that could be lost at any time (e.g. a stemcell upgrade ) ?

I'd rather see value in further exploring the ideas layed out by James
Bayer into [5] e.g. as a form of a git repo populated with the
/home/vcap/app subdir, that developers could clone, push to, and have the
instance epheremal FS updated with pushed changes.

This may be combined with a cloudrocker mechanism as to work with a fully
offline mode when this is required.

[1]
https://groups.google.com/a/cloudfoundry.org/d/msg/vcap-dev/OavSBIhU_xQ/wJrT08iHfJ8J
[2] http://proxytunnel.sourceforge.net/paper.php
[3]
https://cloud.google.com/appengine/docs/managed-vms/host-env#changing_management
[4] http://12factor.net/dev-prod-parity
[5]
https://docs.google.com/document/d/1_C3OWS6giWx4JL_IL9YLA6jcppyQLVD-YjR0GeA8Z0s/edit#heading=h.toypuu5pxh65

On Thu, Jul 2, 2015 at 10:18 PM, James Myers <jmyers(a)pivotal.io> wrote:

I have to agree with Matt on this one. I feel that the recycling of
containers is a very anti-developer default. When you approach Cloud
Foundry from the perspective of running production applications the recycle
policy makes complete sense. However, I feel that this misses out on one of
the massive benefits/use cases of Cloud Foundry, what it offers to the
development process.

From a security stand point, if you can ssh into a container, it means you
have write access to the application in CloudFoundry. Thus you can already
push new bits/change the application in question. All of the "papertrail"
functionality around pushing/changing applications exists for SSH as well
(we record events, output log lines, make it visible to users that action
was taken on the application), and thus concerned operators would be able
to determine if someone modifying the application in question.

Therefore I'm lost on how this is truly the most secure default. If we are
really going by the idea that all defaults should be the most secure, ssh
should be disabled by default.

As a developer, I can see many times in which I would want to be able to
ssh into my container and change my application as part of a
troubleshooting process. Using BOSH as an example, CF Devs constantly ssh
into VMs and change the processes running on them in order to facilitate
development. BOSH does not reap the VM and redeploy a new instance when you
have closed the SSH session. Once again this is largely due to the fact
that if you have SSH access, you can already perform the necessary actions
to change the application through different means.

Another huge hindrance to development, is that the recycling policy is
controlled by administrators. It is not something that normal users can
control, even though we allow the granularity of enabling/disabling SSH
completely to the end user. This seems counterintuitive.

I feel that a better solution would be to provide the user with some
knowledge of which instances may be tainted, and then allowing them to opt
into a policy which will reap tainted containers. This provides users with
clear insight that their application instance may be a snowflake (and that
they may want to take action), while also allowing normal behavior with
regards to SSH access to containers.

To summarize, by enabling the recycling policy by default we not only
produce extremely unusual behavior / workflows for developers, we are also
minimizing the developer-friendliness of CF in general. This mixed with the
fact that as a user I cannot even control this policy, leads me to believe
that as a default recycling should be turned off as it provides the most
cohesive and friendly user experience.

On Mon, Jun 29, 2015 at 9:14 AM, John Wong <gokoproject(a)gmail.com> wrote:

after executing a command, concluding an interactive session, or
copying a file into an instance, that instance will be restarted.

How does it monitor the behavior? Is there a list of commands
whitelisted? I am curious because I am trying to find out what the
whitelist contain. Also is it at the end of the bosh ssh APP_NAME session?
What if two users are there simultaneously?

Thanks.

On Mon, Jun 29, 2015 at 5:49 AM, Dieu Cao <dcao(a)pivotal.io> wrote:

I think with the CLI we could add clarifying messaging when using ssh
what the current policy around recycling is.
Eric, what do you think about calling it the "recycling" policy, enabled
by default? =D

-Dieu


On Sat, Jun 27, 2015 at 3:42 AM, Matthew Sykes <matthew.sykes(a)gmail.com>
wrote:

Depends on your role and where your app is in the deployment pipeline.
Most of the scenarios I envisioned were for the tail end of development
where you need to poke around to debug and figure out those last few
problems.

For example, Ryan Morgan was saying that the Cloud Foundry plugin for
eclipse is going to be using the ssh support in diego to enable debug of
application instances in the context of a buildpack deployed app. This is
aligned with other requirements I've heard from people working on dev tools.

As apps reach production, I would hope that interactive ssh is disabled
entirely on the prod space leaving only scp in source mode as an option
(something the proxy can do).

Between dev and prod, there's a spectrum, but in general, I either
expect access to be enabled or disabled - not enabled with a suicidal
tendency.

On Thu, Jun 25, 2015 at 10:53 PM, Benjamin Black <bblack(a)pivotal.io>
wrote:

matt,

could you elaborate a bit on what you believe ssh access to instances
is for?


b


On Thu, Jun 25, 2015 at 9:29 PM, Matthew Sykes <
matthew.sykes(a)gmail.com> wrote:

My concern is the default behavior.

When I first prototyped this support in February, I never expected
that merely accessing a container would cause it to be terminated. As we
can see from Jan's response, it's completely unexpected; many others have
the same reaction.

I do not believe that this behavior should be part of the default
configuration and I do believe the control needs to be at the space level.
I have have already expressed this opinion during Diego retros and at the
runtime PMC meeting.

I honestly believe that if we were talking about applying this
behavior to `bosh ssh` and `bosh scp`, few would even consider running in a
'kill on taint mode' because of how useful it is. We should learn from that.

If this behavior becomes the default, I think our platform will be
seen as moving from opinionated to parochial. That would be unfortunate.


On Thu, Jun 25, 2015 at 6:05 PM, James Bayer <jbayer(a)pivotal.io>
wrote:

you can turn the "restart tainted containers" feature off with
configuration if you are authorized to do so. then using scp to write files
into a container would be persisted for the lifetime of the container even
after the ssh session ends.

On Thu, Jun 25, 2015 at 5:50 PM, Jan Dubois <jand(a)activestate.com>
wrote:

On Thu, Jun 25, 2015 at 5:36 PM, Eric Malm <emalm(a)pivotal.io>
wrote:
after executing a command, concluding an
interactive session, or copying a file into an instance, that
instance will
be restarted.
What is the purpose of being able to copy a file into an instance if
the instance is restarted as soon as the file has been received?

Cheers,
-Jan
_______________________________________________
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


--
Matthew Sykes
matthew.sykes(a)gmail.com

_______________________________________________
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


--
Matthew Sykes
matthew.sykes(a)gmail.com

_______________________________________________
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

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


loggregator tc repeating error "websocket: close 1005"

Gianluca Volpe <gvolpe1968@...>
 

hi Erik

did you have the chance to open the chore on this case?

if yes, are there any news about?

thx for your help

Gianluca