Date   

Re: VCAP_APPLICATION in the V3 Cloud Foundry API

Mike Youngstrom
 

I have a few customers that grab that instance index to aid in monitoring
and logging and to self identify in certain situations. Is there an issue
with continuing to expose the instance index?

I don't know anything about v2 vs v3 apis. Would VCAP_APPLICATION continue
to work for apps pushed using the v2 api and only have this new value if
pushed using the v3 api?

Mike

On Mon, May 2, 2016 at 2:49 PM, Daniel Mikusa <dmikusa(a)pivotal.io> wrote:

I know some of the build packs will look at application name and use that
for configuration of some of the APM agents (NewRelic, AppDynamics, etc..).


Ex:
https://github.com/cloudfoundry/java-buildpack/blob/master/config/app_dynamics_agent.yml#L21

The PHP build pack does this too.

As long as that info is exposed somewhere, it would be OK.

Dan

On Mon, May 2, 2016 at 4:34 PM, john mcteague <john.mcteague(a)gmail.com>
wrote:

While I dont use this directly, my first reaction is some libraries such
as Spring Cloud Connectors depend on this to identify that an app is
running in CF, and we rely heavily on Spring Cloud Connectors.

That being said, assuming there are alternative variable that uniquely
identify CF, the library authors could key off that instead.

On Mon, May 2, 2016 at 9:28 PM, Nicholas Calugar <ncalugar(a)pivotal.io>
wrote:

Hi CF-Dev,

The CAPI team is working hard to get to MVP for V3 of the Cloud Foundry
API. You can follow along by visiting our documentation and tracker:

http://v3-apidocs.cloudfoundry.org/
https://www.pivotaltracker.com/n/projects/966314

We'd like to get some feedback from the community regarding
VCAP_APPLICATION, an environment variable provided to applications running
on Cloud Foundry. In V3, an application contains 1 or more processes that
can be scaled independently, so VCAP_APPLICATION doesn't quite fit.

Do you have any use cases around VCAP_APPLICATION that you could share?
Are there Cloud Foundry operators / users that would like to get rid of
this all together? Our current plan was to do something like below, but
wanted to hear from the community first.

"CF_APPLICATION_PROCESS": {
"space": {
"guid": "682e10a0-6f3a-4a9f-b52c-f508b2bd99c6",
"name": "ncalugar-a1"
},
"application": {
"guid": "<v3-app-guid>",
"name": "nickdora"
"version": "<app-version-guid>"
},
"process": {
"guid": "<v3-proc-guid>",
"type": "web",
"ports": [8080,8081]
},
"route_mappings": [
{
"guid": "<v3-route-mapping-guid>",
"uri": "nickdora.a1-app.cf-app.com",
"port": 8080
},
{
"guid": "<v3-route-mapping-guid>",
"uri": "nickdora.a1-app.cf-app.com/admin",
"port":"8081"
}
],
"limits": {
"fds": 16384,
"mem": 1024,
"disk": 4096
}
}


Thanks,

Nick


Re: VCAP_APPLICATION in the V3 Cloud Foundry API

Daniel Mikusa
 

I know some of the build packs will look at application name and use that
for configuration of some of the APM agents (NewRelic, AppDynamics, etc..).


Ex:
https://github.com/cloudfoundry/java-buildpack/blob/master/config/app_dynamics_agent.yml#L21

The PHP build pack does this too.

As long as that info is exposed somewhere, it would be OK.

Dan

On Mon, May 2, 2016 at 4:34 PM, john mcteague <john.mcteague(a)gmail.com>
wrote:

While I dont use this directly, my first reaction is some libraries such
as Spring Cloud Connectors depend on this to identify that an app is
running in CF, and we rely heavily on Spring Cloud Connectors.

That being said, assuming there are alternative variable that uniquely
identify CF, the library authors could key off that instead.

On Mon, May 2, 2016 at 9:28 PM, Nicholas Calugar <ncalugar(a)pivotal.io>
wrote:

Hi CF-Dev,

The CAPI team is working hard to get to MVP for V3 of the Cloud Foundry
API. You can follow along by visiting our documentation and tracker:

http://v3-apidocs.cloudfoundry.org/
https://www.pivotaltracker.com/n/projects/966314

We'd like to get some feedback from the community regarding
VCAP_APPLICATION, an environment variable provided to applications running
on Cloud Foundry. In V3, an application contains 1 or more processes that
can be scaled independently, so VCAP_APPLICATION doesn't quite fit.

