Date   

Re: App failed to startup or crashed

Jason Huang
 

Sorry my previous email was not meant for the group. It was for Phong only.
:-). But since I am on it, let me gave more details on what we have seen
before. What we encountered before was that the upgrade of our own
applications in CF took very long time due to insufficient entropy in the
client vm where our upgrade tool was run. We later installed Haveged
package in the client VM to solve the problem.

Jason



On Tue, Dec 13, 2016 at 7:49 AM, Jason Huang <jasonxs.huang(a)gmail.com>
wrote:

I see a reply saying that it is likely because there is not enough
entropy. We had the problem before.

Likely the problem is not enough entropy in /dev/random. You can try to
use /dev/urandom instead to check if that helps: https://github.com/
cloudfoundry/java-buildpack/blob/master/docs/container-tomcat.md (at the
bottom of the page).


Sent from my iPhone

On Dec 13, 2016, at 4:35 AM, Michal Kuratczyk <mkuratczyk(a)pivotal.io>
wrote:

Hi Phong,

Likely the problem is not enough entropy in /dev/random. You can try to
use /dev/urandom instead to check if that helps: https://github.com/
cloudfoundry/java-buildpack/blob/master/docs/container-tomcat.md (at the
bottom of the page).

Best regards,

On Tue, Dec 13, 2016 at 3:41 AM, Phong Tran <phong.tran(a)emc.com> wrote:

Recently we just just consolidated several Cloud Foundry (CF) instances
into one shared CF instance for resource sharing and we are now
occasionally running into a problem with starting up applications .
Basically when trying to start an application, we noticed one DEA is
selected to run the app, but app failed to startup, so another DEA is
selected. This DEA selection process would continue until the app is
successfully started up on the seelcted DEA or app startup is timed out.

Starting app spring-music in org CI / space ngisspace as admin...

0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 down
0 of 1 instances running, 1 down
0 of 1 instances running, 1 down
0 of 1 instances running, 1 down
0 of 1 instances running, 1 down
0 of 1 instances running, 1 down
0 of 1 instances running, 1 down
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
1 of 1 instances running
App started
OK

