1. cf-dev@lists.cloudfoundry.org
  2. Messages
   Date   
Syslog Drain to Logstash Problems

Steve Wall <steve.wall@...>
 

Hello,
We are having problems draining log messages to Logstash. The drain is
setup as a user provided service.

cf cups logstash-drain -l syslog://xx.xx.xx.xx:5000

And then bound to the service.

cf bind-service myapp logstash-drain

But no log messages are coming through to Logstash. Or more specifically,
we are using ELK and the messages aren't seen through Kibana.

We were able to log into the DEA and using netcat (nc), messages were
successfully submitted to the ELK stack.

nc -w0 -u xx.xx.xx.xx 5000 <<< "logging from remote"

Any suggestions on how to debug this further?
-Steve

?
attachment.html

Re: Release Notes for v210

Eric Malm <emalm@...>
 

Hi, all,

Please be aware that the Diego team has recently identified a goroutine and
memory leak in the Diego codebase for release 0.1247.0 that eventually
affects the performance of Diego's receptor component. Further
investigation has revealed that this leak was introduced in final release
0.1221.0 and fixed in 0.1259.0. Consequently, we do not recommend the use
of Diego final releases from 0.1221.0 through 0.1258.0 in long-running
environments. If you do need to mitigate this issue in such an environment,
issuing a 'monit restart' to each receptor process on the Diego 'access'
VMs once it consumes a majority of available memory on the VM should
suffice and should have negligible impact on the performance and
availability of the Diego backend, especially if more than one 'access' VM
is present in the Diego deployment.

The next final release of CF (namely, v211) will be accompanied by a Diego
final release that does not exhibit this problem. Additionally, the Diego
team has identified and corrected the gaps in our testing pipeline and
monitoring configuration that allowed this resource leak to slip through.

Thank you for your understanding, and please let me know if you have
further questions about this matter.

Best,
Eric, CF Runtime Diego PM

On Tue, May 26, 2015 at 10:59 PM, Dieu Cao <dcao(a)pivotal.io> wrote:

The cf-release v210 was released on May 23rd, 2015
Runtime

- Addressed USN-2617-1 <http://www.ubuntu.com/usn/usn-2617-1/>
CVE-2015-3202
<http://people.canonical.com/~ubuntu-security/cve/2015/CVE-2015-3202.html> FUSE
vulnerabilities
- Removed fuse binaries from lucid64 rootfs . Apps running on
lucid64 stack requiring fuse should switch to cflinuxfs2 details
<https://www.pivotaltracker.com/story/show/95186578>
- fuse binaries updated on cflinuxfs2 rootfs. details
<https://www.pivotaltracker.com/story/show/95177810>
- [Experimental] Work continues on support for Asynchronous Service
Instance Operationsdetails
<https://www.pivotaltracker.com/epic/show/1561148>
- Support for configurable max polling duration
- [Experimental] Work continues on /v3 and Application Process Types
details <https://www.pivotaltracker.com/epic/show/1334418>
- [Experimental] Work continues on Route API details
<https://www.pivotaltracker.com/epic/show/1590160>
- [Experimental] Work continues on Context Path Routes details
<https://www.pivotaltracker.com/epic/show/1808212>
- Work continues on support for Service Keys details
<https://www.pivotaltracker.com/epic/show/1743366>
- Upgrade etcd server to 2.0.1 details
<https://www.pivotaltracker.com/story/show/91070214>
- Should be run as 1 node (for small deployments) or 3 nodes spread
across zones (for HA)
- Also upgrades hm9k dependencies. LAMB client to be upgraded in a
subsequent release. Older client is compatible.
- cloudfoundry/cf-release #670
<https://github.com/cloudfoundry/cf-release/pull/670>: Be able to
specify timeouts for acceptance tests without defaults in the spec.
details <https://www.pivotaltracker.com/story/show/93914198>
- Fix bug where ssl enabled routers were not draining properly details
<https://www.pivotaltracker.com/story/show/94718480>
- cloudfoundry/cloud_controller_ng #378
<https://github.com/cloudfoundry/cf-release/pull/378>: current usage
against the org quota details
<https://www.pivotaltracker.com/story/show/94171010>

UAA

- Bumped to UAA 2.3.0 details
<https://github.com/cloudfoundry/uaa/releases/tag/2.3.0>

Used Configuration

- BOSH Version: 152
- Stemcell Version: 2889
- CC Api Version: 2.27.0

Commit summary
<http://htmlpreview.github.io/?https://github.com/cloudfoundry-community/cf-docs-contrib/blob/master/release_notes/cf-210-whats-in-the-deploy.html>
Compatible Diego Version

- final release 0.1247.0 commit
<https://github.com/cloudfoundry-incubator/diego-release/commit/a122a78eeb344bbfc90b7bcd0fa987d08ef1a5d1>

Manifest and Job Spec Changes

- properties.acceptance_tests.skip_regex added
- properties.app_ssh.host_key_fingerprint added
- properties.app_ssh.port defaults to 2222
- properties.uaa.newrelic added
- properties.login.logout.redirect.parameter.whitelist


On Sat, May 23, 2015 at 9:50 PM, James Bayer <jbayer(a)pivotal.io> wrote:

CVE-2015-3202 details:
http://lists.cloudfoundry.org/pipermail/cf-dev/2015-May/000194.html

CVE-2015-1834 details:
http://lists.cloudfoundry.org/pipermail/cf-dev/2015-May/000195.html

On Sat, May 23, 2015 at 9:41 PM, James Bayer <jbayer(a)pivotal.io> wrote:

please note that this release addresses CVE-2015-3202 and CVE-2015-1834
and we strongly recommend upgrading to this release. more details will be
forthcoming after the long united states holiday weekend.

https://github.com/cloudfoundry/cf-release/releases/tag/v210

*https://github.com/cloudfoundry-community/cf-docs-contrib/wiki/v210
<https://github.com/cloudfoundry-community/cf-docs-contrib/wiki/v210>*

--
Thank you,

James Bayer


--
Thank you,

James Bayer

_______________________________________________
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

?
attachment.html

Re: Release Notes for v210

CF Runtime
 

Hi Guillaume,

The metron_agent.deployment default can be found in
cf-release/templates/cf-lamb.yml which should get merged automatically if
using the generate_deployment_manifest script in cf-release.

We do currently have pipelines for all supported environments (AWS,
vSphere, OpenStack, and BoshLite)

Spiff templates are still the recommended way of deploying cf-release, and
I would expect the nfs template change to be merged today as it is near the
top of our backlog.

Joseph Palermo
CF Runtime Team

On Wed, Jun 3, 2015 at 7:32 AM, Guillaume Berche <bercheg(a)gmail.com> wrote:

Hi,

Thanks for the v210 announcement and the associated release note. It seems
that the v209-announced introduction of a new mandatory
metron_agent.deployment property did not make it into the default spiff
templates [5]. Note I tried updating v209 release note formatting to make
this more explicit [6].

I'm wondering whether the pivotal runtime/release team has a cf-release
pipeline for vsphere infrastructure (I'm suspecting the aws-based pipelines
were fine) ? Is such pipeline using the spiff templates into
cf-release/templates [4], or has it moved to something else such as
cf-boshworkspace [3] ?

If the spiff templates templates into cfrelease/templates are still the
recommended way of deploying CF, is there a way to priorize the merge of
PRs for known issues in v211 such as [1] and [2], as to avoid the need by
the cf-community to maintain its own fork of cfrelease/templates ?

Thanks in advance,

Guillaume.

[1] https://github.com/cloudfoundry/cf-release/pull/689
[2] https://github.com/cloudfoundry/cf-release/pull/696
[3] https://github.com/cloudfoundry-community/cf-boshworkspace
[4] https://github.com/cloudfoundry/cf-release/tree/master/templates
[5] https://github.com/cloudfoundry/cf-release/issues/690
[6] https://github.com/cloudfoundry-community/cf-docs-contrib/wiki/v209/fdae17795c61691f96f90cc9fd7be90945252937



On Wed, May 27, 2015 at 7:59 AM, Dieu Cao <dcao(a)pivotal.io> wrote:

The cf-release v210 was released on May 23rd, 2015
Runtime

- Addressed USN-2617-1 <http://www.ubuntu.com/usn/usn-2617-1/>
CVE-2015-3202
<http://people.canonical.com/~ubuntu-security/cve/2015/CVE-2015-3202.html> FUSE
vulnerabilities
- Removed fuse binaries from lucid64 rootfs . Apps running on
lucid64 stack requiring fuse should switch to cflinuxfs2 details
<https://www.pivotaltracker.com/story/show/95186578>
- fuse binaries updated on cflinuxfs2 rootfs. details
<https://www.pivotaltracker.com/story/show/95177810>
- [Experimental] Work continues on support for Asynchronous Service
Instance Operationsdetails
<https://www.pivotaltracker.com/epic/show/1561148>
- Support for configurable max polling duration
- [Experimental] Work continues on /v3 and Application Process Types
details <https://www.pivotaltracker.com/epic/show/1334418>
- [Experimental] Work continues on Route API details
<https://www.pivotaltracker.com/epic/show/1590160>
- [Experimental] Work continues on Context Path Routes details
<https://www.pivotaltracker.com/epic/show/1808212>
- Work continues on support for Service Keys details
<https://www.pivotaltracker.com/epic/show/1743366>
- Upgrade etcd server to 2.0.1 details
<https://www.pivotaltracker.com/story/show/91070214>
- Should be run as 1 node (for small deployments) or 3 nodes
spread across zones (for HA)
- Also upgrades hm9k dependencies. LAMB client to be upgraded in a
subsequent release. Older client is compatible.
- cloudfoundry/cf-release #670
<https://github.com/cloudfoundry/cf-release/pull/670>: Be able to
specify timeouts for acceptance tests without defaults in the spec.
details <https://www.pivotaltracker.com/story/show/93914198>
- Fix bug where ssl enabled routers were not draining properly details
<https://www.pivotaltracker.com/story/show/94718480>
- cloudfoundry/cloud_controller_ng #378
<https://github.com/cloudfoundry/cf-release/pull/378>: current usage
against the org quota details
<https://www.pivotaltracker.com/story/show/94171010>

UAA

- Bumped to UAA 2.3.0 details
<https://github.com/cloudfoundry/uaa/releases/tag/2.3.0>

Used Configuration

- BOSH Version: 152
- Stemcell Version: 2889
- CC Api Version: 2.27.0

Commit summary
<http://htmlpreview.github.io/?https://github.com/cloudfoundry-community/cf-docs-contrib/blob/master/release_notes/cf-210-whats-in-the-deploy.html>
Compatible Diego Version

- final release 0.1247.0 commit
<https://github.com/cloudfoundry-incubator/diego-release/commit/a122a78eeb344bbfc90b7bcd0fa987d08ef1a5d1>

Manifest and Job Spec Changes

- properties.acceptance_tests.skip_regex added
- properties.app_ssh.host_key_fingerprint added
- properties.app_ssh.port defaults to 2222
- properties.uaa.newrelic added
- properties.login.logout.redirect.parameter.whitelist


On Sat, May 23, 2015 at 9:50 PM, James Bayer <jbayer(a)pivotal.io> wrote:

CVE-2015-3202 details:
http://lists.cloudfoundry.org/pipermail/cf-dev/2015-May/000194.html

CVE-2015-1834 details:
http://lists.cloudfoundry.org/pipermail/cf-dev/2015-May/000195.html

On Sat, May 23, 2015 at 9:41 PM, James Bayer <jbayer(a)pivotal.io> wrote:

please note that this release addresses CVE-2015-3202 and CVE-2015-1834
and we strongly recommend upgrading to this release. more details will be
forthcoming after the long united states holiday weekend.

https://github.com/cloudfoundry/cf-release/releases/tag/v210

*https://github.com/cloudfoundry-community/cf-docs-contrib/wiki/v210
<https://github.com/cloudfoundry-community/cf-docs-contrib/wiki/v210>*

--
Thank you,

James Bayer


--
Thank you,

James Bayer

_______________________________________________
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

?
attachment.html

Re: Staging error: no available stagers (status code: 400, error code: 170001)

Takeshi Morikawa
 

Please check the 'staging.advertise' of nats message
https://github.com/cloudfoundry/dea_ng#staging

sample command:
bundle exec nats-sub -s
nats://[nats.user]:[nats.password]@[nats_ipaddress]:[nats.port]
'staging.advertise'


I have one additional request
Can you share your bosh deployment manifest?

?
attachment.html

Re: Release Notes for v210

Guillaume Berche
 

Hi,

Thanks for the v210 announcement and the associated release note. It seems
that the v209-announced introduction of a new mandatory
metron_agent.deployment property did not make it into the default spiff
templates [5]. Note I tried updating v209 release note formatting to make
this more explicit [6].

I'm wondering whether the pivotal runtime/release team has a cf-release
pipeline for vsphere infrastructure (I'm suspecting the aws-based pipelines
were fine) ? Is such pipeline using the spiff templates into
cf-release/templates [4], or has it moved to something else such as
cf-boshworkspace [3] ?

If the spiff templates templates into cfrelease/templates are still the
recommended way of deploying CF, is there a way to priorize the merge of
PRs for known issues in v211 such as [1] and [2], as to avoid the need by
the cf-community to maintain its own fork of cfrelease/templates ?

Thanks in advance,

Guillaume.

[1] https://github.com/cloudfoundry/cf-release/pull/689
[2] https://github.com/cloudfoundry/cf-release/pull/696
[3] https://github.com/cloudfoundry-community/cf-boshworkspace
[4] https://github.com/cloudfoundry/cf-release/tree/master/templates
[5] https://github.com/cloudfoundry/cf-release/issues/690
[6] https://github.com/cloudfoundry-community/cf-docs-contrib/wiki/v209/fdae17795c61691f96f90cc9fd7be90945252937

On Wed, May 27, 2015 at 7:59 AM, Dieu Cao <dcao(a)pivotal.io> wrote:

The cf-release v210 was released on May 23rd, 2015
Runtime

- Addressed USN-2617-1 <http://www.ubuntu.com/usn/usn-2617-1/>
CVE-2015-3202
<http://people.canonical.com/~ubuntu-security/cve/2015/CVE-2015-3202.html> FUSE
vulnerabilities
- Removed fuse binaries from lucid64 rootfs . Apps running on
lucid64 stack requiring fuse should switch to cflinuxfs2 details
<https://www.pivotaltracker.com/story/show/95186578>
- fuse binaries updated on cflinuxfs2 rootfs. details
<https://www.pivotaltracker.com/story/show/95177810>
- [Experimental] Work continues on support for Asynchronous Service
Instance Operationsdetails
<https://www.pivotaltracker.com/epic/show/1561148>
- Support for configurable max polling duration
- [Experimental] Work continues on /v3 and Application Process Types
details <https://www.pivotaltracker.com/epic/show/1334418>
- [Experimental] Work continues on Route API details
<https://www.pivotaltracker.com/epic/show/1590160>
- [Experimental] Work continues on Context Path Routes details
<https://www.pivotaltracker.com/epic/show/1808212>
- Work continues on support for Service Keys details
<https://www.pivotaltracker.com/epic/show/1743366>
- Upgrade etcd server to 2.0.1 details
<https://www.pivotaltracker.com/story/show/91070214>
- Should be run as 1 node (for small deployments) or 3 nodes spread
across zones (for HA)
- Also upgrades hm9k dependencies. LAMB client to be upgraded in a
subsequent release. Older client is compatible.
- cloudfoundry/cf-release #670
<https://github.com/cloudfoundry/cf-release/pull/670>: Be able to
specify timeouts for acceptance tests without defaults in the spec.
details <https://www.pivotaltracker.com/story/show/93914198>
- Fix bug where ssl enabled routers were not draining properly details
<https://www.pivotaltracker.com/story/show/94718480>
- cloudfoundry/cloud_controller_ng #378
<https://github.com/cloudfoundry/cf-release/pull/378>: current usage
against the org quota details
<https://www.pivotaltracker.com/story/show/94171010>