Do you have any use cases around VCAP_APPLICATION that you could share?
Are there Cloud Foundry operators / users that would like to get rid of
this all together? Our current plan was to do something like below, but
wanted to hear from the community first.

"CF_APPLICATION_PROCESS": {
"space": {
"guid": "682e10a0-6f3a-4a9f-b52c-f508b2bd99c6",
"name": "ncalugar-a1"
},
"application": {
"guid": "<v3-app-guid>",
"name": "nickdora"
"version": "<app-version-guid>"
},
"process": {
"guid": "<v3-proc-guid>",
"type": "web",
"ports": [8080,8081]
},
"route_mappings": [
{
"guid": "<v3-route-mapping-guid>",
"uri": "nickdora.a1-app.cf-app.com",
"port": 8080
},
{
"guid": "<v3-route-mapping-guid>",
"uri": "nickdora.a1-app.cf-app.com/admin",
"port":"8081"
}
],
"limits": {
"fds": 16384,
"mem": 1024,
"disk": 4096
}
}


Thanks,

Nick


Re: VCAP_APPLICATION in the V3 Cloud Foundry API

john mcteague <john.mcteague@...>
 

While I dont use this directly, my first reaction is some libraries such as
Spring Cloud Connectors depend on this to identify that an app is running
in CF, and we rely heavily on Spring Cloud Connectors.

That being said, assuming there are alternative variable that uniquely
identify CF, the library authors could key off that instead.

On Mon, May 2, 2016 at 9:28 PM, Nicholas Calugar <ncalugar(a)pivotal.io>
wrote:

Hi CF-Dev,

The CAPI team is working hard to get to MVP for V3 of the Cloud Foundry
API. You can follow along by visiting our documentation and tracker:

http://v3-apidocs.cloudfoundry.org/
https://www.pivotaltracker.com/n/projects/966314

We'd like to get some feedback from the community regarding
VCAP_APPLICATION, an environment variable provided to applications running
on Cloud Foundry. In V3, an application contains 1 or more processes that
can be scaled independently, so VCAP_APPLICATION doesn't quite fit.

Do you have any use cases around VCAP_APPLICATION that you could share?
Are there Cloud Foundry operators / users that would like to get rid of
this all together? Our current plan was to do something like below, but
wanted to hear from the community first.

"CF_APPLICATION_PROCESS": {
"space": {
"guid": "682e10a0-6f3a-4a9f-b52c-f508b2bd99c6",
"name": "ncalugar-a1"
},
"application": {
"guid": "<v3-app-guid>",
"name": "nickdora"
"version": "<app-version-guid>"
},
"process": {
"guid": "<v3-proc-guid>",
"type": "web",
"ports": [8080,8081]
},
"route_mappings": [
{
"guid": "<v3-route-mapping-guid>",
"uri": "nickdora.a1-app.cf-app.com",
"port": 8080
},
{
"guid": "<v3-route-mapping-guid>",
"uri": "nickdora.a1-app.cf-app.com/admin",
"port":"8081"
}
],
"limits": {
"fds": 16384,
"mem": 1024,
"disk": 4096
}
}


Thanks,

Nick


VCAP_APPLICATION in the V3 Cloud Foundry API

Nicholas Calugar
 

Hi CF-Dev,

The CAPI team is working hard to get to MVP for V3 of the Cloud Foundry
API. You can follow along by visiting our documentation and tracker:

http://v3-apidocs.cloudfoundry.org/
https://www.pivotaltracker.com/n/projects/966314

We'd like to get some feedback from the community regarding
VCAP_APPLICATION, an environment variable provided to applications running
on Cloud Foundry. In V3, an application contains 1 or more processes that
can be scaled independently, so VCAP_APPLICATION doesn't quite fit.

Do you have any use cases around VCAP_APPLICATION that you could share? Are
there Cloud Foundry operators / users that would like to get rid of this
all together? Our current plan was to do something like below, but wanted
to hear from the community first.