cf logs spring-music
...
2016-12-12T15:06:50.54-0800 [DEA/10] OUT Starting app instance (index
0) with guid ccc3299d-758e-42a3-9210-8c8264d6d9a7
2016-12-12T15:08:43.91-0800 [DEA/8] OUT Starting app instance (index
0) with guid ccc3299d-758e-42a3-9210-8c8264d6d9a7
2016-12-12T15:09:24.68-0800 [App/0] OUT
2016-12-12T15:09:24.68-0800 [App/0] OUT . ____ _
__ _ _
2016-12-12T15:09:24.68-0800 [App/0] OUT /\\ / ___'_ __ _ _(_)_ __
__ _ \ \ \ \
2016-12-12T15:09:24.68-0800 [App/0] OUT ( ( )\___ | '_ | '_| | '_ \/
_` | \ \ \ \
2016-12-12T15:09:24.68-0800 [App/0] OUT \\/ ___)| |_)| | | | | ||
(_| | ) ) ) )
2016-12-12T15:09:24.68-0800 [App/0] OUT ' |____| .__|_| |_|_|
|_\__, | / / / /
2016-12-12T15:09:24.68-0800 [App/0] OUT
=========|_|==============|___/=/_/_/_/
2016-12-12T15:09:24.68-0800 [App/0] OUT :: Spring Boot ::
(v1.3.5.RELEASE)
2016-12-12T15:09:24.83-0800 [App/0] OUT 2016-12-12 23:09:24.833
INFO 29 --- [ main] pertySourceApplicationContextInitializer :
Adding 'cloud' PropertySource to ApplicationContext
2016-12-12T15:09:24.90-0800 [App/0] OUT 2016-12-12 23:09:24.908
INFO 29 --- [ main] nfigurationApplicationContextInitializer :
Adding cloud service auto-reconfiguration to ApplicationContext
2016-12-12T15:09:25.19-0800 [App/0] OUT 2016-12-12 23:09:25.197
INFO 29 --- [ main] .m.c.SpringApplicationContextInitializer :
Found serviceInfos:
2016-12-12T15:09:25.20-0800 [App/0] OUT 2016-12-12 23:09:25.202
INFO 29 --- [ main] o.c.samples.music.Application :
Starting Application on 1a37tgli287 with PID 29 (/home/vcap/app started by
vcap in /home/vcap/app)

...

Initially we though it could be related to the disk/memory constraint on
DEAs, so we have increased more capacity, so no help here. We thought the
problem be be related to our applications, so we tried to use the Spring
Music sample app (https://github.com/cloudfoundry-samples/spring-music)
and we still have the same startup problem (app crash) as indicated above.

When looked at the dea_next.log, we could not find any obviously wrong
according to our knowledge, however obvious errors except these errors:

"error":"Container state must be one of 'active', current state is
'stopped'","backtrace":["/var/vcap/packages/dea_next/vendor/
cache/warden-b72b8c5a532d/em-warden-client/lib/em/warden/client/connection.rb:25:in
`get'","/var/vcap/packages/dea_next/vendor/cache/warden-b72b
8c5a532d/em-warden-client/lib/em/warden/client.rb:46:in
`call'","/var/vcap/packages/dea_next/lib/container/container.rb:193:in
`call'","/var/vcap/packages/dea_next/lib/container/container.rb:133:in
`block in setup_egress_rules'","/var/vcap/packages/dea_next/lib/container/container.rb:132:in
`each'","/var/vcap/packages/dea_next/lib/container/container.rb:132:in
`setup_egress_rules'","/var/vcap/packages/dea_next/lib/container/container.rb:126:in
`block in create_container'","/var/vcap/packages/dea_next/lib/container/container.rb:235:in
`call'","/var/vcap/packages/dea_next/lib/container/container.rb:235:in
`with_em'","/var/vcap/packages/dea_next/lib/container/container.rb:119:in
`create_container'","/var/vcap/pac
kages/de
a_next/lib/dea/starting/instance.rb:552:in `block in
promise_container'","/var/vcap/packages/dea_next/lib/dea/promise.rb:92:in
`call'","/var/vcap/packages/dea_next/lib/dea/promise.rb:92:in `block in
run'"]},"thread_id":46964431542680,"fiber_id":46964755305680
,"process_id":5695,"file":"/var/vcap/packages/dea_next/
lib/dea/task.rb","lineno":105,"method":"block in resolve_and_log"}

It looked like DEA failed to create a container for the app when setting
up egress rules for the container (race/deadlock?), but I could be wrong
here. The dea_next.log is avaialable in the following pastebin URI.

dea_next.log: http://pastebin.com/PBm1RFtq

We're using Cloud Foundry Release #237.

Please let me me know you if you need further information for
troubleshooting the problem.

Thanks in advance for your help.

Thanks,
Phong


--
Michal Kuratczyk


Re: How to create user provided service step by step

DHR
 

A user-provided service in CF is simply a pointer, with credentials, to some infrastructure that is itself managed outside of CF.

This pointer can be created using the "CF cups" command. If you're having trouble running it, you could run "cf cups --help" which prints the required command arguments.

Or of this still does not make sense, Perhaps you could describe your use case & we will try to help that way

On 13 Dec 2016, at 16:09, john J <johnjerrby(a)yahoo.com> wrote:

Btw this guide is too abstract and doesnt help much....
https://docs.cloudfoundry.org/devguide/services/user-provided.html


Re: How to create user provided service step by step

john J
 

Btw this guide is too abstract and doesnt help much....
https://docs.cloudfoundry.org/devguide/services/user-provided.html


How to create user provided service step by step

john J
 

HI,

I need some guide how to create user provided service step by step, there is someting like this?

Thanks
John


Re: App failed to startup or crashed

Jason Huang
 

I see a reply saying that it is likely because there is not enough entropy. We had the problem before.

Likely the problem is not enough entropy in /dev/random. You can try to use /dev/urandom instead to check if that helps: https://github.com/cloudfoundry/java-buildpack/blob/master/docs/container-tomcat.md (at the bottom of the page).


Sent from my iPhone

On Dec 13, 2016, at 4:35 AM, Michal Kuratczyk <mkuratczyk(a)pivotal.io> wrote:

Hi Phong,

Likely the problem is not enough entropy in /dev/random. You can try to use /dev/urandom instead to check if that helps: https://github.com/cloudfoundry/java-buildpack/blob/master/docs/container-tomcat.md (at the bottom of the page).

Best regards,

On Tue, Dec 13, 2016 at 3:41 AM, Phong Tran <phong.tran(a)emc.com> wrote:
Recently we just just consolidated several Cloud Foundry (CF) instances into one shared CF instance for resource sharing and we are now occasionally running into a problem with starting up applications . Basically when trying to start an application, we noticed one DEA is selected to run the app, but app failed to startup, so another DEA is selected. This DEA selection process would continue until the app is successfully started up on the seelcted DEA or app startup is timed out.

Starting app spring-music in org CI / space ngisspace as admin...

0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 down
0 of 1 instances running, 1 down
0 of 1 instances running, 1 down
0 of 1 instances running, 1 down
0 of 1 instances running, 1 down
0 of 1 instances running, 1 down
0 of 1 instances running, 1 down
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
1 of 1 instances running
App started
OK

cf logs spring-music
...
2016-12-12T15:06:50.54-0800 [DEA/10] OUT Starting app instance (index 0) with guid ccc3299d-758e-42a3-9210-8c8264d6d9a7
2016-12-12T15:08:43.91-0800 [DEA/8] OUT Starting app instance (index 0) with guid ccc3299d-758e-42a3-9210-8c8264d6d9a7
2016-12-12T15:09:24.68-0800 [App/0] OUT
2016-12-12T15:09:24.68-0800 [App/0] OUT . ____ _ __ _ _
2016-12-12T15:09:24.68-0800 [App/0] OUT /\\ / ___'_ __ _ _(_)_ __ __ _ \ \ \ \
2016-12-12T15:09:24.68-0800 [App/0] OUT ( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
2016-12-12T15:09:24.68-0800 [App/0] OUT \\/ ___)| |_)| | | | | || (_| | ) ) ) )
2016-12-12T15:09:24.68-0800 [App/0] OUT ' |____| .__|_| |_|_| |_\__, | / / / /
2016-12-12T15:09:24.68-0800 [App/0] OUT =========|_|==============|___/=/_/_/_/
2016-12-12T15:09:24.68-0800 [App/0] OUT :: Spring Boot :: (v1.3.5.RELEASE)
2016-12-12T15:09:24.83-0800 [App/0] OUT 2016-12-12 23:09:24.833 INFO 29 --- [ main] pertySourceApplicationContextInitializer : Adding 'cloud' PropertySource to ApplicationContext
2016-12-12T15:09:24.90-0800 [App/0] OUT 2016-12-12 23:09:24.908 INFO 29 --- [ main] nfigurationApplicationContextInitializer : Adding cloud service auto-reconfiguration to ApplicationContext
2016-12-12T15:09:25.19-0800 [App/0] OUT 2016-12-12 23:09:25.197 INFO 29 --- [ main] .m.c.SpringApplicationContextInitializer : Found serviceInfos:
2016-12-12T15:09:25.20-0800 [App/0] OUT 2016-12-12 23:09:25.202 INFO 29 --- [ main] o.c.samples.music.Application : Starting Application on 1a37tgli287 with PID 29 (/home/vcap/app started by vcap in /home/vcap/app)