UAA

- Bumped to UAA 2.3.0 details
<https://github.com/cloudfoundry/uaa/releases/tag/2.3.0>

Used Configuration

- BOSH Version: 152
- Stemcell Version: 2889
- CC Api Version: 2.27.0

Commit summary
<http://htmlpreview.github.io/?https://github.com/cloudfoundry-community/cf-docs-contrib/blob/master/release_notes/cf-210-whats-in-the-deploy.html>
Compatible Diego Version

- final release 0.1247.0 commit
<https://github.com/cloudfoundry-incubator/diego-release/commit/a122a78eeb344bbfc90b7bcd0fa987d08ef1a5d1>

Manifest and Job Spec Changes

- properties.acceptance_tests.skip_regex added
- properties.app_ssh.host_key_fingerprint added
- properties.app_ssh.port defaults to 2222
- properties.uaa.newrelic added
- properties.login.logout.redirect.parameter.whitelist


On Sat, May 23, 2015 at 9:50 PM, James Bayer <jbayer(a)pivotal.io> wrote:

CVE-2015-3202 details:
http://lists.cloudfoundry.org/pipermail/cf-dev/2015-May/000194.html

CVE-2015-1834 details:
http://lists.cloudfoundry.org/pipermail/cf-dev/2015-May/000195.html

On Sat, May 23, 2015 at 9:41 PM, James Bayer <jbayer(a)pivotal.io> wrote:

please note that this release addresses CVE-2015-3202 and CVE-2015-1834
and we strongly recommend upgrading to this release. more details will be
forthcoming after the long united states holiday weekend.

https://github.com/cloudfoundry/cf-release/releases/tag/v210

*https://github.com/cloudfoundry-community/cf-docs-contrib/wiki/v210
<https://github.com/cloudfoundry-community/cf-docs-contrib/wiki/v210>*

--
Thank you,

James Bayer


--
Thank you,

James Bayer

_______________________________________________
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

?
attachment.html

Staging error: no available stagers (status code: 400, error code: 170001)

iamflying
 

Resend the question.

I deployed the cf into openstack successfully. However, I got failure when
I tried to push my first php example.

Starting app cf-php-demo in org system / space dev as admin...
FAILED
Server error, status code: 400, error code: 170001, message: Staging error:
no available stagers


Below is my findings. The DEA and CC have enough resources (4G RAM, 20G
disk). Any clues
to debug? Attached debug.log. debug.log
<http://cf-dev.70369.x6.nabble.com/file/n269/debug.log
*My env:*
BOSH 1.2978.0
cf version 6.10.0-b78bf10-2015-02-11T22:26:40+00:00
cf release: 207
stemcell: bosh-openstack-kvm-ubuntu-trusty-go_agent | 2969


ubuntu(a)boshclivm:~/apps/cf-php-demo$ CF_TRACE=debug.log cf push
Using manifest file /home/ubuntu/apps/cf-php-demo/manifest.yml

Creating app cf-php-demo in org system / space dev as admin...
OK

Using route cf-php-demo.runmyapp.io
Binding cf-php-demo.runmyapp.io to cf-php-demo...
OK

Uploading cf-php-demo...
Uploading app files from: /home/ubuntu/apps/cf-php-demo
Uploading 231.9K, 13 files
Done uploading
OK

Starting app cf-php-demo in org system / space dev as admin...
FAILED
Server error, status code: 400, error code: 170001, message: Staging error:
no available stagers


ubuntu(a)boshclivm:~/apps/cf-php-demo$ cf apps
Getting apps in org system / space dev as admin...
OK

name requested state instances memory disk urls
cf-php-demo started 0/1 128M 1G
cf-php-demo.cfapps.io
ubuntu(a)boshclivm:~/apps/cf-php-demo$


Additional error messages:
1. nginx.access.log
api.au.apaas.com - [03/Jun/2015:06:19:51 +0000] "PUT
/v2/apps/7b417005-6716-4d5e-bec2-246a51b588c6?async=true&inline-relations-depth=1
HTTP/1.1" 400 435 "-" "go-cli 6.10.0-b78bf10 / linux" 137.172.74.86,
100.64.1.0, 100.64.1.5
vcap_request_id:ae51df28-8371-44f2-4d18-5e13ded3a467::6faf587a-aba8-4467-8e1e-75b018eff93b
response_time:0.297