"CF_APPLICATION_PROCESS": {
"space": {
"guid": "682e10a0-6f3a-4a9f-b52c-f508b2bd99c6",
"name": "ncalugar-a1"
},
"application": {
"guid": "<v3-app-guid>",
"name": "nickdora"
"version": "<app-version-guid>"
},
"process": {
"guid": "<v3-proc-guid>",
"type": "web",
"ports": [8080,8081]
},
"route_mappings": [
{
"guid": "<v3-route-mapping-guid>",
"uri": "nickdora.a1-app.cf-app.com",
"port": 8080
},
{
"guid": "<v3-route-mapping-guid>",
"uri": "nickdora.a1-app.cf-app.com/admin",
"port":"8081"
}
],
"limits": {
"fds": 16384,
"mem": 1024,
"disk": 4096
}
}


Thanks,

Nick


Re: HTTP request status text is changed

CF Runtime
 

Hi Stanley,

We can reproduce your issue when we push your .war file to a CF running on bosh-lite. We actually also see this same behavior when we run the .war file on a local Tomcat with default configuration . So, we believe the issue is due to tomcat configuration - your local tomcat probably has different configuration than the one provided by the buildpack, and what we see on an out-of-the-box tomcat installation.

You can see the java buildpack's tomcat configuration here: https://github.com/cloudfoundry/java-buildpack/blob/master/resources/tomcat/conf/server.xml

The behavior you're requesting is unusual, so the java buildpack does not support it (it is nothing to do with dea/diego) so you have a few options. If you really need this behavior, you have a few options:
- fork the buildpack and change server.xml to your needs
- use spring boot which allows you to fully configure the servlet container

Thanks,
Rob Dimsdale & David Sabeti
CF Release Integration
Pivotal


PHP Buildpack: Now with persistent session support

Danny Rosen
 

Hi there!

We wanted to let you know of a significant feature addition to the PHP
buildpack. Thanks to Daniel Mikusa and the Buildpacks team the PHP
Buildpack now has support for persistent sessions in both Redis and
Memcached.

Check out the documentation here
<https://github.com/cloudfoundry/php-buildpack/blob/develop/docs/sessions.md>
and give it a spin.


Re: HTTP request status text is changed

Stanley Shen <meteorping@...>
 

hello, I tried with latest cf/diego release.
I still can reproduce the issue.
I am using all things provided by CF without any customization.
I just push my servlet APP and access it from command line.(You can find it in a previous reply in this thread)

wget http://test.[APP domain]/test
--2016-05-02 03:28:15-- http://test.[APP domain]/test
Resolving test.[APP domain] (test.[APP domain])... 152.190.109.xx
Connecting to test.[APP domain] (test.[APP domain])|152.190.109.xx|:80... connected.
HTTP request sent, awaiting response... 414 Request URI Too Long
2016-05-02 03:28:15 ERROR 414: Request URI Too Long.

Here the error message is "Request URI Too Long", which is the standard one, but my customized message "my customized 414 error message".


+---------------------------------------------+---------------+---------+--------------------------------------+
| Name | OS | Version | CID |
+---------------------------------------------+---------------+---------+--------------------------------------+
| bosh-warden-boshlite-ubuntu-trusty-go_agent | ubuntu-trusty | 3147* | 0636a704-8ac9-44a8-7f21-793f17310298 |
+---------------------------------------------+---------------+---------+--------------------------------------+

+-------------------+-----------------+-------------+
| Name | Versions | Commit Hash |
+-------------------+-----------------+-------------+
| cf | 236+dev.1* | 9a550e9d+ |
| diego | 0.1468.0+dev.1* | a54eeaf4+ |
| docker | 26* | 7fabb47c+ |
| etcd | 45* | 96dab618+ |
| garden-linux | 0.337.0* | a7d9ddac |
+-------------------+-----------------+-------------+

buildpack position enabled locked filename
staticfile_buildpack 1 true false staticfile_buildpack-cached-v1.3.6.zip
java_buildpack 2 true false java-buildpack-v3.7.zip
ruby_buildpack 3 true false ruby_buildpack-cached-v1.6.16.zip
nodejs_buildpack 4 true false nodejs_buildpack-cached-v1.5.12.zip
go_buildpack 5 true false go_buildpack-cached-v1.7.5.zip
python_buildpack 6 true false python_buildpack-cached-v1.5.5.zip
php_buildpack 7 true false php_buildpack-cached-v4.3.10.zip
binary_buildpack 8 true false binary_buildpack-cached-v1.0.1.zip
admin_console_buildpack 9 true false admin_console_buildpack-cached-v1.6.12.zip


Interests in mod_security support ?

Guillaume Berche
 

Hi,