...

Initially we though it could be related to the disk/memory constraint on DEAs, so we have increased more capacity, so no help here. We thought the problem be be related to our applications, so we tried to use the Spring Music sample app (https://github.com/cloudfoundry-samples/spring-music) and we still have the same startup problem (app crash) as indicated above.

When looked at the dea_next.log, we could not find any obviously wrong according to our knowledge, however obvious errors except these errors:

"error":"Container state must be one of 'active', current state is 'stopped'","backtrace":["/var/vcap/packages/dea_next/vendor/cache/warden-b72b8c5a532d/em-warden-client/lib/em/warden/client/connection.rb:25:in `get'","/var/vcap/packages/dea_next/vendor/cache/warden-b72b8c5a532d/em-warden-client/lib/em/warden/client.rb:46:in `call'","/var/vcap/packages/dea_next/lib/container/container.rb:193:in `call'","/var/vcap/packages/dea_next/lib/container/container.rb:133:in `block in setup_egress_rules'","/var/vcap/packages/dea_next/lib/container/container.rb:132:in `each'","/var/vcap/packages/dea_next/lib/container/container.rb:132:in `setup_egress_rules'","/var/vcap/packages/dea_next/lib/container/container.rb:126:in `block in create_container'","/var/vcap/packages/dea_next/lib/container/container.rb:235:in `call'","/var/vcap/packages/dea_next/lib/container/container.rb:235:in `with_em'","/var/vcap/packages/dea_next/lib/container/container.rb:119:in `create_container'","/var/vcap/pac
kages/de
a_next/lib/dea/starting/instance.rb:552:in `block in promise_container'","/var/vcap/packages/dea_next/lib/dea/promise.rb:92:in `call'","/var/vcap/packages/dea_next/lib/dea/promise.rb:92:in `block in run'"]},"thread_id":46964431542680,"fiber_id":46964755305680,"process_id":5695,"file":"/var/vcap/packages/dea_next/lib/dea/task.rb","lineno":105,"method":"block in resolve_and_log"}

It looked like DEA failed to create a container for the app when setting up egress rules for the container (race/deadlock?), but I could be wrong here. The dea_next.log is avaialable in the following pastebin URI.

dea_next.log: http://pastebin.com/PBm1RFtq

We're using Cloud Foundry Release #237.

Please let me me know you if you need further information for troubleshooting the problem.

Thanks in advance for your help.

Thanks,
Phong


--
Michal Kuratczyk


Re: App failed to startup or crashed

Michal Kuratczyk
 

Hi Phong,

Likely the problem is not enough entropy in /dev/random. You can try to use
/dev/urandom instead to check if that helps:
https://github.com/cloudfoundry/java-buildpack/blob/master/docs/container-tomcat.md
(at the bottom of the page).

Best regards,

On Tue, Dec 13, 2016 at 3:41 AM, Phong Tran <phong.tran(a)emc.com> wrote:

Recently we just just consolidated several Cloud Foundry (CF) instances
into one shared CF instance for resource sharing and we are now
occasionally running into a problem with starting up applications .
Basically when trying to start an application, we noticed one DEA is
selected to run the app, but app failed to startup, so another DEA is
selected. This DEA selection process would continue until the app is
successfully started up on the seelcted DEA or app startup is timed out.

Starting app spring-music in org CI / space ngisspace as admin...

0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 down
0 of 1 instances running, 1 down
0 of 1 instances running, 1 down
0 of 1 instances running, 1 down
0 of 1 instances running, 1 down
0 of 1 instances running, 1 down
0 of 1 instances running, 1 down
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
1 of 1 instances running
App started
OK

cf logs spring-music
...
2016-12-12T15:06:50.54-0800 [DEA/10] OUT Starting app instance (index
0) with guid ccc3299d-758e-42a3-9210-8c8264d6d9a7
2016-12-12T15:08:43.91-0800 [DEA/8] OUT Starting app instance (index
0) with guid ccc3299d-758e-42a3-9210-8c8264d6d9a7
2016-12-12T15:09:24.68-0800 [App/0] OUT
2016-12-12T15:09:24.68-0800 [App/0] OUT . ____ _
__ _ _
2016-12-12T15:09:24.68-0800 [App/0] OUT /\\ / ___'_ __ _ _(_)_ __
__ _ \ \ \ \
2016-12-12T15:09:24.68-0800 [App/0] OUT ( ( )\___ | '_ | '_| | '_ \/
_` | \ \ \ \
2016-12-12T15:09:24.68-0800 [App/0] OUT \\/ ___)| |_)| | | | | ||
(_| | ) ) ) )
2016-12-12T15:09:24.68-0800 [App/0] OUT ' |____| .__|_| |_|_|
|_\__, | / / / /
2016-12-12T15:09:24.68-0800 [App/0] OUT
=========|_|==============|___/=/_/_/_/
2016-12-12T15:09:24.68-0800 [App/0] OUT :: Spring Boot ::
(v1.3.5.RELEASE)
2016-12-12T15:09:24.83-0800 [App/0] OUT 2016-12-12 23:09:24.833 INFO
29 --- [ main] pertySourceApplicationContextInitializer :
Adding 'cloud' PropertySource to ApplicationContext
2016-12-12T15:09:24.90-0800 [App/0] OUT 2016-12-12 23:09:24.908 INFO
29 --- [ main] nfigurationApplicationContextInitializer :
Adding cloud service auto-reconfiguration to ApplicationContext
2016-12-12T15:09:25.19-0800 [App/0] OUT 2016-12-12 23:09:25.197 INFO
29 --- [ main] .m.c.SpringApplicationContextInitializer : Found
serviceInfos:
2016-12-12T15:09:25.20-0800 [App/0] OUT 2016-12-12 23:09:25.202 INFO
29 --- [ main] o.c.samples.music.Application :
Starting Application on 1a37tgli287 with PID 29 (/home/vcap/app started by
vcap in /home/vcap/app)

...

Initially we though it could be related to the disk/memory constraint on
DEAs, so we have increased more capacity, so no help here. We thought the
problem be be related to our applications, so we tried to use the Spring
Music sample app (https://github.com/cloudfoundry-samples/spring-music)
and we still have the same startup problem (app crash) as indicated above.

When looked at the dea_next.log, we could not find any obviously wrong
according to our knowledge, however obvious errors except these errors:

"error":"Container state must be one of 'active', current state is
'stopped'","backtrace":["/var/vcap/packages/dea_next/vendor/
cache/warden-b72b8c5a532d/em-warden-client/lib/em/warden/client/connection.rb:25:in
`get'","/var/vcap/packages/dea_next/vendor/cache/warden-
b72b8c5a532d/em-warden-client/lib/em/warden/client.rb:46:in
`call'","/var/vcap/packages/dea_next/lib/container/container.rb:193:in
`call'","/var/vcap/packages/dea_next/lib/container/container.rb:133:in
`block in setup_egress_rules'","/var/vcap/packages/dea_next/lib/container/container.rb:132:in
`each'","/var/vcap/packages/dea_next/lib/container/container.rb:132:in
`setup_egress_rules'","/var/vcap/packages/dea_next/lib/container/container.rb:126:in
`block in create_container'","/var/vcap/packages/dea_next/lib/container/container.rb:235:in
`call'","/var/vcap/packages/dea_next/lib/container/container.rb:235:in
`with_em'","/var/vcap/packages/dea_next/lib/container/container.rb:119:in
`create_container'","/var/vcap/pac
kages/de
a_next/lib/dea/starting/instance.rb:552:in `block in
promise_container'","/var/vcap/packages/dea_next/lib/dea/promise.rb:92:in
`call'","/var/vcap/packages/dea_next/lib/dea/promise.rb:92:in `block in
run'"]},"thread_id":46964431542680,"fiber_id":46964755305680,"process_id":
5695,"file":"/var/vcap/packages/dea_next/lib/dea/
task.rb","lineno":105,"method":"block in resolve_and_log"}

It looked like DEA failed to create a container for the app when setting
up egress rules for the container (race/deadlock?), but I could be wrong
here. The dea_next.log is avaialable in the following pastebin URI.

dea_next.log: http://pastebin.com/PBm1RFtq

We're using Cloud Foundry Release #237.

Please let me me know you if you need further information for
troubleshooting the problem.

Thanks in advance for your help.

Thanks,
Phong
--
Michal Kuratczyk


Re: CF CAB call next week Wednesday December 14th @ 8a PST --- last one for 2016

Guillaume Berche
 

Thanks Max for the reminder.

I prepared some questions into the Cab agenda google doc [1]. As there
might be too many of them, or some of them being not suited for the Cab
(too specific ?), participants could choose to prepare some alternative
questions, or possibly vote (with "+1") for questions they'd like to be
answered 1st ?

[1]
https://docs.google.com/document/d/1SCOlAquyUmNM-AQnekCOXiwhLs6gveTxAcduvDcW_xI/edit#

Guillaume.

On Mon, Dec 12, 2016 at 11:14 PM, Michael Maximilien <maxim(a)us.ibm.com>
wrote:

Final reminder of the last CAB call for 2016 is this coming Wednesday at
8a Pacific time. All info below.

Talk to you then. Best,

dr.max
ibm cloud labs
sillicon valley, ca

Sent from my iPhone

Begin forwarded message:

*From:* "Michael Maximilien" <maxim(a)us.ibm.com>
*Date:* December 7, 2016 at 11:37:23 AM PST
*To:* cf-dev(a)lists.cloudfoundry.org
*Subject:* *CF CAB call next week Wednesday December 14th @ 8a PST ---
last one for 2016*

Hi, all,

Quick reminder of the final CAB call of 2016 is next Wednesday,
December 14th @ 8a PST.

In addition to open QAs with CF PMs, we are also looking for suggestions
of two or three cloudfoundry-community projects or new proposals to
highlight and perhaps have a short presentation on. Please reply directly
to me with your suggestions and nominations (nominating yourself is
perfectly fine).

Finally, join the slack.cloudfoundry.org and join the #CAB channel for
previous and future discussions.

Talk to you all next week. We'll send one more reminder on this list.

Best,

Chip, James, and Max

dr.max
ibm cloud labs
sillicon valley, ca

Sent from my iPhone



App failed to startup or crashed

Phong Tran
 

Recently we just just consolidated several Cloud Foundry (CF) instances into one shared CF instance for resource sharing and we are now occasionally running into a problem with starting up applications . Basically when trying to start an application, we noticed one DEA is selected to run the app, but app failed to startup, so another DEA is selected. This DEA selection process would continue until the app is successfully started up on the seelcted DEA or app startup is timed out.

Starting app spring-music in org CI / space ngisspace as admin...

0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 down
0 of 1 instances running, 1 down
0 of 1 instances running, 1 down
0 of 1 instances running, 1 down
0 of 1 instances running, 1 down
0 of 1 instances running, 1 down
0 of 1 instances running, 1 down
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
1 of 1 instances running
App started
OK

cf logs spring-music
...
2016-12-12T15:06:50.54-0800 [DEA/10] OUT Starting app instance (index 0) with guid ccc3299d-758e-42a3-9210-8c8264d6d9a7
2016-12-12T15:08:43.91-0800 [DEA/8] OUT Starting app instance (index 0) with guid ccc3299d-758e-42a3-9210-8c8264d6d9a7
2016-12-12T15:09:24.68-0800 [App/0] OUT
2016-12-12T15:09:24.68-0800 [App/0] OUT . ____ _ __ _ _
2016-12-12T15:09:24.68-0800 [App/0] OUT /\\ / ___'_ __ _ _(_)_ __ __ _ \ \ \ \
2016-12-12T15:09:24.68-0800 [App/0] OUT ( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
2016-12-12T15:09:24.68-0800 [App/0] OUT \\/ ___)| |_)| | | | | || (_| | ) ) ) )
2016-12-12T15:09:24.68-0800 [App/0] OUT ' |____| .__|_| |_|_| |_\__, | / / / /
2016-12-12T15:09:24.68-0800 [App/0] OUT =========|_|==============|___/=/_/_/_/
2016-12-12T15:09:24.68-0800 [App/0] OUT :: Spring Boot :: (v1.3.5.RELEASE)
2016-12-12T15:09:24.83-0800 [App/0] OUT 2016-12-12 23:09:24.833 INFO 29 --- [ main] pertySourceApplicationContextInitializer : Adding 'cloud' PropertySource to ApplicationContext
2016-12-12T15:09:24.90-0800 [App/0] OUT 2016-12-12 23:09:24.908 INFO 29 --- [ main] nfigurationApplicationContextInitializer : Adding cloud service auto-reconfiguration to ApplicationContext
2016-12-12T15:09:25.19-0800 [App/0] OUT 2016-12-12 23:09:25.197 INFO 29 --- [ main] .m.c.SpringApplicationContextInitializer : Found serviceInfos:
2016-12-12T15:09:25.20-0800 [App/0] OUT 2016-12-12 23:09:25.202 INFO 29 --- [ main] o.c.samples.music.Application : Starting Application on 1a37tgli287 with PID 29 (/home/vcap/app started by vcap in /home/vcap/app)