2. cloud_controller_ng.log
{"timestamp":1433313002.4425669,"message":"Request failed: 400:
{\"code\"=>170001, \"description\"=>\"Staging error: no available stagers\",
\"error_code\"=>\"CF-StagingError\",
\"backtrace\"=>[\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/lib/cloud_controller/dea/app_stager_task.rb:26:in
`stage'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/lib/cloud_controller/dea/stager.rb:45:in
`stage_app'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/lib/cloud_controller/app_observer.rb:57:in
`react_to_state_change'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/lib/cloud_controller/app_observer.rb:27:in
`updated'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/app/models/runtime/app.rb:534:in
`after_commit'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/sequel-4.21.0/lib/sequel/model/base.rb:1920:in
`block in _save'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/sequel-4.21.0/lib/sequel/database/transactions.rb:280:in
`call'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/sequel-4.21.0/lib/sequel/database/transactions.rb:280:in
`block in remove_transaction'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/sequel-4.21.0/lib/sequel/database/transactions.rb:280:in
`each'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/sequel-4.21.0/lib/sequel/database/transactions.rb:280:in
`remove_transaction'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/sequel-4.21.0/lib/sequel/database/transactions.rb:156:in
`_transaction'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/sequel-4.21.0/lib/sequel/database/transactions.rb:108:in
`block in transaction'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/sequel-4.21.0/lib/sequel/database/connecting.rb:250:in
`block in synchronize'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/sequel-4.21.0/lib/sequel/connection_pool/threaded.rb:98:in
`hold'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/sequel-4.21.0/lib/sequel/database/connecting.rb:250:in
`synchronize'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/sequel-4.21.0/lib/sequel/database/transactions.rb:97:in
`transaction'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/app/controllers/base/model_controller.rb:64:in
`update'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/app/controllers/base/base_controller.rb:76:in
`dispatch'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/lib/cloud_controller/rest_controller/routes.rb:16:in
`block in define_route'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/sinatra-1.4.5/lib/sinatra/base.rb:1602:in
`call'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/sinatra-1.4.5/lib/sinatra/base.rb:1602:in
`block in compile!'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/sinatra-1.4.5/lib/sinatra/base.rb:966:in
`[]'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/sinatra-1.4.5/lib/sinatra/base.rb:966:in
`block (3 levels) in route!'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/sinatra-1.4.5/lib/sinatra/base.rb:985:in
`route_eval'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/sinatra-1.4.5/lib/sinatra/base.rb:966:in
`block (2 levels) in route!'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/sinatra-1.4.5/lib/sinatra/base.rb:1006:in
`block in process_route'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/sinatra-1.4.5/lib/sinatra/base.rb:1004:in
`catch'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/sinatra-1.4.5/lib/sinatra/base.rb:1004:in
`process_route'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/sinatra-1.4.5/lib/sinatra/base.rb:964:in
`block in route!'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/sinatra-1.4.5/lib/sinatra/base.rb:963:in
`each'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/sinatra-1.4.5/lib/sinatra/base.rb:963:in
`route!'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/sinatra-1.4.5/lib/sinatra/base.rb:1076:in
`block in dispatch!'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/sinatra-1.4.5/lib/sinatra/base.rb:1058:in
`block in invoke'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/sinatra-1.4.5/lib/sinatra/base.rb:1058:in
`catch'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/sinatra-1.4.5/lib/sinatra/base.rb:1058:in
`invoke'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/sinatra-1.4.5/lib/sinatra/base.rb:1073:in
`dispatch!'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/sinatra-1.4.5/lib/sinatra/base.rb:898:in
`block in call!'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/sinatra-1.4.5/lib/sinatra/base.rb:1058:in
`block in invoke'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/sinatra-1.4.5/lib/sinatra/base.rb:1058:in
`catch'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/sinatra-1.4.5/lib/sinatra/base.rb:1058:in
`invoke'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/sinatra-1.4.5/lib/sinatra/base.rb:898:in
`call!'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/sinatra-1.4.5/lib/sinatra/base.rb:886:in
`call'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/rack-protection-1.5.3/lib/rack/protection/xss_header.rb:18:in
`call'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/rack-protection-1.5.3/lib/rack/protection/path_traversal.rb:16:in
`call'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/rack-protection-1.5.3/lib/rack/protection/json_csrf.rb:18:in
`call'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/rack-protection-1.5.3/lib/rack/protection/base.rb:49:in
`call'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/rack-protection-1.5.3/lib/rack/protection/base.rb:49:in
`call'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/rack-protection-1.5.3/lib/rack/protection/frame_options.rb:31:in
`call'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/rack-1.5.2/lib/rack/nulllogger.rb:9:in
`call'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/rack-1.5.2/lib/rack/head.rb:11:in
`call'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/sinatra-1.4.5/lib/sinatra/base.rb:180:in
`call'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/sinatra-1.4.5/lib/sinatra/base.rb:2014:in
`call'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/rack-1.5.2/lib/rack/builder.rb:138:in
`call'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/rack-1.5.2/lib/rack/urlmap.rb:65:in
`block in call'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/rack-1.5.2/lib/rack/urlmap.rb:50:in
`each'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/rack-1.5.2/lib/rack/urlmap.rb:50:in
`call'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/rack-1.5.2/lib/rack/builder.rb:138:in
`call'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/thin-1.6.3/lib/thin/connection.rb:86:in
`block in pre_process'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/thin-1.6.3/lib/thin/connection.rb:84:in
`catch'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/thin-1.6.3/lib/thin/connection.rb:84:in
`pre_process'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/eventmachine-1.0.3/lib/eventmachine.rb:1037:in
`call'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/eventmachine-1.0.3/lib/eventmachine.rb:1037:in
`block in
spawn_threadpool'\"]}","log_level":"info","source":"cc.api","data":{"request_guid":"d916023a-d364-492b-50bb-624e5862e455::2c136550-80cb-4d5b-8ab3-6c2dd397fc1a"},"thread_id":69941342398660,"fiber_id":69941329029340,"process_id":1816,"file":"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/lib/sinatra/vcap.rb","lineno":51,"method":"block
in registered"}

?
attachment.html

Re: Scaling Services

Robert Moss
 

Regarding a) you could try having your services managed by Apache Brooklyn
<http://brooklyn.incubator.apache.org/> it can auto- or manually-scale. I
wrote a Service Broker
<https://github.com/cloudfoundry-community/brooklyn-service-broker> and a CLI
plugin <https://github.com/cloudfoundry-community/brooklyn-plugin> that
let's you talk to Brooklyn in a CF native way.

Robert

--
Cloudsoft Corporation Limited, Registered in Scotland No: SC349230.
Registered Office: 13 Dryden Place, Edinburgh, EH9 1RP

This e-mail message is confidential and for use by the addressee only. If
the message is received by anyone other than the addressee, please return
the message to the sender by replying to it and then delete the message
from your computer. Internet e-mails are not necessarily secure. Cloudsoft
Corporation Limited does not accept responsibility for changes made to this
message after it was sent.

Whilst all reasonable care has been taken to avoid the transmission of
viruses, it is the responsibility of the recipient to ensure that the
onward transmission, opening or use of this message and any attachments
will not adversely affect its systems or data. No responsibility is
accepted by Cloudsoft Corporation Limited in this regard and the recipient
should carry out such virus and other checks as it considers appropriate.

?
attachment.html

Server error, status code: 400, error code: 170001, message: Staging error: no available stagers

iamflying
 

Hi all,

I got failure when I deployed the cf into openstack. Below is my current
findings. The DEA and CC have enough resources (4G RAM, 20G disk). Any clues
to debug? Attached debug.log. debug.log
<http://cf-dev.70369.x6.nabble.com/file/n269/debug.log>


BOSH 1.2978.0
cf version 6.10.0-b78bf10-2015-02-11T22:26:40+00:00
cf release: 207
stemcell: bosh-openstack-kvm-ubuntu-trusty-go_agent | 2969



ubuntu(a)boshclivm:~/apps/cf-php-demo$ CF_TRACE=debug.log cf push
Using manifest file /home/ubuntu/apps/cf-php-demo/manifest.yml

Creating app cf-php-demo in org system / space dev as admin...
OK

Using route cf-php-demo.runmyapp.io
Binding cf-php-demo.runmyapp.io to cf-php-demo...
OK

Uploading cf-php-demo...
Uploading app files from: /home/ubuntu/apps/cf-php-demo
Uploading 231.9K, 13 files
Done uploading
OK

Starting app cf-php-demo in org system / space dev as admin...
FAILED
Server error, status code: 400, error code: 170001, message: Staging error:
no available stagers


ubuntu(a)boshclivm:~/apps/cf-php-demo$ cf apps
Getting apps in org system / space dev as admin...
OK

name requested state instances memory disk urls
cf-php-demo started 0/1 128M 1G
cf-php-demo.cfapps.io
ubuntu(a)boshclivm:~/apps/cf-php-demo$


Additional error messages:
1. nginx.access.log
api.au.apaas.com - [03/Jun/2015:06:19:51 +0000] "PUT
/v2/apps/7b417005-6716-4d5e-bec2-246a51b588c6?async=true&inline-relations-depth=1
HTTP/1.1" 400 435 "-" "go-cli 6.10.0-b78bf10 / linux" 137.172.74.86,
100.64.1.0, 100.64.1.5
vcap_request_id:ae51df28-8371-44f2-4d18-5e13ded3a467::6faf587a-aba8-4467-8e1e-75b018eff93b
response_time:0.297

2. cloud_controller_ng.log
{"timestamp":1433313002.4425669,"message":"Request failed: 400:
{\"code\"=>170001, \"description\"=>\"Staging error: no available stagers\",
\"error_code\"=>\"CF-StagingError\",
\"backtrace\"=>[\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/lib/cloud_controller/dea/app_stager_task.rb:26:in
`stage'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/lib/cloud_controller/dea/stager.rb:45:in
`stage_app'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/lib/cloud_controller/app_observer.rb:57:in
`react_to_state_change'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/lib/cloud_controller/app_observer.rb:27:in
`updated'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/app/models/runtime/app.rb:534:in
`after_commit'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/sequel-4.21.0/lib/sequel/model/base.rb:1920:in
`block in _save'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/sequel-4.21.0/lib/sequel/database/transactions.rb:280:in
`call'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/sequel-4.21.0/lib/sequel/database/transactions.rb:280:in
`block in remove_transaction'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/sequel-4.21.0/lib/sequel/database/transactions.rb:280:in
`each'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/sequel-4.21.0/lib/sequel/database/transactions.rb:280:in
`remove_transaction'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/sequel-4.21.0/lib/sequel/database/transactions.rb:156:in
`_transaction'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/sequel-4.21.0/lib/sequel/database/transactions.rb:108:in
`block in transaction'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/sequel-4.21.0/lib/sequel/database/connecting.rb:250:in
`block in synchronize'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/sequel-4.21.0/lib/sequel/connection_pool/threaded.rb:98:in
`hold'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/sequel-4.21.0/lib/sequel/database/connecting.rb:250:in
`synchronize'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/sequel-4.21.0/lib/sequel/database/transactions.rb:97:in
`transaction'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/app/controllers/base/model_controller.rb:64:in
`update'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/app/controllers/base/base_controller.rb:76:in
`dispatch'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/lib/cloud_controller/rest_controller/routes.rb:16:in
`block in define_route'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/sinatra-1.4.5/lib/sinatra/base.rb:1602:in
`call'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/sinatra-1.4.5/lib/sinatra/base.rb:1602:in
`block in compile!'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/sinatra-1.4.5/lib/sinatra/base.rb:966:in
`[]'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/sinatra-1.4.5/lib/sinatra/base.rb:966:in
`block (3 levels) in route!'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/sinatra-1.4.5/lib/sinatra/base.rb:985:in
`route_eval'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/sinatra-1.4.5/lib/sinatra/base.rb:966:in
`block (2 levels) in route!'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/sinatra-1.4.5/lib/sinatra/base.rb:1006:in
`block in process_route'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/sinatra-1.4.5/lib/sinatra/base.rb:1004:in
`catch'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/sinatra-1.4.5/lib/sinatra/base.rb:1004:in
`process_route'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/sinatra-1.4.5/lib/sinatra/base.rb:964:in
`block in route!'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/sinatra-1.4.5/lib/sinatra/base.rb:963:in
`each'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/sinatra-1.4.5/lib/sinatra/base.rb:963:in
`route!'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/sinatra-1.4.5/lib/sinatra/base.rb:1076:in
`block in dispatch!'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/sinatra-1.4.5/lib/sinatra/base.rb:1058:in
`block in invoke'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/sinatra-1.4.5/lib/sinatra/base.rb:1058:in
`catch'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/sinatra-1.4.5/lib/sinatra/base.rb:1058:in
`invoke'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/sinatra-1.4.5/lib/sinatra/base.rb:1073:in
`dispatch!'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/sinatra-1.4.5/lib/sinatra/base.rb:898:in
`block in call!'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/sinatra-1.4.5/lib/sinatra/base.rb:1058:in
`block in invoke'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/sinatra-1.4.5/lib/sinatra/base.rb:1058:in
`catch'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/sinatra-1.4.5/lib/sinatra/base.rb:1058:in
`invoke'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/sinatra-1.4.5/lib/sinatra/base.rb:898:in
`call!'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/sinatra-1.4.5/lib/sinatra/base.rb:886:in
`call'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/rack-protection-1.5.3/lib/rack/protection/xss_header.rb:18:in
`call'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/rack-protection-1.5.3/lib/rack/protection/path_traversal.rb:16:in
`call'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/rack-protection-1.5.3/lib/rack/protection/json_csrf.rb:18:in
`call'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/rack-protection-1.5.3/lib/rack/protection/base.rb:49:in
`call'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/rack-protection-1.5.3/lib/rack/protection/base.rb:49:in
`call'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/rack-protection-1.5.3/lib/rack/protection/frame_options.rb:31:in
`call'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/rack-1.5.2/lib/rack/nulllogger.rb:9:in
`call'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/rack-1.5.2/lib/rack/head.rb:11:in
`call'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/sinatra-1.4.5/lib/sinatra/base.rb:180:in
`call'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/sinatra-1.4.5/lib/sinatra/base.rb:2014:in
`call'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/rack-1.5.2/lib/rack/builder.rb:138:in
`call'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/rack-1.5.2/lib/rack/urlmap.rb:65:in
`block in call'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/rack-1.5.2/lib/rack/urlmap.rb:50:in
`each'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/rack-1.5.2/lib/rack/urlmap.rb:50:in
`call'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/rack-1.5.2/lib/rack/builder.rb:138:in
`call'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/thin-1.6.3/lib/thin/connection.rb:86:in
`block in pre_process'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/thin-1.6.3/lib/thin/connection.rb:84:in
`catch'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/thin-1.6.3/lib/thin/connection.rb:84:in
`pre_process'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/eventmachine-1.0.3/lib/eventmachine.rb:1037:in
`call'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/eventmachine-1.0.3/lib/eventmachine.rb:1037:in
`block in
spawn_threadpool'\"]}","log_level":"info","source":"cc.api","data":{"request_guid":"d916023a-d364-492b-50bb-624e5862e455::2c136550-80cb-4d5b-8ab3-6c2dd397fc1a"},"thread_id":69941342398660,"fiber_id":69941329029340,"process_id":1816,"file":"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/lib/sinatra/vcap.rb","lineno":51,"method":"block
in registered"}










--
View this message in context: http://cf-dev.70369.x6.nabble.com/Server-error-status-code-400-error-code-170001-message-Staging-error-no-available-stagers-tp269.html
Sent from the CF Dev mailing list archive at Nabble.com.
Re: Soliciting feedback for design proposal: TCP Routing

James Bayer
 

shannon and team,

thanks to all of those that worked on this proposal thus far! so many new
workloads will be enabled by adding tcp routing for cf applications. i'm
looking forward to the community feedback.

On Tue, Jun 2, 2015 at 7:06 PM, Shannon Coen <scoen(a)pivotal.io> wrote:

Currently Cloud Foundry only supports routing of http traffic to
applications. There are many use cases, especially related to IOT, for
which applications need to receive non-http traffic.

Together with Atul Kshirsagar and Fermin Ordaz from GE, we've begun
initial work on a TCP Routing service that would enable routing of non-http
traffic to applications running on Diego in Lattice and Cloud Foundry.

Our project proposal is open for public comment and we welcome your
feedback:

https://docs.google.com/document/d/1PZE_ieAZLew6nUKIB1eaNtDWRrZt57ffqwXch0K6lVw/edit?usp=sharing

We will be requesting this project be accepted into incubation with a
Cloud Foundry Foundation PMC.

Thank you,

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

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

--
Thank you,

James Bayer

?
attachment.html

Re: Scaling Services

Alberto A. Flores
 

My 2 cents:

Your database, while it's deployed in CF, it's based on MySQL. Depending on
the configuration (YML file) you used for that release, scaling that
database is strictly based on whatever MySQL can provide. It's not CF, but
it's BOSH and the Software (in this case MySQL) that enables the "scaling"
of the software. All CF provides is the ability to connect apps to this db
service using the "service broker" model. In other words, CF does not scale
your service, but the BOSH release (e.g. cf-mysql-release) may be
configured to scale using features available in both BOSH and the software
(e.g. MySQL).

With regards to where to save "profile pictures", I've learned that the
right answer is always driven by the "access pattern" of the data. The S3
solution may work, but if you only archiving you can certainly wonder if
it's cost effective to do it that way. The docs you suggest refers to
writing data to disk as an anti-pattern. In general, CF allows to implement
patterns described in the "12 Factor App" http://12factor.net/

With regards to scaling, there are others factors you can consider. Perhaps
putting an "in-memory" store as a service to your app that can hold certain
type of data. I think there's more than one way to skin the cat.


Alberto Flores
@albertoaflores


On Tue, Jun 2, 2015 at 5:12 PM, Flávio Henrique Schuindt da Silva <
flavio.schuindt(a)gmail.com> wrote:

Hi, guys.

I'm a beginner in using CF and I successfully deployed cf-mysql-release
[1] and now I can write, read, etc from the database as a service bound in
my application.

Now, I have some questions and it would be really great if someone could
help me.

a) Ok, I have a database that works and its great. Imagine a scenario that
a lot of clients are acessing my app and now I have to scale. How CF scale
the service? I mean there must be some way to give more nodes on the maria
db cluster provided by [1], right?

b) If I need to save profile pictures to a user table. What should I do?
Save it as blob in the database since write data to disk is not recommended
by cf docs because apps are isolated each other in the DEA.

Thank you very much for your patient and time.

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

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

?
attachment.html

Soliciting feedback for design proposal: TCP Routing

Shannon Coen
 

Currently Cloud Foundry only supports routing of http traffic to
applications. There are many use cases, especially related to IOT, for
which applications need to receive non-http traffic.

Together with Atul Kshirsagar and Fermin Ordaz from GE, we've begun initial
work on a TCP Routing service that would enable routing of non-http traffic
to applications running on Diego in Lattice and Cloud Foundry.

Our project proposal is open for public comment and we welcome your
feedback:
https://docs.google.com/document/d/1PZE_ieAZLew6nUKIB1eaNtDWRrZt57ffqwXch0K6lVw/edit?usp=sharing

We will be requesting this project be accepted into incubation with a Cloud
Foundry Foundation PMC.

Thank you,

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

?
attachment.html

Re: Scaling Services

Matt Cowger
 

I can't speak to a), but the general pattern for b) would be to store the
actual blob data into an object store of some sort (whether public like AWS
S3 or Azure, etc, or on a private service like Scality, EMC ECS, or
Cleversafe), and then simply store the URL / ID for that photo into the
database.

On Tue, Jun 2, 2015 at 2:12 PM, Flávio Henrique Schuindt da Silva <
flavio.schuindt(a)gmail.com> wrote:

Hi, guys.

I'm a beginner in using CF and I successfully deployed cf-mysql-release
[1] and now I can write, read, etc from the database as a service bound in
my application.

Now, I have some questions and it would be really great if someone could
help me.

a) Ok, I have a database that works and its great. Imagine a scenario that
a lot of clients are acessing my app and now I have to scale. How CF scale
the service? I mean there must be some way to give more nodes on the maria
db cluster provided by [1], right?