Mod_security [1] is a flexible opensource web application firewall, which
runs configureable rules to detect and possible filter malicious incoming
HTTP requests received (XSS, SQL injection ....). Orange is preparing a PR
to add support for mod_security in the php_buildpack [2].

I'd be interested to hear if there is interest for such support in the
community and specific requirements/refinements over Orange's initial work
to be done.

Thanks in advance,

Guillaume.

ps: A possible future integration could also be packaged as a
fully-brokered route service in the future, which could be applying to all
buildpacks. As a 1st step, we focussed our effort to httpd within php
buildpack, mainly to avoid the added network hops implied by the
fully-brokered service

[1] https://www.modsecurity.org
[2] https://github.com/cloudfoundry/php-buildpack/issues/144


Re: What does status code 255 mean?

Daniel Mikusa
 

If possible add more logging or increase logging levels. Not sure what
language / runtime you're using, but you might be able to add an exit hook
or some code that is guaranteed to run before your app exits and use that
to dump more info.

If CF were shutting down your app for some reason, you would see a SIGTERM
sent followed by a SIGKILL roughly 10 seconds later (if your app doesn't
gracefully exit first). I don't think that's what is happening here, but
you could catch the SIGTERM and log a message to check. CF would really
only do this if the cell that your app is running on were being shut off
(like during an upgrade). Then it would restart your app automatically on
another cell.

The other case could be that you're exceeding your MEMORY_LIMIT. I don't
think that's happening as I believe Diego logs something that specifically
says when you run out of memory (like `Exited with status 255 (out of
memory)`).

Dan

On Mon, May 2, 2016 at 10:03 AM, Sam Dai <sam.dai(a)servicemax.com> wrote:

No, I didn't see error or related messages in the logs prior to the
application existing. I also executed the command "bosh logs cell_z1 0" to
get the log of cell_z1 0, but didn't find any useful information from the
log.


Re: What does status code 255 mean?

Sam Dai
 

No, I didn't see error or related messages in the logs prior to the application existing. I also executed the command "bosh logs cell_z1 0" to get the log of cell_z1 0, but didn't find any useful information from the log.


Re: My nodejs application can't work if the version nodejs buildpack >= v1.5.9

Daniel Mikusa
 

This isn't really a problem with the build pack. It's a problem with
compiling one of the native modules that you are using `
dtrace-provider(a)0.2.8`. Not sure why that's failing. There's some info in
the output from NPM below, which might help to someone more familiar with
that module.

From a CF perspective you could confirm it's the problem if you remove that
package from your application and push again.

Dan

On Sat, Apr 30, 2016 at 9:45 PM, Sam Dai <sam.dai(a)servicemax.com> wrote:

Hello,
I have a nodejs application, it can be deployed and started in CF if the
version nodejs buildpack <v 1.5.9, the version of node and npm in
package.json of my nodejs application is as below:

, "engines" : {
"node" : "~0.12.7",
"npm" : "~2.11.3"
}

When I deployed my nodejs application to nodejs v1.5.9, there is the
following error, do I need change something?

Downloading nodejs_buildpack...

Downloaded nodejs_buildpack (60.7M)

Creating container

Successfully created container

Downloading app package...

Downloaded app package (4.8M)

Staging...

-------> Buildpack version 1.5.11

-----> Creating runtime environment



NPM_CONFIG_LOGLEVEL=error

NPM_CONFIG_PRODUCTION=true

NODE_ENV=production

NODE_MODULES_CACHE=true

-----> Installing binaries

engines.node (package.json): ~0.12.7

engines.npm (package.json): ~2.11.3



Downloading and installing node 0.12.13...