...

Initially we though it could be related to the disk/memory constraint on DEAs, so we have increased more capacity, so no help here. We thought the problem be be related to our applications, so we tried to use the Spring Music sample app (https://github.com/cloudfoundry-samples/spring-music) and we still have the same startup problem (app crash) as indicated above.

When looked at the dea_next.log, we could not find any obviously wrong according to our knowledge, however obvious errors except these errors:

"error":"Container state must be one of 'active', current state is 'stopped'","backtrace":["/var/vcap/packages/dea_next/vendor/cache/warden-b72b8c5a532d/em-warden-client/lib/em/warden/client/connection.rb:25:in `get'","/var/vcap/packages/dea_next/vendor/cache/warden-b72b8c5a532d/em-warden-client/lib/em/warden/client.rb:46:in `call'","/var/vcap/packages/dea_next/lib/container/container.rb:193:in `call'","/var/vcap/packages/dea_next/lib/container/container.rb:133:in `block in setup_egress_rules'","/var/vcap/packages/dea_next/lib/container/container.rb:132:in `each'","/var/vcap/packages/dea_next/lib/container/container.rb:132:in `setup_egress_rules'","/var/vcap/packages/dea_next/lib/container/container.rb:126:in `block in create_container'","/var/vcap/packages/dea_next/lib/container/container.rb:235:in `call'","/var/vcap/packages/dea_next/lib/container/container.rb:235:in `with_em'","/var/vcap/packages/dea_next/lib/container/container.rb:119:in `create_container'","/var/vcap/packages/de
a_next/lib/dea/starting/instance.rb:552:in `block in promise_container'","/var/vcap/packages/dea_next/lib/dea/promise.rb:92:in `call'","/var/vcap/packages/dea_next/lib/dea/promise.rb:92:in `block in run'"]},"thread_id":46964431542680,"fiber_id":46964755305680,"process_id":5695,"file":"/var/vcap/packages/dea_next/lib/dea/task.rb","lineno":105,"method":"block in resolve_and_log"}

It looked like DEA failed to create a container for the app when setting up egress rules for the container (race/deadlock?), but I could be wrong here. The dea_next.log is avaialable in the following pastebin URI.

dea_next.log: http://pastebin.com/PBm1RFtq

We're using Cloud Foundry Release #237.

Please let me me know you if you need further information for troubleshooting the problem.

Thanks in advance for your help.

Thanks,
Phong


CF CAB call next week Wednesday December 14th @ 8a PST --- last one for 2016

Michael Maximilien
 

Final reminder of the last CAB call for 2016 is this coming Wednesday at 8a Pacific time. All info below.

Talk to you then. Best,

dr.max
ibm cloud labs
sillicon valley, ca

Sent from my iPhone

Begin forwarded message:

From: "Michael Maximilien" <maxim(a)us.ibm.com>
Date: December 7, 2016 at 11:37:23 AM PST
To: cf-dev(a)lists.cloudfoundry.org
Subject: CF CAB call next week Wednesday December 14th @ 8a PST --- last one for 2016

Hi, all,

Quick reminder of the final CAB call of 2016 is next Wednesday, December 14th @ 8a PST.

In addition to open QAs with CF PMs, we are also looking for suggestions of two or three cloudfoundry-community projects or new proposals to highlight and perhaps have a short presentation on. Please reply directly to me with your suggestions and nominations (nominating yourself is perfectly fine).

Finally, join the slack.cloudfoundry.org and join the #CAB channel for previous and future discussions.

Talk to you all next week. We'll send one more reminder on this list.

Best,

Chip, James, and Max

dr.max
ibm cloud labs
sillicon valley, ca

Sent from my iPhone


Re: Using a deployment based on a Buildpack, it is possible to define multiple cores for that app?

Chip Childers <cchilders@...>
 

That's odd. It works for me. Did the URL get mangled on your side?
On Mon, Dec 12, 2016 at 2:02 PM Juan Antonio Breña Moral <
bren(a)juanantonio.info> wrote:

Hi Daniel, the link return:

The requested URL /archives/list/cf-dev@
lists.cloudfoundry.org/message/B76YGMZ5DQS2WGJZLAI45LBV6ZRKVVRI/ was not
found on this server.

Another address?

Juan Antonio
--
Chip Childers
CTO, Cloud Foundry Foundation
1.267.250.0815


Re: Using a deployment based on a Buildpack, it is possible to define multiple cores for that app?

Juan Antonio Breña Moral <bren at juanantonio.info...>
 

Hi Daniel, the link return:

The requested URL /archives/list/cf-dev@lists.cloudfoundry.org/message/B76YGMZ5DQS2WGJZLAI45LBV6ZRKVVRI/ was not found on this server.

Another address?

Juan Antonio


Re: Using a deployment based on a Buildpack, it is possible to define multiple cores for that app?

Daniel Mikusa
 

No. See this email for an explanation.

https://lists.cloudfoundry.org/archives/list/cf-dev(a)lists.cloudfoundry.org/message/B76YGMZ5DQS2WGJZLAI45LBV6ZRKVVRI/

Dan

On Sat, Dec 10, 2016 at 11:46 AM, Juan Antonio Breña Moral <
bren(a)juanantonio.info> wrote:

Hi,

I would like to know if using CF with Buildpacks, it is possible to define
the number of cores to be used by the app.
With Docker, it is possible to define the number of cores with the
following option:

``` bash
docker run ubuntu /bin/echo 'Hello world --cpuset-cpus="0-3"
````

Juan Antonio


Re: CVE-2016-8218: Unauthenticated JWT signing algorithm in routing

Shannon Coen
 

Clarification:

The routing-api job is not deployed with cf-release. It is deployed with
the routing-release [1], which provides support for TCP routing to apps on
Diego. If you have not deployed the routing-release specifically, then
chances are you do not have the routing-api job deployed and no action is
required.

To confirm, look at your BOSH deployments.

$ bosh deployments

For those who have deployed the routing-release, we recommend upgrading now
to version 0.142.0 which contains a fix for the vulnerability:
https://github.com/cloudfoundry-incubator/routing-release/releases/tag/0.142.0

[1] https://github.com/cloudfoundry-incubator/routing-release

Best,

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

On Fri, Dec 9, 2016 at 11:00 PM, Molly Crowther <mcrowther(a)cloudfoundry.org>
wrote:

A new cf-release has been cut to mitigate the following issue. This notice
can also be found at https://www.cloudfoundry.org/cve-2016-8218/. An RSS
feed of Cloud Foundry vulnerabilities is available at
https://www.cloudfoundry.org/category/security/feed/.


CVE-2016-8218: Unauthenticated JWT signing algorithm in routing
Severity

Critical
Vendor

Cloud Foundry Foundation
Versions Affected

-

cf-release versions prior to 237, if:
-

any versions of routing release have been uploaded, AND
-

the routing API is enabled through a manifest property on cf-release
-

cf-release versions 237 and later, prior to v249

Description

Incomplete validation logic in JSON Web Token (JWT) libraries can allow
unprivileged attackers to impersonate other users to the routing API.
Mitigation

OSS users of affected versions are strongly encouraged to:

-

Upgrade to Cloud Foundry v249 [1] or later

Credit

The issue was responsibly reported by a Pivotal team member.
References

-

[1] https://github.com/cloudfoundry/cf-release/releases

History2016-12-09: Initial vulnerability report published


Using a deployment based on a Buildpack, it is possible to define multiple cores for that app?

Juan Antonio Breña Moral <bren at juanantonio.info...>
 

Hi,

I would like to know if using CF with Buildpacks, it is possible to define the number of cores to be used by the app.
With Docker, it is possible to define the number of cores with the following option:

``` bash
docker run ubuntu /bin/echo 'Hello world --cpuset-cpus="0-3"
````

Juan Antonio


CVE-2016-8218: Unauthenticated JWT signing algorithm in routing

Molly Crowther
 

A new cf-release has been cut to mitigate the following issue. This notice
can also be found at https://www.cloudfoundry.org/cve-2016-8218/. An RSS
feed of Cloud Foundry vulnerabilities is available at
https://www.cloudfoundry.org/category/security/feed/.


CVE-2016-8218: Unauthenticated JWT signing algorithm in routing
Severity

Critical
Vendor

Cloud Foundry Foundation
Versions Affected

-

cf-release versions prior to 237, if:
-

any versions of routing release have been uploaded, AND
-

the routing API is enabled through a manifest property on cf-release
-

cf-release versions 237 and later, prior to v249

Description

Incomplete validation logic in JSON Web Token (JWT) libraries can allow
unprivileged attackers to impersonate other users to the routing API.
Mitigation

OSS users of affected versions are strongly encouraged to:

-

Upgrade to Cloud Foundry v249 [1] or later

Credit

The issue was responsibly reported by a Pivotal team member.
References

-

[1] https://github.com/cloudfoundry/cf-release/releases

History2016-12-09: Initial vulnerability report published


Proposal: Private Docker repository support

Will Pragnell <wpragnell@...>
 

Hi all,

We've recently come up with a proposal for adding support for private
Docker repositories to Cloud Foundry [1]. The runtime product team spent
some time considering various solutions to the problem (details of which
are linked to from within the doc) and we feel that the proposed solution
is the best next step, given the relative ease of implementation and the
simplicity of the UX.

We'd love to hear any feedback from the community. Please leave input and
feedback in the comments on the document.

We're hoping to begin work on this with at least some of the teams involved
before the end of the year. We intend to start at the Garden / GrootFS
level, as the changes needed there should be essentially the same
regardless of any changes we might make to the whole feature.

Thanks,
Will - GrootFS project lead

[1] https://goo.gl/xw2Z6V


Custom health checks

John Feminella <jxf@...>
 

hi all,
Is there a custom health checks proposal that is being worked on or has already
been accepted? If not, what is the state of the CF roadmap with respect to
custom health checks?
best,~ jf--John Feminella
Advisory Platform Architect
✉ ·jxf(a)pivotal.io
t · @jxxf


Re: USN-3151-2: Linux kernel (Xenial HWE) vulnerability

Molly Crowther
 

Hi Marco,

Thanks for the feedback - I do usually include the Ubuntu link in the
postings but overlooked it this time (and just added it on the site). I
agree it's annoying to have to copy-paste out the link. :)

https://www.ubuntu.com/usn/usn-3151-2/

Thanks,
Molly

On Thu, Dec 8, 2016 at 11:35 PM, Voelz, Marco <marco.voelz(a)sap.com> wrote:

Dear Molly,



thanks for pushing these security notifications to the cloudfoundry site
and this mailing list!



One small suggestion: Could you please include a link to the original
source of the vulnerability posting, in this case to the Ubuntu USN?
Otherwise, everybody just has to copy out the USN-id, open the Ubuntu USN
page, paste it to find the original notice.



Thanks and warm regards

Marco



*From: *Molly Crowther <mcrowther(a)cloudfoundry.org>
*Reply-To: *"Discussions about Cloud Foundry projects and the system
overall." <cf-dev(a)lists.cloudfoundry.org>
*Date: *Thursday, 8 December 2016 at 00:26
*To: *"Discussions about Cloud Foundry projects and the system overall." <
cf-dev(a)lists.cloudfoundry.org>
*Subject: *[cf-dev] USN-3151-2: Linux kernel (Xenial HWE) vulnerability



The following notice has been posted to cloudfoundry.org/security:

https://www.cloudfoundry.org/usn-3151-2/



It details the information for the new versions of the BOSH stemcell that
mitigate a high-severity kernel CVE.


Users are strongly encouraged to upgrade BOSH stemcells in all deployments
to one of the following versions:

· Upgrade all earlier versions to 3151.5

· Upgrade 3233.x versions to 3233.6 or later

· Upgrade 3263.x versions to 3263.12 or later

· Upgrade 3312.x versions to to 3312.7 or later

Thanks,

Molly Crowther

Cloud Foundry Foundation Security Team


Re: Memory/Disk usage information -MB vs MiB

Nicholas Calugar
 

Hi Ponraj,

Apologies for the delay, I promise you I have been considering this query,
just having trouble finding the correct response.

I think I actually do need more of an example of how this is failing you,
it’s not clear why presenting [1] Org Memory Usage in MB is inherently
wrong when [2] App Memory is also MB. For example:

cf curl "/v2/apps?q=space_guid:d2357fe4-a9f2-4c76-99d9-321b7668fde4" | grep
memory
"memory": 256,
"memory": 1000,

cf curl /v2/organizations/$(cf org system --guid)/memory_usage

{
"memory_usage_in_mb": 1256
}


Do you think you could provide a more end-to-end example of when this goes
wrong?

Thanks,

Nick


[1]
http://apidocs.cloudfoundry.org/234/organizations/retrieving_organization_memory_usage.html
[2] http://apidocs.cloudfoundry.org/234/apps/creating_an_app.html

--
Nicholas Calugar

On December 7, 2016 at 11:16:53 AM, Ponraj E (ponraj.e(a)gmail.com) wrote:

Hi Nicholas,

Anything that you expect from us? Are we missing something here?

---
Ponraj


Re: USN-3151-2: Linux kernel (Xenial HWE) vulnerability

Graham Bleach
 

On 9 December 2016 at 08:13, Guillaume Berche <bercheg(a)gmail.com> wrote:

thanks for pushing these security notifications to the cloudfoundry
site and this mailing list!
+1

Also, is there an RSS feed that enables programmatic access to newly
disclosed vulnerabilities on the security page ?
+1

We're currently doing this by running an app [1] in our CF that scrapes the
Pivotal security page once an hour & creates events in Datadog
corresponding to new CVEs. Datadog then raises a ticket in our support
system. It's perhaps a bit over-engineered, but we wanted to have the
events in Datadog so we could put the alerts in a dashboard etc. if we
wanted.

We only used the Pivotal security page because the Cloud Foundry one didn't
exist then. Ideally there would be a stable machine-readable list of all
CVEs relevant to the open source product. If it is RSS/atom we might be
able to do what we want without writing code, using something like
https://ifttt.com/

Cheers,
Graham

[1] https://github.com/alphagov/paas-cve-notifier