b) If I need to save profile pictures to a user table. What should I do?
Save it as blob in the database since write data to disk is not recommended
by cf docs because apps are isolated each other in the DEA.

Thank you very much for your patient and time.

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

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


--
-- Matt

?
attachment.html

Scaling Services

Flávio Henrique Schuindt da Silva <flavio.schuindt at gmail.com...>
 

Hi, guys.

I'm a beginner in using CF and I successfully deployed cf-mysql-release [1]
and now I can write, read, etc from the database as a service bound in my
application.

Now, I have some questions and it would be really great if someone could
help me.

a) Ok, I have a database that works and its great. Imagine a scenario that
a lot of clients are acessing my app and now I have to scale. How CF scale
the service? I mean there must be some way to give more nodes on the maria
db cluster provided by [1], right?

b) If I need to save profile pictures to a user table. What should I do?
Save it as blob in the database since write data to disk is not recommended
by cf docs because apps are isolated each other in the DEA.

Thank you very much for your patient and time.

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

?
attachment.html

Utilities PMC - 2015-06-02 notes

Mike Dalessio
 

Hi all,

We had a meeting of the Utilities PMC today, permanent notes are at:

https://github.com/cloudfoundry/pmc-notes/blob/master/Utilities/2015-06-02-utilities.md

which I've helpfully copied into this email below.