Downloaded
[file:///tmp/buildpacks/d9e57be809c47eef0c67cf7e2b84bbbe/dependencies/https___pivotal-buildpacks.s3.amazonaws.com_concourse-binaries_node_node-0.12.13-linux-x64.tgz]

Resolving npm version ~2.11.3 via semver.io...

Downloading and installing npm 2.11.3 (replacing version 2.15.0)...

-----> Restoring cache

Skipping cache restore (new runtime signature)

-----> Building dependencies

Prebuild detected (node_modules already exists)

Rebuilding any native modules



> bson(a)0.2.2 install
/tmp/app/node_modules/mongoskin/node_modules/mongodb/node_modules/bson

> (node-gyp rebuild 2> builderror.log) || (exit 0)





> kerberos(a)0.0.3 install
/tmp/app/node_modules/mongoskin/node_modules/mongodb/node_modules/kerberos

> (node-gyp rebuild 2> builderror.log) || (exit 0)





> dtrace-provider(a)0.2.8 install
/tmp/app/node_modules/ldapjs/node_modules/dtrace-provider

> node-gyp rebuild



gyp: /tmp/app/.heroku/node/common.gypi not found (cwd:
/tmp/app/node_modules/ldapjs/node_modules/dtrace-provider) while reading
includes of binding.gyp while trying to load binding.gyp

gyp ERR! configure error

gyp ERR! stack Error: `gyp` failed with exit code: 1

gyp ERR! stack at ChildProcess.onCpExit
(/tmp/app/.heroku/node/lib/node_modules/npm/node_modules/node-gyp/lib/configure.js:355:16)

gyp ERR! stack at ChildProcess.emit (events.js:110:17)

gyp ERR! stack at Process.ChildProcess._handle.onexit
(child_process.js:1078:12)

gyp ERR! System Linux 3.19.0-28-generic

gyp ERR! command "node"
"/tmp/app/.heroku/node/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js"
"rebuild"

gyp ERR! cwd
/tmp/app/node_modules/ldapjs/node_modules/dtrace-provider

gyp ERR! node -v v0.12.13

gyp ERR! node-gyp -v v2.0.1

gyp ERR! not ok



npm ERR! Linux 3.19.0-28-generic

npm ERR! argv "node" "/tmp/app/.heroku/node/bin/npm" "rebuild"
"--nodedir=/tmp/app/.heroku/node"

npm ERR! node v0.12.13

npm ERR! npm v2.11.3

npm ERR! code ELIFECYCLE

npm ERR! dtrace-provider(a)0.2.8 install: `node-gyp rebuild`

npm ERR! Exit status 1

npm ERR!

npm ERR! Failed at the dtrace-provider(a)0.2.8 install script
'node-gyp rebuild'.

npm ERR! This is most likely a problem with the dtrace-provider
package,

npm ERR! not with npm itself.

npm ERR! Tell the author that this fails on your system:

npm ERR! node-gyp rebuild

npm ERR! You can get their info via:

npm ERR! npm owner ls dtrace-provider

npm ERR! There is likely additional logging output above.



npm ERR! Please include the following file with any support request:

npm ERR! /tmp/app/npm-debug.log

-----> Build failed



We're sorry this build is failing! You can troubleshoot common
issues here:

https://devcenter.heroku.com/articles/troubleshooting-node-deploys



Some possible problems:



- node_modules checked into source control


https://docs.npmjs.com/misc/faq#should-i-check-my-node-modules-folder-into-git



Love,

Heroku


Re: What does status code 255 mean?

Daniel Mikusa
 

It is the exit status of your application. In other words, your app exited
and returned this number.

http://tldp.org/LDP/abs/html/exit-status.html

It may be an application specific number or it could be one of the exit
codes with a special meaning.

http://tldp.org/LDP/abs/html/exitcodes.html

In this case, it's 255 which is kind of a generic number. Do you see
anything in the logs prior to the application exiting? If not, try turning
up the logging in your application to see if you can figure out what it is
doing prior to exiting.

Dan

On Mon, May 2, 2016 at 4:33 AM, Sam Dai <sam.dai(a)servicemax.com> wrote:

Hello,
I deployed an application to Diego, found this application often got
restarted, there is no error message in the log, just found the following
message, what does the status code 255 mean?

*2016-05-02T14:15:00.06+0800 [CELL/0]* OUT Exit status 255

*2016-05-02T14:15:00.06+0800 [APP/0]* OUT Exit status 255

*2016-05-02T14:15:00.17+0800 [CELL/0]* OUT Creating container

*2016-05-02T14:15:00.66+0800 [CELL/0]* OUT Successfully created
container
*2016-05-02T14:15:43.61+0800 [CELL/0]* OUT Starting health monitoring
of container


CF release version: v235
Diego version: v0.1467.0

Thanks,
Sam


Re: What does status code 255 mean?

Sam Dai
 

Sorry, the version of CF and Diego in previous mail is incorrect, CF release version is v233, Diego version is V 0.1460.0


What does status code 255 mean?

Sam Dai
 

Hello,
I deployed an application to Diego, found this application often got
restarted, there is no error message in the log, just found the following
message, what does the status code 255 mean?

*2016-05-02T14:15:00.06+0800 [CELL/0]* OUT Exit status 255

*2016-05-02T14:15:00.06+0800 [APP/0]* OUT Exit status 255

*2016-05-02T14:15:00.17+0800 [CELL/0]* OUT Creating container

*2016-05-02T14:15:00.66+0800 [CELL/0]* OUT Successfully created
container
*2016-05-02T14:15:43.61+0800 [CELL/0]* OUT Starting health monitoring
of container


CF release version: v235
Diego version: v0.1467.0

Thanks,
Sam


Re: `router_z1/0' is not running after update

Sam Dai
 

This issue has been resolved in https://github.com/cloudfoundry-incubator/cf-routing-release/issues/28, the root cause of this issue is that cf cli caches RoutingEndpoint in ~/cf/config.json so do a cf login again

cf login

will fix this issue.


My nodejs application can't work if the version nodejs buildpack >= v1.5.9

Sam Dai
 

Hello,
I have a nodejs application, it can be deployed and started in CF if the
version nodejs buildpack <v 1.5.9, the version of node and npm in
package.json of my nodejs application is as below:

, "engines" : {
"node" : "~0.12.7",
"npm" : "~2.11.3"
}

When I deployed my nodejs application to nodejs v1.5.9, there is the
following error, do I need change something?

Downloading nodejs_buildpack...

Downloaded nodejs_buildpack (60.7M)

Creating container

Successfully created container

Downloading app package...

Downloaded app package (4.8M)

Staging...

-------> Buildpack version 1.5.11

-----> Creating runtime environment



NPM_CONFIG_LOGLEVEL=error

NPM_CONFIG_PRODUCTION=true

NODE_ENV=production

NODE_MODULES_CACHE=true

-----> Installing binaries

engines.node (package.json): ~0.12.7

engines.npm (package.json): ~2.11.3



Downloading and installing node 0.12.13...

Downloaded
[file:///tmp/buildpacks/d9e57be809c47eef0c67cf7e2b84bbbe/dependencies/https___pivotal-buildpacks.s3.amazonaws.com_concourse-binaries_node_node-0.12.13-linux-x64.tgz]

Resolving npm version ~2.11.3 via semver.io...

Downloading and installing npm 2.11.3 (replacing version 2.15.0)...

-----> Restoring cache

Skipping cache restore (new runtime signature)

-----> Building dependencies

Prebuild detected (node_modules already exists)

Rebuilding any native modules



> bson(a)0.2.2 install
/tmp/app/node_modules/mongoskin/node_modules/mongodb/node_modules/bson

> (node-gyp rebuild 2> builderror.log) || (exit 0)





> kerberos(a)0.0.3 install
/tmp/app/node_modules/mongoskin/node_modules/mongodb/node_modules/kerberos

> (node-gyp rebuild 2> builderror.log) || (exit 0)





> dtrace-provider(a)0.2.8 install
/tmp/app/node_modules/ldapjs/node_modules/dtrace-provider

> node-gyp rebuild



gyp: /tmp/app/.heroku/node/common.gypi not found (cwd:
/tmp/app/node_modules/ldapjs/node_modules/dtrace-provider) while reading
includes of binding.gyp while trying to load binding.gyp

gyp ERR! configure error

gyp ERR! stack Error: `gyp` failed with exit code: 1

gyp ERR! stack at ChildProcess.onCpExit
(/tmp/app/.heroku/node/lib/node_modules/npm/node_modules/node-gyp/lib/configure.js:355:16)

gyp ERR! stack at ChildProcess.emit (events.js:110:17)

gyp ERR! stack at Process.ChildProcess._handle.onexit
(child_process.js:1078:12)

gyp ERR! System Linux 3.19.0-28-generic

gyp ERR! command "node"
"/tmp/app/.heroku/node/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js"
"rebuild"

gyp ERR! cwd
/tmp/app/node_modules/ldapjs/node_modules/dtrace-provider

gyp ERR! node -v v0.12.13

gyp ERR! node-gyp -v v2.0.1

gyp ERR! not ok



npm ERR! Linux 3.19.0-28-generic

npm ERR! argv "node" "/tmp/app/.heroku/node/bin/npm" "rebuild"
"--nodedir=/tmp/app/.heroku/node"

npm ERR! node v0.12.13

npm ERR! npm v2.11.3

npm ERR! code ELIFECYCLE

npm ERR! dtrace-provider(a)0.2.8 install: `node-gyp rebuild`

npm ERR! Exit status 1

npm ERR!

npm ERR! Failed at the dtrace-provider(a)0.2.8 install script
'node-gyp rebuild'.

npm ERR! This is most likely a problem with the dtrace-provider
package,

npm ERR! not with npm itself.

npm ERR! Tell the author that this fails on your system:

npm ERR! node-gyp rebuild

npm ERR! You can get their info via:

npm ERR! npm owner ls dtrace-provider

npm ERR! There is likely additional logging output above.



npm ERR! Please include the following file with any support request:

npm ERR! /tmp/app/npm-debug.log

-----> Build failed



We're sorry this build is failing! You can troubleshoot common
issues here:

https://devcenter.heroku.com/articles/troubleshooting-node-deploys



Some possible problems:



- node_modules checked into source control


https://docs.npmjs.com/misc/faq#should-i-check-my-node-modules-folder-into-git



Love,

Heroku


Re: Brokered route services only receiving traffic for routes mapped to started apps

Stefan Mayr
 

Hi

Am 28.04.2016 um 23:08 schrieb Mike Youngstrom:
Here is another minor use case. My users are often confused that a
stopped app returns a 404 instead of a 503. So, we implement that
functionality for the user using an app mapped to wildcard routes that
constantly asks the CC for valid routes. This works for wildcard
domains but not one off domains.

It might be better if the router returned a 503. At least for routes
bound to apps. Not sure if this should extend to routes not bound to apps.
+1 for that proposal. A 404 also causes issues when crawler remove pages
from their index. A 503 has less side effects. I would also prefer a 503
service unavailable when a route is not bound - because there is no
service for this route. IMHO the meaning is much closer to what has
happended.

Stefan

Mike

On Thu, Apr 28, 2016 at 1:32 PM, Shannon Coen <scoen(a)pivotal.io
<mailto:scoen(a)pivotal.io>> wrote:

Hello Guillaume,

Thank you for sharing your thoughts on these use cases. I can see
how having
a route service field requests for an app, whether the app is up on not,
could be useful.

However, enabling this would significantly change how routes are
registered
for apps on Cloud Foundry, and how the router handles the route lookup.
Routes are not currently enabled in the routing tier unless they are
mapped
to an app, and only when the app is determined healthy.

You are proposing the router maintains routes which have no
backends, and
instead of a failed lookup determining whether a 404 is returned,
the router
should figure out whether a route has any backends or a route service.

I'll chew on your use case and keep my ear out for additional use
cases for
maintaining routes with no backends in the routing table.

Best,
Shannon



--
View this message in context:
http://cf-dev.70369.x6.nabble.com/cf-dev-Brokered-route-services-only-receiving-traffic-for-routes-mapped-to-started-apps-tp4699p4742.html
Sent from the CF Dev mailing list archive at Nabble.com.


Change in 'haproxy' manifest property

Shannon Coen
 

Hi all,

Giving everyone heads up about changes in manifest property for 'haproxy'
job. We are merging what are now two separate properties for configuration
of the router static ips into a single property that takes a list of IPs.

Who should care: if you have configured the router ips using properties in
the haproxy job, you will need to update your stubs to use the new property.

When is this change happening: This change is likely to be present in
cf-release v237.

Old properties were 'haproxy.router.servers.{z1,z2}'
```
properties:
haproxy:

router:

servers:

z1:

- ROUTER_Z1_IP

z2:
- ROUTER_Z2_IP
```

New property is 'haproxy.router.servers'
```
properties:
haproxy:

router:

servers:

- ROUTER_Z1_IP

- ROUTER_Z2_IP
```



Thank you,
Shash && Shannon
CF Routing Team


Re: Some in-depth info on how to use CF

Marco Ristuccia
 

Hi Eric,

forget my preceding messages. I had to add and bind the security groups. Now it seems to work.

What if I have a username/password protected registry? (https, self signed certs)
Where do I have to put the account information when I make a "cf push -o"?

Thank you again.

Regards,
Marco


Re: HTTP request status text is changed

Alvaro Perez-Shirley
 

Hi Stanley,

We attempted to reproduce this behavior on bosh-lite and were unable to, which leads me to believe the issue might be in some middleware. Are you using the provided java buildpack or a custom buildpack? Are you running tomcat, and if so how is it configured?

You could try updating to the latest version of cf-release to see if that makes any difference, as that is the one we tested with.

Hope this helps,
Alvaro

4661 - 4680 of 9426