Cheers!
-mike


-----

*# Utilities PMC Meeting 2015-05-19*

*## Agenda*

1. Update on CI tools (Mike Dalessio)
2. Update on CLI (Greg Oehmen)
3. Update on Eclipse plugin and Java tools (Ryan Morgan)
4. Open Discussion


*## Attendees*

* Chip Childers, Cloud Foundry Foundation
* Mike Dalessio, Pivotal (PMC lead)
* Ryan Morgan, Pivotal
* Steve Winkler, GE
* Gert Drapers, HP
* Matt Sykes, IBM
* Michael Fraenkel, IBM


*## Update on CI tools (Mike Dalessio)*

- The Toolsmiths team will be shutting down the OSS GoCD pipeline,
which was only servicing the CLI team (and they are moving to
Concourse).

- The Buildpacks team has moved to concourse, and will be
open-sourcing their pipeline configurations once the environment has
been secured and it's not leaking credentials

- The Concourse team has started to put together some security
recommendations for setting up a secure Concourse deployment, with
particular attention to AWS configuration.



*## Update on CLI (Greg Oehman)*

* Ongoing work on service keys with Services team
* Finishing last details of Concourse migration
* Ongoing work on Plugin API (vetted plan/implementation with community at
CF Summit CLI Open House - great experience)
* Reviving `cfhelp` refactoring work with Mike Long, IBM Designers. Will
be next feature after Plugin API


*## Update on Eclipse plugin and Java tools (Ryan Morgan)*

* Work on 1.8.3 progressing, mostly bug fixes.
* Completed a spike on Debugging a Java application via SSH. Requires
Diego and currently only works in bosh-lite. Will be included in 1.8.3.
Story for this feature: https://www.pivotaltracker.com/story/show/94617426.


*## Open Discussion*

Nothing additional was discussed.

?
attachment.html

Soliciting feedback on feature proposal: User-managed Service Brokers

Shannon Coen
 

Currently registration of service brokers is an admin-only function in
Cloud Foundry. We've heard users and operators ask for a feature that would
enable broker authors to register their own service brokers, as this will
remove barriers to development of service brokers and add support for
self-service marketplace catalog management for application developers.

Our proposal is open for public comment:
https://docs.google.com/document/d/1azArNcDtOjiq5wHx0BCS3OABfJf1PufPmc0OqfkFq7c/edit?usp=sharing

I've also linked to it from the cloudfoundry-community design docs page:
https://github.com/cloudfoundry-community/cf-docs-contrib/wiki/Design-Documents

If this feature is of interest to you, please review our proposal and give
us feedback by commenting in the doc. The Services API team will likely
begin working on the feature next week.

Thank you,

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

?
attachment.html

Compatibility with Amazon RDS for Aurora

Mike Youngstrom <youngm@...>
 

Has anyone run the cloud controller and/or uaa against Aurora? Any issues?

Mike

?
attachment.html

Re: sporadic connection resets between login and uaa

Filip Hanik
 

hi Jan, yes you are correct. And even in the old configuration, a
connection reset is a network issue, so you would have to see who initiated
the the reset (TCP RST package). Most likely the IP that hosts uaa.<domain>
- the load balancer?

On Tue, Jun 2, 2015 at 10:25 AM, Sievers, Jan <jan.sievers(a)sap.com> wrote:

Am I right this problem is obsolete since the login-uaa merge in CF 208
[1]?

Regards,
Jan

[1] http://lists.cloudfoundry.org/pipermail/cf-dev/2015-May/000087.html

-----Original Message-----
From: Sievers, Jan
Sent: Montag, 1. Juni 2015 11:31
To: 'cf-dev(a)lists.cloudfoundry.org'
Subject: sporadic connection resets between login and uaa

Hi,

while running the CF 207 smoke and acceptance tests repeatedly, we
noticed
sporadic connection resets during 'cf login'
(see log snippet from login log below).

The connection reset is happening on the login machine when it's doing an
HTTP POST to

http://uaa.cf.<DOMAIN>/authenticate

(via load balancer, and getting a connection reset from the load
balancer).
This is happening ~ 1 out of 5 times if we run the smoke tests every 5
minutes.

We found that adding

-Dhttp.keepAlive=false

to JAVA_OPTS in /var/vcap/jobs/login/bin/login_ctl

works around the problem. Otherwise, by default there is a pool of 5
connections being kept alive and reused.

We use an F5 BigIP load balancer with 300 seconds socket idle timeout
configured.

Could this be a bug with stale connections being reused by the HTTP
client on
the login machine?

Best Regards,
Jan


--- log snippet from login machine ---

[2015-05-08 08:07:52.787] login - 9054 [http-bio-8080-exec-2] .... DEBUG
---
DispatcherServlet: DispatcherServlet with name 'spring' processing POST
request for [/error500]
[2015-05-08 08:07:52.787] login - 9054 [http-bio-8080-exec-2] .... DEBUG
---
RequestMappingHandlerMapping: Looking up handler method for path
/error500
[2015-05-08 08:07:52.787] login - 9054 [http-bio-8080-exec-2] .... DEBUG
---
RequestMappingHandlerMapping: Returning handler method [public
java.lang.String
org.cloudfoundry.identity.uaa.login.HomeController.error500(org.springframewo
rk.ui.Model,javax.servlet.http.HttpServletRequest)]
[2015-05-08 08:07:52.787] login - 9054 [http-bio-8080-exec-2] .... ERROR
---
HomeController: Internal error
org.springframework.web.client.ResourceAccessException: I/O error on POST
request for "http://uaa.cf.<DOMAIN>/authenticate":Connection reset;
nested
exception is java.net.SocketException: Connection reset
at
org.springframework.web.client.RestTemplate.doExecute(RestTemplate.java:567)
at
org.springframework.security.oauth2.client.OAuth2RestTemplate.doExecute(OAuth
2RestTemplate.java:128)
at
org.springframework.web.client.RestTemplate.execute(RestTemplate.java:512)
at
org.springframework.web.client.RestTemplate.exchange(RestTemplate.java:454)
at
org.cloudfoundry.identity.uaa.login.RemoteUaaAuthenticationManager.authentica
te(RemoteUaaAuthenticationManager.java:137)
at
org.cloudfoundry.identity.uaa.authentication.AuthzAuthenticationFilter.doFilt
er(AuthzAuthenticationFilter.java:138)
at
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter
(FilterChainProxy.java:342)
at
org.springframework.security.web.context.request.async.WebAsyncManagerIntegra
tionFilter.doFilterInternal(WebAsyncManagerIntegrationFilter.java:50)
at
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFi
lter.java:107)
at
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter
(FilterChainProxy.java:342)
at
org.springframework.security.web.context.SecurityContextPersistenceFilter.doF
ilter(SecurityContextPersistenceFilter.java:87)
at
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter
(FilterChainProxy.java:342)
at
org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChai
nProxy.java:192)
at
org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.j
ava:160)
at
org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(Delegatin
gFilterProxy.java:344)
at
org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilte
rProxy.java:261)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationF
ilterChain.java:241)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCha
in.java:208)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.jav
a:220)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.jav
a:122)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.
java:501)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:950)
at
org.apache.catalina.valves.RemoteIpValve.invoke(RemoteIpValve.java:683)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:
116)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:
116) [37/1995]
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408)
at
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Proces
sor.java:1070)
at
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(Abstract
Protocol.java:611)
at
org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:3
14)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:114
5)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:61
5)
at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.jav
a:61)
at java.lang.Thread.run(Thread.java:744)
Caused by: java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(SocketInputStream.java:196)
at java.net.SocketInputStream.read(SocketInputStream.java:122)
at
org.apache.http.impl.io.SessionInputBufferImpl.streamRead(SessionInputBufferI
mpl.java:136)
at
org.apache.http.impl.io.SessionInputBufferImpl.fillBuffer(SessionInputBufferI
mpl.java:152)
at
org.apache.http.impl.io.SessionInputBufferImpl.readLine(SessionInputBufferImp
l.java:270)
at
org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResp
onseParser.java:140)
at
org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResp
onseParser.java:57)
at
org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.jav
a:260)
at
org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(Defau
ltBHttpClientConnection.java:161)
at sun.reflect.GeneratedMethodAccessor121.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.
java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.apache.http.impl.conn.CPoolProxy.invoke(CPoolProxy.java:138)
at com.sun.proxy.$Proxy45.receiveResponseHeader(Unknown Source)
at
org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExe
cutor.java:271)
at
org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java
:123)
at
org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:254
)
at
org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:195)
at
org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:86)
at
org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:108)
at
org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.j
ava:186)
at
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.j
ava:82)
at
org.springframework.http.client.HttpComponentsClientHttpRequest.executeIntern
al(HttpComponentsClientHttpRequest.java:91)
at
org.springframework.http.client.AbstractBufferingClientHttpRequest.executeInt
ernal(AbstractBufferingClientHttpRequest.java:48)
at
org.springframework.http.client.AbstractClientHttpRequest.execute(AbstractCli
entHttpRequest.java:53)
at
org.springframework.web.client.RestTemplate.doExecute(RestTemplate.java:551)
... 33 more
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

?
attachment.html

Re: What ports will be needed to support hm and loggregator

Lev Berman <lev.berman@...>
 

Sorry, I've missed your notes about the firewalls you configure for each CF
machine - this firewalls is what needs to be configured to accept UDP
traffic to ports 3456 and 3457 from any host. vSphere itself will probably
allow this traffic without any additional configuration.

On Tue, Jun 2, 2015 at 1:51 PM, Berman Lev <lev.berman(a)altoros.com> wrote:

I have never worked with vSphere, unfortunately. I've googled a bit and
found this table which shows which TCP and UDP ports are open by default on
vSphere VMs -
https://pubs.vmware.com/vsphere-55/index.jsp#com.vmware.vsphere.security.doc/GUID-ECEA77F5-D38E-4339-9B06-FF9B78E94B68.html.
Consult the vSphere documentation to find out how to add UDP 3456 and 3457
ports to this list.

On Tue, Jun 2, 2015 at 1:32 PM, Meng, Xiangyi <xiangyi.meng(a)emc.com>
wrote:

I deployed my CF on vshpere server.



*From:* cf-dev-bounces(a)lists.cloudfoundry.org [mailto:
cf-dev-bounces(a)lists.cloudfoundry.org] *On Behalf Of *Lev Berman
*Sent:* 2015年6月2日 18:30

*To:* Discussions about Cloud Foundry projects and the system overall.
*Subject:* Re: [cf-dev] What ports will be needed to support hm and
loggregator



You have posted your Application Security Groups -
http://docs.pivotal.io/pivotalcf/adminguide/app-sec-groups.html. This
groups are created and managed by Cloud Foundry.

But the issue here is with security groups configured in your
infrastructure - AWS, OpenStack, etc. Which one is your CF deployed on?



On Tue, Jun 2, 2015 at 1:23 PM, Meng, Xiangyi <xiangyi.meng(a)emc.com>
wrote:

Hi, Lev



Would you please let me know what exactly I should add to my security
group? Following are the current configuration.



- name: public_networks

rules:

- protocol: all

destination: 0.0.0.0-9.255.255.255

- protocol: all

destination: 11.0.0.0-169.253.255.255

- protocol: all

destination: 169.255.0.0-172.15.255.255

- protocol: all

destination: 172.32.0.0-192.167.255.255

- protocol: all

destination: 192.169.0.0-255.255.255.255

- name: dns

rules:

- protocol: tcp

destination: 0.0.0.0/0

ports: '53'

- protocol: udp

destination: 0.0.0.0/0

ports: '53'

default_running_security_groups:

- public_networks

- dns

default_staging_security_groups:

- public_networks

- dns



Thanks,

Maggie



*From:* cf-dev-bounces(a)lists.cloudfoundry.org [mailto:
cf-dev-bounces(a)lists.cloudfoundry.org] *On Behalf Of *Lev Berman
*Sent:* 2015年6月2日 18:16
*To:* Discussions about Cloud Foundry projects and the system overall.
*Subject:* Re: [cf-dev] What ports will be needed to support hm and
loggregator



Hi,

At least for loggregator to successflly talk to metron agents, you need
to add a rule to a security group for your private subnet allowing the
ingress UDP traffic through ports 3456 and 3457 from all hosts (0.0.0.0/0).
See more about security group rules needed for CF here -
http://docs.cloudfoundry.org/deploying/common/security_groups.html.





On Tue, Jun 2, 2015 at 1:04 PM, Meng, Xiangyi <xiangyi.meng(a)emc.com>
wrote:

Hi,



I am updating my cf env from 172 to 197. But I found some issues after
upgrade is done. I couldn’t get the correct running application instance
number:



CF_TRACE=true cf apps

…

"running_instances": -1,

…

application started ?/3



Another issue is I can’t get log information from loggregator. “cf logs”
showed nothing after I restarted my application.



I think this may be related to our firewall configuration. Because in
another environment where no firewall is configured, hm and loggregator
work perfectly well. We have firewalls for deas, routers and all other
components separately(three firewalls). So would anyone please tell me what
ports we should open for deas, routers or other components?



Thanks,

Maggie





--

Lev Berman

Altoros - Cloud Foundry deployment, training and integration



Github*: *https://github.com/ldmberman





--

Lev Berman

Altoros - Cloud Foundry deployment, training and integration



Github*: *https://github.com/ldmberman


--
Lev Berman

Altoros - Cloud Foundry deployment, training and integration

Github
*: https://github.com/ldmberman <https://github.com/ldmberman> *
--
Lev Berman

Altoros - Cloud Foundry deployment, training and integration

Github
*: https://github.com/ldmberman <https://github.com/ldmberman>*

?
attachment.html

Re: What ports will be needed to support hm and loggregator

Lev Berman <ldmberman@...>
 

Sorry, I've missed your notes about the firewalls you configure for each CF
machine - this firewalls is what needs to be configured to accept UDP
traffic to ports 3456 and 3457 from any host. vSphere itself will probably
allow this traffic without any additional configuration.

On Tue, Jun 2, 2015 at 1:51 PM, Berman Lev <lev.berman(a)altoros.com> wrote:

I have never worked with vSphere, unfortunately. I've googled a bit and
found this table which shows which TCP and UDP ports are open by default on
vSphere VMs -
https://pubs.vmware.com/vsphere-55/index.jsp#com.vmware.vsphere.security.doc/GUID-ECEA77F5-D38E-4339-9B06-FF9B78E94B68.html.
Consult the vSphere documentation to find out how to add UDP 3456 and 3457
ports to this list.

On Tue, Jun 2, 2015 at 1:32 PM, Meng, Xiangyi <xiangyi.meng(a)emc.com>
wrote:

I deployed my CF on vshpere server.



*From:* cf-dev-bounces(a)lists.cloudfoundry.org [mailto:
cf-dev-bounces(a)lists.cloudfoundry.org] *On Behalf Of *Lev Berman
*Sent:* 2015年6月2日 18:30

*To:* Discussions about Cloud Foundry projects and the system overall.
*Subject:* Re: [cf-dev] What ports will be needed to support hm and
loggregator



You have posted your Application Security Groups -
http://docs.pivotal.io/pivotalcf/adminguide/app-sec-groups.html. This
groups are created and managed by Cloud Foundry.

But the issue here is with security groups configured in your
infrastructure - AWS, OpenStack, etc. Which one is your CF deployed on?



On Tue, Jun 2, 2015 at 1:23 PM, Meng, Xiangyi <xiangyi.meng(a)emc.com>
wrote:

Hi, Lev



Would you please let me know what exactly I should add to my security
group? Following are the current configuration.



- name: public_networks

rules:

- protocol: all

destination: 0.0.0.0-9.255.255.255

- protocol: all

destination: 11.0.0.0-169.253.255.255

- protocol: all

destination: 169.255.0.0-172.15.255.255

- protocol: all

destination: 172.32.0.0-192.167.255.255

- protocol: all

destination: 192.169.0.0-255.255.255.255

- name: dns

rules:

- protocol: tcp

destination: 0.0.0.0/0

ports: '53'

- protocol: udp

destination: 0.0.0.0/0

ports: '53'

default_running_security_groups:

- public_networks

- dns

default_staging_security_groups:

- public_networks

- dns



Thanks,

Maggie



*From:* cf-dev-bounces(a)lists.cloudfoundry.org [mailto:
cf-dev-bounces(a)lists.cloudfoundry.org] *On Behalf Of *Lev Berman
*Sent:* 2015年6月2日 18:16
*To:* Discussions about Cloud Foundry projects and the system overall.
*Subject:* Re: [cf-dev] What ports will be needed to support hm and
loggregator



Hi,

At least for loggregator to successflly talk to metron agents, you need
to add a rule to a security group for your private subnet allowing the
ingress UDP traffic through ports 3456 and 3457 from all hosts (0.0.0.0/0).
See more about security group rules needed for CF here -
http://docs.cloudfoundry.org/deploying/common/security_groups.html.





On Tue, Jun 2, 2015 at 1:04 PM, Meng, Xiangyi <xiangyi.meng(a)emc.com>
wrote:

Hi,



I am updating my cf env from 172 to 197. But I found some issues after
upgrade is done. I couldn’t get the correct running application instance
number:



CF_TRACE=true cf apps

…

"running_instances": -1,

…

application started ?/3



Another issue is I can’t get log information from loggregator. “cf logs”
showed nothing after I restarted my application.



I think this may be related to our firewall configuration. Because in
another environment where no firewall is configured, hm and loggregator
work perfectly well. We have firewalls for deas, routers and all other
components separately(three firewalls). So would anyone please tell me what
ports we should open for deas, routers or other components?



Thanks,

Maggie





--

Lev Berman

Altoros - Cloud Foundry deployment, training and integration



Github*: *https://github.com/ldmberman





--

Lev Berman

Altoros - Cloud Foundry deployment, training and integration



Github*: *https://github.com/ldmberman


--
Lev Berman

Altoros - Cloud Foundry deployment, training and integration

Github
*: https://github.com/ldmberman <https://github.com/ldmberman> *

?
attachment.html

Re: What ports will be needed to support hm and loggregator

Lev Berman <lev.berman@...>
 

I have never worked with vSphere, unfortunately. I've googled a bit and
found this table which shows which TCP and UDP ports are open by default on
vSphere VMs -
https://pubs.vmware.com/vsphere-55/index.jsp#com.vmware.vsphere.security.doc/GUID-ECEA77F5-D38E-4339-9B06-FF9B78E94B68.html.
Consult the vSphere documentation to find out how to add UDP 3456 and 3457
ports to this list.

On Tue, Jun 2, 2015 at 1:32 PM, Meng, Xiangyi <xiangyi.meng(a)emc.com> wrote:

I deployed my CF on vshpere server.



*From:* cf-dev-bounces(a)lists.cloudfoundry.org [mailto:
cf-dev-bounces(a)lists.cloudfoundry.org] *On Behalf Of *Lev Berman
*Sent:* 2015年6月2日 18:30

*To:* Discussions about Cloud Foundry projects and the system overall.
*Subject:* Re: [cf-dev] What ports will be needed to support hm and
loggregator



You have posted your Application Security Groups -
http://docs.pivotal.io/pivotalcf/adminguide/app-sec-groups.html. This
groups are created and managed by Cloud Foundry.

But the issue here is with security groups configured in your
infrastructure - AWS, OpenStack, etc. Which one is your CF deployed on?



On Tue, Jun 2, 2015 at 1:23 PM, Meng, Xiangyi <xiangyi.meng(a)emc.com>
wrote:

Hi, Lev



Would you please let me know what exactly I should add to my security
group? Following are the current configuration.



- name: public_networks

rules:

- protocol: all

destination: 0.0.0.0-9.255.255.255

- protocol: all

destination: 11.0.0.0-169.253.255.255

- protocol: all

destination: 169.255.0.0-172.15.255.255

- protocol: all

destination: 172.32.0.0-192.167.255.255

- protocol: all

destination: 192.169.0.0-255.255.255.255

- name: dns

rules:

- protocol: tcp

destination: 0.0.0.0/0

ports: '53'

- protocol: udp

destination: 0.0.0.0/0

ports: '53'

default_running_security_groups:

- public_networks

- dns

default_staging_security_groups:

- public_networks

- dns



Thanks,

Maggie



*From:* cf-dev-bounces(a)lists.cloudfoundry.org [mailto:
cf-dev-bounces(a)lists.cloudfoundry.org] *On Behalf Of *Lev Berman
*Sent:* 2015年6月2日 18:16
*To:* Discussions about Cloud Foundry projects and the system overall.
*Subject:* Re: [cf-dev] What ports will be needed to support hm and
loggregator



Hi,

At least for loggregator to successflly talk to metron agents, you need to
add a rule to a security group for your private subnet allowing the ingress
UDP traffic through ports 3456 and 3457 from all hosts (0.0.0.0/0). See
more about security group rules needed for CF here -
http://docs.cloudfoundry.org/deploying/common/security_groups.html.





On Tue, Jun 2, 2015 at 1:04 PM, Meng, Xiangyi <xiangyi.meng(a)emc.com>
wrote:

Hi,



I am updating my cf env from 172 to 197. But I found some issues after
upgrade is done. I couldn’t get the correct running application instance
number:



CF_TRACE=true cf apps

…

"running_instances": -1,

…

application started ?/3



Another issue is I can’t get log information from loggregator. “cf logs”
showed nothing after I restarted my application.



I think this may be related to our firewall configuration. Because in
another environment where no firewall is configured, hm and loggregator
work perfectly well. We have firewalls for deas, routers and all other
components separately(three firewalls). So would anyone please tell me what
ports we should open for deas, routers or other components?



Thanks,

Maggie





--

Lev Berman

Altoros - Cloud Foundry deployment, training and integration



Github*: *https://github.com/ldmberman





--

Lev Berman

Altoros - Cloud Foundry deployment, training and integration



Github*: *https://github.com/ldmberman
--
Lev Berman

Altoros - Cloud Foundry deployment, training and integration

Github
*: https://github.com/ldmberman <https://github.com/ldmberman>*

?
attachment.html

9121 - 9140 of 9429