Date   

Re: CF push error - Not able to resolve - Error dialing loggregator server: Get https://loggregator.systemdomain.com

Ronak Agarwal <roagarwa@...>
 

Its a fresh install.

I found few logs may be helpful to resolve this issue --

I found few logs on cloud_controller_ng as below -

Nodejs buildpack install fail :-
{"timestamp":1438583731.044699,"message":"Buildpack nodejs_buildpack
failed to install or update. Error:
#","log_level":"error","source":"cc.background","data":{},"thread_id":70305412338480,"fiber_id":70305448717440,"process_id":4360,"file":"/var/vcap/data/packages/cloud_controller_ng/a60643ffa860f4f065c25b6b99687b9d55067757.1-0e8fbd36253d4107c466281136ad267d0660bc51/cloud_controller_ng/app/jobs/runtime/buildpack_installer.rb","lineno":38,"method":"rescue
in perform"} {"timestamp":1438583731.045526,"message":"Request failed:
500: {\"code\"=>10001, \"description\"=>\"connect timeout reached\",
\"error_code\"=>\"CF-Timeout\",
------------------------------------------ -> Fails at
nodejs_buildpack-cached-v1.4.0.zip

"log_level":"error","source":"cc.background","data":{},"thread_id":70305412338480,"fiber_id":70305448717440,"process_id":4360,"file":"/var/vcap/data/packages/cloud_controller_ng/a60643ffa860f4f065c25b6b99687b9d55067757.1-0e8fbd36253d4107c466281136ad267d0660bc51/cloud_controller_ng/app/jobs/exception_catching_job.rb","lineno":24,"method":"log_error"}
{"timestamp":1438583731.0496318,"message":"(0.001478s) UPDATE
delayed_jobs SET guid = '82d9ebe1-7af0-4671-89a5-30146a5bb554',
created_at = '2015-08-03 06:27:26', updated_at = CURRENT_TIMESTAMP,
priority = 0, attempts = 0, handler = '---
!ruby/object:VCAP::CloudController::Jobs::ExceptionCatchingJob\nhandler:
!ruby/object:VCAP::CloudController::Jobs::RequestJob\n handler:
!ruby/object:VCAP::CloudController::Jobs::TimeoutJob\n handler:
!ruby/object:VCAP::CloudController::Jobs::Runtime::BuildpackInstaller\n
name: nodejs_buildpack\n file:
\\"/var/vcap/packages/buildpack_nodejs/nodejs_buildpack-cached-v1.4.0.zip\\"\n
opts: {}\n request_id: \n', last_error = NULL, run_at = '2015-08-03
06:27:26', locked_at = '2015-08-03 06:31:30',failed_at = NULL,
locked_by = 'cc_api_worker.api_z1.0.1', queue = 'cc-api_z1-0',
cf_api_error = '---\nerror_code: UnknownError\ndescription: An unknown
error occurred.\ncode: 10001\n' WHERE (id = 971) LIMIT
1","log_level":"debug2","source":"cc.background","data":{},"thread_id":70305412338480,"fiber_id":70305448717440,"process_id":4360,"file":"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/sequel-4.21.0/lib/sequel/database/logging.rb","lineno":70,"method":"block
in log_each"}

________________________________

go_buildpack failed to install

{"timestamp":1438583970.3534014,"message":"Buildpack go_buildpack
failed to install or update. Error:
#","log_level":"error","source":"cc.background","data":{},"thread_id":70006300463920,"fiber_id":70006336842960,"process_id":4397,"file":"/var/vcap/data/packages/cloud_controller_ng/a60643ffa860f4f065c25b6b99687b9d55067757.1-0e8fbd36253d4107c466281136ad267d0660bc51/cloud_controller_ng/app/jobs/runtime/buildpack_installer.rb","lineno":38,"method":"rescue
in perform"}
{"timestamp":1438583970.3541129,"message":"Request failed: 500:
{\"code\"=>10001, \"description\"=>\"connect timeout reached\",
\"error_code\"=>\"CF-Timeout\",
\"backtrace\"=>[\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/excon-0.44.1/lib/excon/socket.rb:135:in
rescue in block in connect'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/excon-0.44.1/lib/excon/socket.rb:114:inblock
in connect'\"

________________________________

->go_buildpack-cached-v1.4.0.zip
,
"log_level":"error","source":"cc.background","data":{},"thread_id":70006300463920,"fiber_id":70006336842960,"process_id":4397,"file":"/var/vcap/data/packages/cloud_controller_ng/a60643ffa860f4f065c25b6b99687b9d55067757.1-0e8fbd36253d4107c466281136ad267d0660bc51/cloud_controller_ng/app/jobs/exception_catching_job.rb","lineno":24,"method":"log_error"}
{"timestamp":1438583970.358118,"message":"(0.001543s) UPDATE
delayed_jobs SET guid = 'd559d276-c5a2-471c-aca1-ba25f4e9cd97',
created_at = '2015-08-03 06:27:26', updated_at = CURRENT_TIMESTAMP,
priority = 0, attempts = 0, handler = '---
!ruby/object:VCAP::CloudController::Jobs::ExceptionCatchingJob\nhandler:
!ruby/object:VCAP::CloudController::Jobs::RequestJob\n handler:
!ruby/object:VCAP::CloudController::Jobs::TimeoutJob\n handler:
!ruby/object:VCAP::CloudController::Jobs::Runtime::BuildpackInstaller\n
name: go_buildpack\n file:
\\"/var/vcap/packages/buildpack_go/go_buildpack-cached-v1.4.0.zip\\"\n
opts: {}\n request_id: \n',last_error = NULL, run_at = '2015-08-03
06:27:26', locked_at = '2015-08-03 06:35:29', failed_at = NULL,
locked_by = 'cc_api_worker.api_z1.0.2', queue = 'cc-api_z1-0',
cf_api_error = '---\nerror_code: UnknownError\ndescription: An unknown
error occurred.\ncode: 10001\n' WHERE (id = 972) LIMIT
1","log_level":"debug2","source":"cc.background","data":{},"thread_id":70006300463920,"fiber_id":70006336842960,"process_id":4397,"file":"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/sequel-4.21.0/lib/sequel/database/logging.rb","lineno":70,"method":"block
in log_each"}

________________________________

python_buildpack failed to install

{"timestamp":1438583971.811825,"message":"Buildpack python_buildpack
failed to install or update. Error:
#","log_level":"error","source":"cc.background","data":{},"thread_id":70305412338480,"fiber_id":70305448717440,"process_id":4360,"file":"/var/vcap/data/packages/cloud_controller_ng/a60643ffa860f4f065c25b6b99687b9d55067757.1-0e8fbd36253d4107c466281136ad267d0660bc51/cloud_controller_ng/app/jobs/runtime/buildpack_installer.rb","lineno":38,"method":"rescue
in perform"}
{"timestamp":1438583971.8125288,"message":"Request failed: 500:
{\"code\"=>10001, \"description\"=>\"connect timeout reached\",
\"error_code\"=>\"CF-Timeout\",
\"backtrace\"=>[\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/excon-0.44.1/lib/excon/socket.rb:135:in
rescue in block in connect'\",
\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/excon-0.44.1/lib/excon/socket.rb:114:inblock
in connect'\",

________________________________

->python_buildpack-cached-v1.4.0.zip

,"log_level":"error","source":"cc.background","data":{},"thread_id":70305412338480,"fiber_id":70305448717440,"process_id":4360,"file":"/var/vcap/data/packages/cloud_controller_ng/a60643ffa860f4f065c25b6b99687b9d55067757.1-0e8fbd36253d4107c466281136ad267d0660bc51/cloud_controller_ng/app/jobs/exception_catching_job.rb","lineno":24,"method":"log_error"}

{"timestamp":1438583971.8163912,"message":"(0.001414s) UPDATE
delayed_jobs SET guid = '37f04f8f-2e1e-4096-8f5f-c10d8180a9fc',
created_at = '2015-08-03 06:27:26', updated_at = CURRENT_TIMESTAMP,
priority = 0, attempts = 0,handler = '---
!ruby/object:VCAP::CloudController::Jobs::ExceptionCatchingJob\nhandler:
!ruby/object:VCAP::CloudController::Jobs::RequestJob\n handler:
!ruby/object:VCAP::CloudController::Jobs::TimeoutJob\n handler:
!ruby/object:VCAP::CloudController::Jobs::Runtime::BuildpackInstaller\n
name: python_buildpack\n file:
\\"/var/vcap/packages/buildpack_python/python_buildpack-cached-v1.4.0.zip\\"\n
opts: {}\n request_id: \n',last_error = NULL, run_at = '2015-08-03
06:27:26',locked_at = '2015-08-03 06:35:31', failed_at =
NULL,locked_by = 'cc_api_worker.api_z1.0.1', queue = 'cc-api_z1-0',
cf_api_error = '---\nerror_code: UnknownError\ndescription: An unknown
error occurred.\ncode: 10001\n' WHERE (id = 973) LIMIT
1","log_level":"debug2","source":"cc.background","data":{},"thread_id":70305412338480,"fiber_id":7030

php_buildpack failed to install

{"timestamp":1438584211.920127,"message":"Buildpack php_buildpack
failed to install or update. Error:
#","log_level":"error","source":"cc.background","data":{},"thread_id":70006300463920,"fiber_id":70006336842960,"process_id":4397,"file":"/var/vcap/data/packages/cloud_controller_ng/a60643ffa860f4f065c25b6b99687b9d55067757.1-0e8fbd36253d4107c466281136ad267d0660bc51/cloud_controller_ng/app/jobs/runtime/buildpack_installer.rb","lineno":38,"method":"rescue
in perform"}

________________________________

->php_buildpack-cached-v3.3.0.zip

{"timestamp":1438584211.9250205,"message":"(0.001442s) UPDATE
delayed_jobs SET guid = '133a41bd-307f-4e2b-b70e-635f3dec60c4',
created_at = '2015-08-03 06:27:26', updated_at = CURRENT_TIMESTAMP,
priority = 0, attempts = 0, handler = '---
!ruby/object:VCAP::CloudController::Jobs::ExceptionCatchingJob\nhandler:
!ruby/object:VCAP::CloudController::Jobs::RequestJob\n handler:
!ruby/object:VCAP::CloudController::Jobs::TimeoutJob\n handler:
!ruby/object:VCAP::CloudController::Jobs::Runtime::BuildpackInstaller\n
name: php_buildpack\n file:
\\"/var/vcap/packages/buildpack_php/php_buildpack-cached-v3.3.0.zip\\"\n
opts: {}\n request_id: \n',last_error = NULL, run_at = '2015-08-03
06:27:26', locked_at = '2015-08-03 06:39:30', failed_at = NULL,
locked_by = 'cc_api_worker.api_z1.0.2', queue = 'cc-api_z1-0',
cf_api_error = '---\nerror_code: UnknownError\ndescription: An unknown
error occurred.\ncode: 10001\n' WHERE (id = 974) LIMIT
1","log_level":"debug2","source":"cc.background","data":{},"thread_id":70006300463920,"fiber_id":70006336842960,"process_id":4397,

________________________________

binary_buildpack failed to install

{"timestamp":1438584212.2200441,"message":"Buildpack binary_buildpack
failed to install or update. Error:
#","log_level":"error","source":"cc.background","data":{},"thread_id":70305412338480,"fiber_id":70305448717440,"process_id":4360,"file":"/var/vcap/data/packages/cloud_controller_ng/a60643ffa860f4f065c25b6b99687b9d55067757.1-0e8fbd36253d4107c466281136ad267d0660bc51/cloud_controller_ng/app/jobs/runtime/buildpack_installer.rb","lineno":38,"method":"rescue
in perform"}

________________________________

->binary_buildpack-cached-v1.0.1.zip

{"timestamp":1438584212.2245483,"message":"(0.001381s) UPDATE
delayed_jobs SET guid = '7ea6156e-024c-4f2d-b574-ca9b218470cd',
created_at = '2015-08-03 06:27:26', updated_at = CURRENT_TIMESTAMP,
priority = 0, attempts = 0, handler = '---
!ruby/object:VCAP::CloudController::Jobs::ExceptionCatchingJob\nhandler:
!ruby/object:VCAP::CloudController::Jobs::RequestJob\n handler:
!ruby/object:VCAP::CloudController::Jobs::TimeoutJob\n handler:
!ruby/object:VCAP::CloudController::Jobs::Runtime::BuildpackInstaller\n
name: binary_buildpack\n file:
\\"/var/vcap/packages/buildpack_binary/binary_buildpack-cached-v1.0.1.zip\\"\n
opts: {}\n request_id: \n',last_error = NULL, run_at = '2015-08-03
06:27:26', locked_at = '2015-08-03 06:39:31', failed_at = NULL,
locked_by = 'cc_api_worker.api_z1.0.1', queue = 'cc-api_z1-0',
cf_api_error = '---\nerror_code: UnknownError\ndescription: An unknown
error occurred.\ncode: 10001\n' WHERE (id = 975) LIMIT
1","log_level":"debug2","source":"cc.background","data":{},"thread_id":70305412338480,"fiber_id":70305448717440,"process_id":436

________________________________

This seems to be timeout issue.

{"timestamp":1438585142.846115,"message":"Request failed: 500:
{\"code\"=>10001, \"description\"=>\"connect timeout reached\",
\"error_code\"=>\"CF-Timeout\",
\"backtrace\"=>[\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/excon-0.44.1/lib/excon/socket.rb:135:in
`rescue in block in connect'

{"timestamp":1438585142.851403,"message":"(0.001378s) UPDATE
delayed_jobs SET guid = '6e4167d9-c7ee-4425-9049-e50971864a64',
created_at = '2015-08-03 06:55:01', updated_at = CURRENT_TIMESTAMP,
priority = 0, attempts = 0, handler = '---
!ruby/object:VCAP::CloudController::Jobs::ExceptionCatchingJob\nhandler:
!ruby/object:VCAP::CloudController::Jobs::RequestJob\n handler:
!ruby/object:VCAP::CloudController::Jobs::TimeoutJob\n handler:
!ruby/object:VCAP::CloudController::Jobs::Runtime::AppBitsPacker\n
app_guid: 41657738-cc7c-4237-ab52-e4f9683e16f4\n
uploaded_compressed_path:
\\"/var/vcap/data/cloud_controller_ng/tmp/uploads/0000000001\\"\n
fingerprints: []\n request_id:
64cc342c-9db9-495e-46d9-ce5e9331aa41::d6c111c3-79b1-4fec-8fa9-0d4be759bdd9\n',
last_error = NULL, run_at = '2015-08-03 06:55:01', locked_at =
'2015-08-03 06:55:02', failed_at = NULL,locked_by =
'cc_api_worker.api_z1.0.2', queue = 'cc-api_z1-0', cf_api_error =
'---\nerror_code: UnknownError\ndescription: An unknown error
occurred.\ncode: 10001\n' WHERE (id = 989) LIMIT
1","log_level":"debug2","source":"cc.background","data":{},"thread_id":70006300463920,"fiber_id":70006336842960,"process_id":4397,"file":"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/sequel-4.21.0/lib/sequel/database/logging.rb","lineno":70,"method":"block
in log_each"}

________________________________

I will try to push Java app to verify if its getting pushed.

On Mon, Aug 3, 2015 at 2:19 PM, Gwenn Etourneau <getourneau(a)pivotal.io> wrote:
Btw CF-213 is a fresh install or update ??

On Mon, Aug 3, 2015 at 5:37 PM, Ronak Agarwal <roagarwa(a)tibco.com> wrote:

Hi,

Please go through all my instance info below and let me know what can
be done to resolve this issue??

I have deployed CF-213.yml release through microbosh on AWS.
I have installed latest CF CLI v6.12.2
I am able to do cf login using below endpoints -
/.cf/config.json
"Target": "https://api.cf.ronak.com",
"ApiVersion": "2.33.0",
"AuthorizationEndpoint": "https://login.cf.ronak.com",
"LoggregatorEndPoint": "wss://loggregator.cf.ronak.com:4443",
"DopplerEndPoint": "wss://doppler.cf.ronak.com:4443",
"UaaEndpoint": "https://uaa.cf.ronak.com",

Now when I am trying to push Nodejs app using -
cf push nodeapp -c "node main.js" -m 128M -b node_buildpack
OR
cf push nodeapp -c "node main.js"

both are failing .. gives unknown error.
When I do -> cf logs nodeapp --recent
It gives below error -
FAILED
Error dialing loggregator server: Get

https://loggregator.cf.ronak.com:4443/recent?app=05ea8bda-28c1-49ed-8c65-4625c77423be:
EOF.
Please ask your Cloud Foundry Operator to check the platform
configuration (loggregator endpoint is
wss://loggregator.cf.ronak.com:4443).



--------------------------------------------------------------------------------

I am using ELB and my HA-proxy job is not running. Please let me know
how to overcome this challenge. I found lot of people have faced it
but all of them I think are using HA-proxy and not ELB.

I have configured 4443 with SSL on ELB -

80 (HTTP) forwarding to 80 (HTTP),
443 (HTTPS, Certificate: cfrouter_cert) forwarding to 80 (HTTP),
4443 (SSL, Certificate: cfrouter_cert) forwarding to 80 (TCP)



----------------------------------------------------------------------------------

Below are the vms/jobs which are running on AWS I dont see login_z1/z2
in them, so do I need these jobs?

Job/index | State | Resource Pool | IPs |

+------------------------------------+---------+---------------+--------------+
| api_worker_z1/0 | running | small_z1 | 10.10.17.3 |
| api_worker_z2/0 | running | small_z2 | 10.10.81.0 |
| api_z1/0 | running | large_z1 | 10.10.17.1 |
| api_z2/0 | running | large_z2 | 10.10.80.255 |
| clock_global/0 | running | medium_z1 | 10.10.17.2 |
| doppler_z1/0 | running | medium_z1 | 10.10.17.6 |
| doppler_z2/0 | running | medium_z2 | 10.10.81.3 |
| etcd_z1/0 | running | medium_z1 | 10.10.16.20 |
| etcd_z1/1 | running | medium_z1 | 10.10.16.35 |
| etcd_z2/0 | running | medium_z2 | 10.10.80.19 |
| hm9000_z1/0 | running | medium_z1 | 10.10.17.4 |
| hm9000_z2/0 | running | medium_z2 | 10.10.81.1 |
| loggregator_trafficcontroller_z1/0 | running | small_z1 | 10.10.17.7 |
| loggregator_trafficcontroller_z2/0 | running | small_z2 | 10.10.81.4 |
| nats_z1/0 | running | medium_z1 | 10.10.16.11 |
| nats_z2/0 | running | medium_z2 | 10.10.80.11 |
| nfs_z1/0 | running | medium_z1 | 10.10.16.36 |
| router_z1/0 | running | router_z1 | 10.10.16.15 |
| router_z2/0 | running | router_z2 | 10.10.80.15 |
| runner_z1/0 | running | runner_z1 | 10.10.17.5 |
| runner_z2/0 | running | runner_z2 | 10.10.81.2 |
| stats_z1/0 | running | small_z1 | 10.10.16.255 |
| uaa_z1/0 | running | medium_z1 | 10.10.17.0 |
| uaa_z2/0 | running | medium_z2 | 10.10.80.254 |


------------------------------------------------------------------------------------------------------

openssl s_client -connect api.cf.ronak.com:443
CONNECTED(00000003)
depth=0 C = US, O = Pivotal, CN = *.cf.ronak.com
verify error:num=18:self signed certificate
verify return:1
depth=0 C = US, O = Pivotal, CN = *.cf.ronak.com

verify return:1

Certificate chain
0 s:/C=US/O=Pivotal/CN=*.cf.ronak.com

i:/C=US/O=Pivotal/CN=*.cf.ronak.com

Server certificate
-----BEGIN CERTIFICATE-----
MIIC6TCCAdGgAwIBAgIBADANBgkqhkiG9w0BAQUFADA4MQswCQYDVQQGEwJVUzEQ
MA4GA1UECgwHUGl2b3RhbDEXMBUGA1UEAwwOKi5jZi5yb25hay5jb20wHhcNMTUw
NzE0MTAxNDA1WhcNMTgwNzE0MTAxNDA1WjA4MQswCQYDVQQGEwJVUzEQMA4GA1UE
CgwHUGl2b3RhbDEXMBUGA1UEAwwOKi5jZi5yb25hay5jb20wggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQDi2+NVSsR7/oCh40H+CfFWUS0BczyTubpV72Ir
6TCkjLitLdFgJFqNvaIcT0+2+rozxQs7Zr/IlH5OznYsFYNyOSx2l/xDKCqA7q4U
l6aGhFZSodIow6AKCRzVt2y5T/nmeRCWsVPjHMvANvJlM57PdWI1vIlaav3l3enF
FUs14MSEuXY+eWfeP74Sprg/Xc5TiD5RQPLZC8h2HeAmIMgTV5TAagWiGK5MUoQ9
hScJvsgBPKQuldRfRsk7NxuXmY+wdfOYKc5CZ7szl7QiLsT7Tdeei+UuhIAh874S
HjPP+JlFH4/whRJyDtv/h9rZzW1DJbx5ZeUtzFGv0jxmsvJrAgMBAAEwDQYJKoZI
hvcNAQEFBQADggEBAM7S9za5V2sJ8Gwb4QQ29F4bQxVNk5/u7AnbzvfmhcWgO9yt
oBUwtc04F/Ycz7sTlXXDe0f+nSo+Q0vowd4NmTSont5g8ZznD18k4krCcfvXCsAL
AvJ/yt2n+fW/gwZbZHS9kb4Esxu4SmjU8GFN10+DMRFaB9JkbRpJmRLsxZzE8w+E
MW7gi0V+IycOLyeJsfwXtjGZhKsLSq6fg/mwVax9Z0MsqVRbzO61RaJjMDiop+aN
kf/ktqGVBACwqvG7cxKu4/2cFMzi6dC9xEN7o5spinfdNt/uH3O0JHRcftUCICaL
ln6RtW7XXHNWnP2YfMXxPLvhjV/Cg49soz3D+os=
-----END CERTIFICATE-----
subject=/C=US/O=Pivotal/CN=*.cf.ronak.com

issuer=/C=US/O=Pivotal/CN=*.cf.ronak.com

No client certificate CA names sent

SSL handshake has read 1403 bytes and written 421 bytes

New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES128-GCM-SHA256
Session-ID:
B845CA20842317DB12FB250C05D40686334A7C85D8BE2E5332B6C70632BF9256
Session-ID-ctx:
Master-Key:
3934F0F361C1A407B215D869F8142F3B3180BB8CD232D55D937430CDD3674F047A774594B6A3BA9DB7275D1E507AE0B5
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
0000 - 1b 21 b6 45 6b 48 d6 c5-6d 66 e4 97 58 ae 76 91 .!.EkH..mf..X.v.
0010 - 0c 85 3f 3b f8 79 3d 59-b5 55 57 bd a7 98 a2 90 ..?;.y=Y.UW.....
0020 - 20 81 2b 0b 8a 6a 13 8c-1e e7 c4 d2 f7 d1 f6 5b .+..j.........[
0030 - c7 d6 58 16 42 89 1e 51-01 7d 20 24 3f fa 2e f7 ..X.B..Q.} $?...
0040 - 76 06 d5 61 ff 4f 5c a1-46 77 41 62 fe fc c9 50 v..a.O.FwAb...P
0050 - 55 b6 00 98 15 22 8a 81-e2 e0 0e 9d da 83 fc 7b U....".........{
0060 - ef 33 16 ec 88 60 ca 38-3f 35 85 6d fe 68 26 f6 .3...`.8?5.m.h&.
0070 - 24 48 65 47 8b c4 f6 20-f9 31 63 74 56 1a 67 d5 $HeG... .1ctV.g.
0080 - 26 d1 4c 0d fa 5f 01 da-ec d9 a6 88 9d ab cd fa &.L.._..........
0090 - 05 17 bd e4 b4 78 f4 02-6b 5e 86 83 04 b7 f2 33 .....x..k^.....3

Start Time: 1438453185
Timeout : 300 (sec)
Verify return code: 18 (self signed certificate)


------------------------------------------------------------------------------------------------------------------------


I am using self signed certificate.. so if I have to continue without
--skip-ssl-validation, I should add this ELB certificate in all the
VMS as trusted keys. Is it correct ? OR anyother option ?


--------------------------------------------------------------------------------------------------------------


In CF-AWS-Stub.yml I found two -
a) jwt: signing_key & verification_key
b) router . ssl_cert & ssl_key
Both should be same as AWS ELB ssl certificate ??



------------------------------------------------------------------------------------------


I think core problem is cf push error which I mentioned above -

1) I can see in Response - "detected_buildpack": null, I am not sure
why its null because I am uploading system buildpack app which of
Nodejs and when I do - cf buildpacks I can see 4 buildpacks below -

buildpack position enabled locked filename
staticfile_buildpack 1 true false
java_buildpack 2 true false
node_buildpack 3 true false
php_buildpack 6 true false

I am not sure why filename is null ??

2) Unknown Error Code - 10001 explained more below



---------------------------------------------------------------------------------------

'CF_TRACE=true cf push' gives below error -

REQUEST: [2015-08-02T10:40:17Z]
GET /v2/jobs/fd682f50-c857-40dc-a190-abc0f59492c5 HTTP/1.1
Host: api.cf.ronak.com
Accept: application/json
Authorization: [PRIVATE DATA HIDDEN]
Content-Type: application/json
User-Agent: go-cli 6.12.2-24abed3 / linux

RESPONSE: [2015-08-02T10:40:17Z]
HTTP/1.1 200 OK
Content-Length: 491
Connection: keep-alive
Content-Type: application/json;charset=utf-8
Date: Sun, 02 Aug 2015 10:40:17 GMT
Server: nginx
X-Cf-Requestid: f423947e-8512-41f0-7fd1-21ba6b89178d
X-Content-Type-Options: nosniff
X-Vcap-Request-Id:
aa782bd8-d758-4c65-505c-af71f2bc212d::a0ac2db0-3f3e-4a49-b011-2f9e7f02660b

{
"metadata": {
"guid": "fd682f50-c857-40dc-a190-abc0f59492c5",
"created_at": "2015-08-02T10:36:11Z",
"url": "/v2/jobs/fd682f50-c857-40dc-a190-abc0f59492c5"
},
"entity": {
"guid": "fd682f50-c857-40dc-a190-abc0f59492c5",
"status": "failed",
"error": "Use of entity>error is deprecated in favor of
entity>error_details.",
"error_details": {
"error_code": "UnknownError",
"description": "An unknown error occurred.",
"code": 10001
}
}
}
FAILED
Error uploading application.
An unknown error occurred.
FAILED
Error uploading application.
An unknown error occurred.

________________________________

I found post in which its mentioned - The point was that S3 buckets
name (specified by following options: resource_directory_key,
app_package_directory_key, droplet_directory_key, and
buildpack_directory_key) had dots in their names. Removing dots from
this parameters will solve the problem.

I removing dots and replaced with '-' and again did 'bosh deploy' ---
I can't find these directories getting created after deployment under
S3 ?? is it normal ?
I tried cf push anyways to check if its working - but gave me same
'Unkown Error code 10001.

Please help me to solve the problem.


---------------------------------------------------------------------------------------------------

cf logs nodeapp --recent

RESPONSE: [2015-08-02T10:41:51Z]
HTTP/1.1 200 OK
Content-Length: 4525
Connection: keep-alive
Content-Type: application/json;charset=utf-8
Date: Sun, 02 Aug 2015 10:41:50 GMT
Server: nginx
X-Cf-Requestid: c5508a55-a9f4-4be0-49a4-23a4f14fb5d3
X-Content-Type-Options: nosniff
X-Vcap-Request-Id:
ae35d7fc-659f-4811-4d7c-077a78963951::4bae904f-6903-4a76-9d0e-314098266502

{
"total_results": 1,
"total_pages": 1,
"prev_url": null,
"next_url": null,
"resources": [
{
"metadata": {
"guid": "41657738-cc7c-4237-ab52-e4f9683e16f4",
"url": "/v2/apps/41657738-cc7c-4237-ab52-e4f9683e16f4",
"created_at": "2015-08-02T10:36:10Z",
"updated_at": "2015-08-02T10:36:11Z"
},
"entity": {
"name": "nodeapp",
"production": false,
"space_guid": "6ffcaf95-f30b-41b6-88ce-d67f59584e89",
"stack_guid": "612874d8-144e-4599-88a7-e38e333ca93e",
"buildpack": null,
"detected_buildpack": null,
"environment_json": {

},
"memory": 1024,
"instances": 1,
"disk_quota": 1024,
"state": "STOPPED",
"version": "d2fa841d-17d6-4bae-9400-409966082443",
"command": "node main.js",
"console": false,
"debug": null,
"staging_task_id": null,
"package_state": "PENDING",
"health_check_type": "port",
"health_check_timeout": null,
"staging_failed_reason": null,
"staging_failed_description": null,
"diego": false,
"docker_image": null,
"package_updated_at": null,
"detected_start_command": "",
"enable_ssh": true,
"docker_credentials_json": {
"redacted_message": "[PRIVATE DATA HIDDEN]"
},
"space_url": "/v2/spaces/6ffcaf95-f30b-41b6-88ce-d67f59584e89",
"space": {
"metadata": {
"guid": "6ffcaf95-f30b-41b6-88ce-d67f59584e89",
"url": "/v2/spaces/6ffcaf95-f30b-41b6-88ce-d67f59584e89",
"created_at": "2015-07-30T09:08:36Z",
"updated_at": null
},
"entity": {
"name": "ronak",
"organization_guid": "66e33d43-92fa-4f30-809d-1f5d9adaf921",
"space_quota_definition_guid": null,
"allow_ssh": true,
"organization_url":
"/v2/organizations/66e33d43-92fa-4f30-809d-1f5d9adaf921",
"developers_url":
"/v2/spaces/6ffcaf95-f30b-41b6-88ce-d67f59584e89/developers",
"managers_url":
"/v2/spaces/6ffcaf95-f30b-41b6-88ce-d67f59584e89/managers",
"auditors_url":
"/v2/spaces/6ffcaf95-f30b-41b6-88ce-d67f59584e89/auditors",
"apps_url":
"/v2/spaces/6ffcaf95-f30b-41b6-88ce-d67f59584e89/apps",
"routes_url":
"/v2/spaces/6ffcaf95-f30b-41b6-88ce-d67f59584e89/routes",
"domains_url":
"/v2/spaces/6ffcaf95-f30b-41b6-88ce-d67f59584e89/domains",
"service_instances_url":
"/v2/spaces/6ffcaf95-f30b-41b6-88ce-d67f59584e89/service_instances",
"app_events_url":
"/v2/spaces/6ffcaf95-f30b-41b6-88ce-d67f59584e89/app_events",
"events_url":
"/v2/spaces/6ffcaf95-f30b-41b6-88ce-d67f59584e89/events",
"security_groups_url":
"/v2/spaces/6ffcaf95-f30b-41b6-88ce-d67f59584e89/security_groups"
}
},
"stack_url": "/v2/stacks/612874d8-144e-4599-88a7-e38e333ca93e",
"stack": {
"metadata": {
"guid": "612874d8-144e-4599-88a7-e38e333ca93e",
"url": "/v2/stacks/612874d8-144e-4599-88a7-e38e333ca93e",
"created_at": "2015-07-23T12:10:53Z",
"updated_at": null
},
"entity": {
"name": "cflinuxfs2",
"description": "Cloud Foundry Linux-based filesystem"
}
},
"events_url": "/v2/apps/41657738-cc7c-4237-ab52-e4f9683e16f4/events",
"service_bindings_url":
"/v2/apps/41657738-cc7c-4237-ab52-e4f9683e16f4/service_bindings",
"service_bindings": [

],
"routes_url": "/v2/apps/41657738-cc7c-4237-ab52-e4f9683e16f4/routes",
"routes": [
{
"metadata": {
"guid": "2489386f-973b-45db-bc86-412b57bfffb0",
"url": "/v2/routes/2489386f-973b-45db-bc86-412b57bfffb0",
"created_at": "2015-07-31T06:53:17Z",
"updated_at": null
},
"entity": {
"host": "nodeapp",
"path": "",
"domain_guid": "c3c27b28-9fef-4130-8942-41dbeb8220a0",
"space_guid": "6ffcaf95-f30b-41b6-88ce-d67f59584e89",
"domain_url":
"/v2/domains/c3c27b28-9fef-4130-8942-41dbeb8220a0",
"space_url": "/v2/spaces/6ffcaf95-f30b-41b6-88ce-d67f59584e89",
"apps_url":
"/v2/routes/2489386f-973b-45db-bc86-412b57bfffb0/apps"
}
}
]
}
}

]
}
Connected, dumping recent logs for app nodeapp in org ronak / space
ronak as admin...

FAILED
Error dialing loggregator server: Get

https://loggregator.cf.ronak.com:4443/recent?app=41657738-cc7c-4237-ab52-e4f9683e16f4:
EOF.
Please ask your Cloud Foundry Operator to check the platform
configuration (loggregator endpoint is
wss://loggregator.cf.ronak.com:4443).
FAILED
Error dialing loggregator server: Get

https://loggregator.cf.ronak.com:4443/recent?app=41657738-cc7c-4237-ab52-e4f9683e16f4:
EOF.
Please ask your Cloud Foundry Operator to check the platform
configuration (loggregator endpoint is
wss://loggregator.cf.ronak.com:4443).



----------------------------------------------------------------------------------------------------------


Please go through all my above research and let me know what can be
done to resolve this issue??


Thanks
Ronak
_______________________________________________
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
--
Regards,
Ronak Agarwal
(M) +91 8446044994
(O) +91 20 4150 7935
roagarwa(a)tibco.com


Re: Is Garden limiting disk IOs ?

Will Pragnell <wpragnell@...>
 

The honest answer there is that I'm not sure. It's conceivable that
limiting CPU for a container could prevent it from pummeling disk enough to
DOS a garden host, but we've not tested that. I'll talk to the team about
investigating this DOS vector.

On 30 July 2015 at 21:03, Guillaume Berche <bercheg(a)gmail.com> wrote:

Thanks Will.

Would other existing limits (e.g. nice, or fair cpu share) prevent one app
from using up all of the host disk io, or could such app impact its
neighbor containers (and other DEA/Cell process), and possibly up to denial
of service (e.g. a compromised app that was to impact the cf platform that
host them) ?

Guillaume.

On Thu, Jul 30, 2015 at 6:34 PM, Will Pragnell <wpragnell(a)pivotal.io>
wrote:

Hi Guillaume,

No, Garden-Linux does not currently do any disk IO limiting.

Thanks,
Will

On 30 July 2015 at 17:24, Guillaume Berche <bercheg(a)gmail.com> wrote:

Out of curiosity, I'd like to understand whether Garden is limiting disk
IOs, similar to [2].

I do see disk space, inodes..., and network IOs limits described into
[1] but did not find block IOs.

Thanks in advance,

Guillaume.

[1] http://godoc.org/github.com/cloudfoundry-incubator/garden
[2]
https://github.com/appc/spec/blob/master/spec/ace.md#resourceblock-bandwidth


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

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

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


Re: CF push error - Not able to resolve - Error dialing loggregator server: Get https://loggregator.systemdomain.com

Gwenn Etourneau
 

Btw CF-213 is a fresh install or update ??

On Mon, Aug 3, 2015 at 5:37 PM, Ronak Agarwal <roagarwa(a)tibco.com> wrote:

Hi,

Please go through all my instance info below and let me know what can
be done to resolve this issue??

I have deployed CF-213.yml release through microbosh on AWS.
I have installed latest CF CLI v6.12.2
I am able to do cf login using below endpoints -
/.cf/config.json
"Target": "https://api.cf.ronak.com",
"ApiVersion": "2.33.0",
"AuthorizationEndpoint": "https://login.cf.ronak.com",
"LoggregatorEndPoint": "wss://loggregator.cf.ronak.com:4443",
"DopplerEndPoint": "wss://doppler.cf.ronak.com:4443",
"UaaEndpoint": "https://uaa.cf.ronak.com",

Now when I am trying to push Nodejs app using -
cf push nodeapp -c "node main.js" -m 128M -b node_buildpack
OR
cf push nodeapp -c "node main.js"

both are failing .. gives unknown error.
When I do -> cf logs nodeapp --recent
It gives below error -
FAILED
Error dialing loggregator server: Get

https://loggregator.cf.ronak.com:4443/recent?app=05ea8bda-28c1-49ed-8c65-4625c77423be
:
EOF.
Please ask your Cloud Foundry Operator to check the platform
configuration (loggregator endpoint is
wss://loggregator.cf.ronak.com:4443).



--------------------------------------------------------------------------------

I am using ELB and my HA-proxy job is not running. Please let me know
how to overcome this challenge. I found lot of people have faced it
but all of them I think are using HA-proxy and not ELB.

I have configured 4443 with SSL on ELB -

80 (HTTP) forwarding to 80 (HTTP),
443 (HTTPS, Certificate: cfrouter_cert) forwarding to 80 (HTTP),
4443 (SSL, Certificate: cfrouter_cert) forwarding to 80 (TCP)



----------------------------------------------------------------------------------

Below are the vms/jobs which are running on AWS I dont see login_z1/z2
in them, so do I need these jobs?

Job/index | State | Resource Pool | IPs |

+------------------------------------+---------+---------------+--------------+
| api_worker_z1/0 | running | small_z1 | 10.10.17.3 |
| api_worker_z2/0 | running | small_z2 | 10.10.81.0 |
| api_z1/0 | running | large_z1 | 10.10.17.1 |
| api_z2/0 | running | large_z2 | 10.10.80.255 |
| clock_global/0 | running | medium_z1 | 10.10.17.2 |
| doppler_z1/0 | running | medium_z1 | 10.10.17.6 |
| doppler_z2/0 | running | medium_z2 | 10.10.81.3 |
| etcd_z1/0 | running | medium_z1 | 10.10.16.20 |
| etcd_z1/1 | running | medium_z1 | 10.10.16.35 |
| etcd_z2/0 | running | medium_z2 | 10.10.80.19 |
| hm9000_z1/0 | running | medium_z1 | 10.10.17.4 |
| hm9000_z2/0 | running | medium_z2 | 10.10.81.1 |
| loggregator_trafficcontroller_z1/0 | running | small_z1 | 10.10.17.7 |
| loggregator_trafficcontroller_z2/0 | running | small_z2 | 10.10.81.4 |
| nats_z1/0 | running | medium_z1 | 10.10.16.11 |
| nats_z2/0 | running | medium_z2 | 10.10.80.11 |
| nfs_z1/0 | running | medium_z1 | 10.10.16.36 |
| router_z1/0 | running | router_z1 | 10.10.16.15 |
| router_z2/0 | running | router_z2 | 10.10.80.15 |
| runner_z1/0 | running | runner_z1 | 10.10.17.5 |
| runner_z2/0 | running | runner_z2 | 10.10.81.2 |
| stats_z1/0 | running | small_z1 | 10.10.16.255 |
| uaa_z1/0 | running | medium_z1 | 10.10.17.0 |
| uaa_z2/0 | running | medium_z2 | 10.10.80.254 |


------------------------------------------------------------------------------------------------------

openssl s_client -connect api.cf.ronak.com:443
CONNECTED(00000003)
depth=0 C = US, O = Pivotal, CN = *.cf.ronak.com
verify error:num=18:self signed certificate
verify return:1
depth=0 C = US, O = Pivotal, CN = *.cf.ronak.com

verify return:1

Certificate chain
0 s:/C=US/O=Pivotal/CN=*.cf.ronak.com

i:/C=US/O=Pivotal/CN=*.cf.ronak.com

Server certificate
-----BEGIN CERTIFICATE-----
MIIC6TCCAdGgAwIBAgIBADANBgkqhkiG9w0BAQUFADA4MQswCQYDVQQGEwJVUzEQ
MA4GA1UECgwHUGl2b3RhbDEXMBUGA1UEAwwOKi5jZi5yb25hay5jb20wHhcNMTUw
NzE0MTAxNDA1WhcNMTgwNzE0MTAxNDA1WjA4MQswCQYDVQQGEwJVUzEQMA4GA1UE
CgwHUGl2b3RhbDEXMBUGA1UEAwwOKi5jZi5yb25hay5jb20wggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQDi2+NVSsR7/oCh40H+CfFWUS0BczyTubpV72Ir
6TCkjLitLdFgJFqNvaIcT0+2+rozxQs7Zr/IlH5OznYsFYNyOSx2l/xDKCqA7q4U
l6aGhFZSodIow6AKCRzVt2y5T/nmeRCWsVPjHMvANvJlM57PdWI1vIlaav3l3enF
FUs14MSEuXY+eWfeP74Sprg/Xc5TiD5RQPLZC8h2HeAmIMgTV5TAagWiGK5MUoQ9
hScJvsgBPKQuldRfRsk7NxuXmY+wdfOYKc5CZ7szl7QiLsT7Tdeei+UuhIAh874S
HjPP+JlFH4/whRJyDtv/h9rZzW1DJbx5ZeUtzFGv0jxmsvJrAgMBAAEwDQYJKoZI
hvcNAQEFBQADggEBAM7S9za5V2sJ8Gwb4QQ29F4bQxVNk5/u7AnbzvfmhcWgO9yt
oBUwtc04F/Ycz7sTlXXDe0f+nSo+Q0vowd4NmTSont5g8ZznD18k4krCcfvXCsAL
AvJ/yt2n+fW/gwZbZHS9kb4Esxu4SmjU8GFN10+DMRFaB9JkbRpJmRLsxZzE8w+E
MW7gi0V+IycOLyeJsfwXtjGZhKsLSq6fg/mwVax9Z0MsqVRbzO61RaJjMDiop+aN
kf/ktqGVBACwqvG7cxKu4/2cFMzi6dC9xEN7o5spinfdNt/uH3O0JHRcftUCICaL
ln6RtW7XXHNWnP2YfMXxPLvhjV/Cg49soz3D+os=
-----END CERTIFICATE-----
subject=/C=US/O=Pivotal/CN=*.cf.ronak.com

issuer=/C=US/O=Pivotal/CN=*.cf.ronak.com

No client certificate CA names sent

SSL handshake has read 1403 bytes and written 421 bytes

New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES128-GCM-SHA256
Session-ID:
B845CA20842317DB12FB250C05D40686334A7C85D8BE2E5332B6C70632BF9256
Session-ID-ctx:
Master-Key:
3934F0F361C1A407B215D869F8142F3B3180BB8CD232D55D937430CDD3674F047A774594B6A3BA9DB7275D1E507AE0B5
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
0000 - 1b 21 b6 45 6b 48 d6 c5-6d 66 e4 97 58 ae 76 91 .!.EkH..mf..X.v.
0010 - 0c 85 3f 3b f8 79 3d 59-b5 55 57 bd a7 98 a2 90 ..?;.y=Y.UW.....
0020 - 20 81 2b 0b 8a 6a 13 8c-1e e7 c4 d2 f7 d1 f6 5b .+..j.........[
0030 - c7 d6 58 16 42 89 1e 51-01 7d 20 24 3f fa 2e f7 ..X.B..Q.} $?...
0040 - 76 06 d5 61 ff 4f 5c a1-46 77 41 62 fe fc c9 50 v..a.O.FwAb...P
0050 - 55 b6 00 98 15 22 8a 81-e2 e0 0e 9d da 83 fc 7b U....".........{
0060 - ef 33 16 ec 88 60 ca 38-3f 35 85 6d fe 68 26 f6 .3...`.8?5.m.h&.
0070 - 24 48 65 47 8b c4 f6 20-f9 31 63 74 56 1a 67 d5 $HeG... .1ctV.g.
0080 - 26 d1 4c 0d fa 5f 01 da-ec d9 a6 88 9d ab cd fa &.L.._..........
0090 - 05 17 bd e4 b4 78 f4 02-6b 5e 86 83 04 b7 f2 33 .....x..k^.....3

Start Time: 1438453185
Timeout : 300 (sec)
Verify return code: 18 (self signed certificate)


------------------------------------------------------------------------------------------------------------------------


I am using self signed certificate.. so if I have to continue without
--skip-ssl-validation, I should add this ELB certificate in all the
VMS as trusted keys. Is it correct ? OR anyother option ?


--------------------------------------------------------------------------------------------------------------


In CF-AWS-Stub.yml I found two -
a) jwt: signing_key & verification_key
b) router . ssl_cert & ssl_key
Both should be same as AWS ELB ssl certificate ??



------------------------------------------------------------------------------------------


I think core problem is cf push error which I mentioned above -

1) I can see in Response - "detected_buildpack": null, I am not sure
why its null because I am uploading system buildpack app which of
Nodejs and when I do - cf buildpacks I can see 4 buildpacks below -

buildpack position enabled locked filename
staticfile_buildpack 1 true false
java_buildpack 2 true false
node_buildpack 3 true false
php_buildpack 6 true false

I am not sure why filename is null ??

2) Unknown Error Code - 10001 explained more below



---------------------------------------------------------------------------------------

'CF_TRACE=true cf push' gives below error -

REQUEST: [2015-08-02T10:40:17Z]
GET /v2/jobs/fd682f50-c857-40dc-a190-abc0f59492c5 HTTP/1.1
Host: api.cf.ronak.com
Accept: application/json
Authorization: [PRIVATE DATA HIDDEN]
Content-Type: application/json
User-Agent: go-cli 6.12.2-24abed3 / linux

RESPONSE: [2015-08-02T10:40:17Z]
HTTP/1.1 200 OK
Content-Length: 491
Connection: keep-alive
Content-Type: application/json;charset=utf-8
Date: Sun, 02 Aug 2015 10:40:17 GMT
Server: nginx
X-Cf-Requestid: f423947e-8512-41f0-7fd1-21ba6b89178d
X-Content-Type-Options: nosniff
X-Vcap-Request-Id:
aa782bd8-d758-4c65-505c-af71f2bc212d::a0ac2db0-3f3e-4a49-b011-2f9e7f02660b

{
"metadata": {
"guid": "fd682f50-c857-40dc-a190-abc0f59492c5",
"created_at": "2015-08-02T10:36:11Z",
"url": "/v2/jobs/fd682f50-c857-40dc-a190-abc0f59492c5"
},
"entity": {
"guid": "fd682f50-c857-40dc-a190-abc0f59492c5",
"status": "failed",
"error": "Use of entity>error is deprecated in favor of
entity>error_details.",
"error_details": {
"error_code": "UnknownError",
"description": "An unknown error occurred.",
"code": 10001
}
}
}
FAILED
Error uploading application.
An unknown error occurred.
FAILED
Error uploading application.
An unknown error occurred.

________________________________

I found post in which its mentioned - The point was that S3 buckets
name (specified by following options: resource_directory_key,
app_package_directory_key, droplet_directory_key, and
buildpack_directory_key) had dots in their names. Removing dots from
this parameters will solve the problem.

I removing dots and replaced with '-' and again did 'bosh deploy' ---
I can't find these directories getting created after deployment under
S3 ?? is it normal ?
I tried cf push anyways to check if its working - but gave me same
'Unkown Error code 10001.

Please help me to solve the problem.


---------------------------------------------------------------------------------------------------

cf logs nodeapp --recent

RESPONSE: [2015-08-02T10:41:51Z]
HTTP/1.1 200 OK
Content-Length: 4525
Connection: keep-alive
Content-Type: application/json;charset=utf-8
Date: Sun, 02 Aug 2015 10:41:50 GMT
Server: nginx
X-Cf-Requestid: c5508a55-a9f4-4be0-49a4-23a4f14fb5d3
X-Content-Type-Options: nosniff
X-Vcap-Request-Id:
ae35d7fc-659f-4811-4d7c-077a78963951::4bae904f-6903-4a76-9d0e-314098266502

{
"total_results": 1,
"total_pages": 1,
"prev_url": null,
"next_url": null,
"resources": [
{
"metadata": {
"guid": "41657738-cc7c-4237-ab52-e4f9683e16f4",
"url": "/v2/apps/41657738-cc7c-4237-ab52-e4f9683e16f4",
"created_at": "2015-08-02T10:36:10Z",
"updated_at": "2015-08-02T10:36:11Z"
},
"entity": {
"name": "nodeapp",
"production": false,
"space_guid": "6ffcaf95-f30b-41b6-88ce-d67f59584e89",
"stack_guid": "612874d8-144e-4599-88a7-e38e333ca93e",
"buildpack": null,
"detected_buildpack": null,
"environment_json": {

},
"memory": 1024,
"instances": 1,
"disk_quota": 1024,
"state": "STOPPED",
"version": "d2fa841d-17d6-4bae-9400-409966082443",
"command": "node main.js",
"console": false,
"debug": null,
"staging_task_id": null,
"package_state": "PENDING",
"health_check_type": "port",
"health_check_timeout": null,
"staging_failed_reason": null,
"staging_failed_description": null,
"diego": false,
"docker_image": null,
"package_updated_at": null,
"detected_start_command": "",
"enable_ssh": true,
"docker_credentials_json": {
"redacted_message": "[PRIVATE DATA HIDDEN]"
},
"space_url": "/v2/spaces/6ffcaf95-f30b-41b6-88ce-d67f59584e89",
"space": {
"metadata": {
"guid": "6ffcaf95-f30b-41b6-88ce-d67f59584e89",
"url": "/v2/spaces/6ffcaf95-f30b-41b6-88ce-d67f59584e89",
"created_at": "2015-07-30T09:08:36Z",
"updated_at": null
},
"entity": {
"name": "ronak",
"organization_guid": "66e33d43-92fa-4f30-809d-1f5d9adaf921",
"space_quota_definition_guid": null,
"allow_ssh": true,
"organization_url":
"/v2/organizations/66e33d43-92fa-4f30-809d-1f5d9adaf921",
"developers_url":
"/v2/spaces/6ffcaf95-f30b-41b6-88ce-d67f59584e89/developers",
"managers_url":
"/v2/spaces/6ffcaf95-f30b-41b6-88ce-d67f59584e89/managers",
"auditors_url":
"/v2/spaces/6ffcaf95-f30b-41b6-88ce-d67f59584e89/auditors",
"apps_url": "/v2/spaces/6ffcaf95-f30b-41b6-88ce-d67f59584e89/apps",
"routes_url":
"/v2/spaces/6ffcaf95-f30b-41b6-88ce-d67f59584e89/routes",
"domains_url":
"/v2/spaces/6ffcaf95-f30b-41b6-88ce-d67f59584e89/domains",
"service_instances_url":
"/v2/spaces/6ffcaf95-f30b-41b6-88ce-d67f59584e89/service_instances",
"app_events_url":
"/v2/spaces/6ffcaf95-f30b-41b6-88ce-d67f59584e89/app_events",
"events_url":
"/v2/spaces/6ffcaf95-f30b-41b6-88ce-d67f59584e89/events",
"security_groups_url":
"/v2/spaces/6ffcaf95-f30b-41b6-88ce-d67f59584e89/security_groups"
}
},
"stack_url": "/v2/stacks/612874d8-144e-4599-88a7-e38e333ca93e",
"stack": {
"metadata": {
"guid": "612874d8-144e-4599-88a7-e38e333ca93e",
"url": "/v2/stacks/612874d8-144e-4599-88a7-e38e333ca93e",
"created_at": "2015-07-23T12:10:53Z",
"updated_at": null
},
"entity": {
"name": "cflinuxfs2",
"description": "Cloud Foundry Linux-based filesystem"
}
},
"events_url": "/v2/apps/41657738-cc7c-4237-ab52-e4f9683e16f4/events",
"service_bindings_url":
"/v2/apps/41657738-cc7c-4237-ab52-e4f9683e16f4/service_bindings",
"service_bindings": [

],
"routes_url": "/v2/apps/41657738-cc7c-4237-ab52-e4f9683e16f4/routes",
"routes": [
{
"metadata": {
"guid": "2489386f-973b-45db-bc86-412b57bfffb0",
"url": "/v2/routes/2489386f-973b-45db-bc86-412b57bfffb0",
"created_at": "2015-07-31T06:53:17Z",
"updated_at": null
},
"entity": {
"host": "nodeapp",
"path": "",
"domain_guid": "c3c27b28-9fef-4130-8942-41dbeb8220a0",
"space_guid": "6ffcaf95-f30b-41b6-88ce-d67f59584e89",
"domain_url": "/v2/domains/c3c27b28-9fef-4130-8942-41dbeb8220a0",
"space_url": "/v2/spaces/6ffcaf95-f30b-41b6-88ce-d67f59584e89",
"apps_url":
"/v2/routes/2489386f-973b-45db-bc86-412b57bfffb0/apps"
}
}
]
}
}

]
}
Connected, dumping recent logs for app nodeapp in org ronak / space
ronak as admin...

FAILED
Error dialing loggregator server: Get

https://loggregator.cf.ronak.com:4443/recent?app=41657738-cc7c-4237-ab52-e4f9683e16f4
:
EOF.
Please ask your Cloud Foundry Operator to check the platform
configuration (loggregator endpoint is
wss://loggregator.cf.ronak.com:4443).
FAILED
Error dialing loggregator server: Get

https://loggregator.cf.ronak.com:4443/recent?app=41657738-cc7c-4237-ab52-e4f9683e16f4
:
EOF.
Please ask your Cloud Foundry Operator to check the platform
configuration (loggregator endpoint is
wss://loggregator.cf.ronak.com:4443).



----------------------------------------------------------------------------------------------------------


Please go through all my above research and let me know what can be
done to resolve this issue??


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


CF push error - Not able to resolve - Error dialing loggregator server: Get https://loggregator.systemdomain.com

Ronak Agarwal <roagarwa@...>
 

Hi,

Please go through all my instance info below and let me know what can
be done to resolve this issue??

I have deployed CF-213.yml release through microbosh on AWS.
I have installed latest CF CLI v6.12.2
I am able to do cf login using below endpoints -
/.cf/config.json
"Target": "https://api.cf.ronak.com",
"ApiVersion": "2.33.0",
"AuthorizationEndpoint": "https://login.cf.ronak.com",
"LoggregatorEndPoint": "wss://loggregator.cf.ronak.com:4443",
"DopplerEndPoint": "wss://doppler.cf.ronak.com:4443",
"UaaEndpoint": "https://uaa.cf.ronak.com",

Now when I am trying to push Nodejs app using -
cf push nodeapp -c "node main.js" -m 128M -b node_buildpack
OR
cf push nodeapp -c "node main.js"

both are failing .. gives unknown error.
When I do -> cf logs nodeapp --recent
It gives below error -
FAILED
Error dialing loggregator server: Get
https://loggregator.cf.ronak.com:4443/recent?app=05ea8bda-28c1-49ed-8c65-4625c77423be:
EOF.
Please ask your Cloud Foundry Operator to check the platform
configuration (loggregator endpoint is
wss://loggregator.cf.ronak.com:4443).


--------------------------------------------------------------------------------

I am using ELB and my HA-proxy job is not running. Please let me know
how to overcome this challenge. I found lot of people have faced it
but all of them I think are using HA-proxy and not ELB.

I have configured 4443 with SSL on ELB -

80 (HTTP) forwarding to 80 (HTTP),
443 (HTTPS, Certificate: cfrouter_cert) forwarding to 80 (HTTP),
4443 (SSL, Certificate: cfrouter_cert) forwarding to 80 (TCP)


----------------------------------------------------------------------------------

Below are the vms/jobs which are running on AWS I dont see login_z1/z2
in them, so do I need these jobs?

Job/index | State | Resource Pool | IPs |
+------------------------------------+---------+---------------+--------------+
| api_worker_z1/0 | running | small_z1 | 10.10.17.3 |
| api_worker_z2/0 | running | small_z2 | 10.10.81.0 |
| api_z1/0 | running | large_z1 | 10.10.17.1 |
| api_z2/0 | running | large_z2 | 10.10.80.255 |
| clock_global/0 | running | medium_z1 | 10.10.17.2 |
| doppler_z1/0 | running | medium_z1 | 10.10.17.6 |
| doppler_z2/0 | running | medium_z2 | 10.10.81.3 |
| etcd_z1/0 | running | medium_z1 | 10.10.16.20 |
| etcd_z1/1 | running | medium_z1 | 10.10.16.35 |
| etcd_z2/0 | running | medium_z2 | 10.10.80.19 |
| hm9000_z1/0 | running | medium_z1 | 10.10.17.4 |
| hm9000_z2/0 | running | medium_z2 | 10.10.81.1 |
| loggregator_trafficcontroller_z1/0 | running | small_z1 | 10.10.17.7 |
| loggregator_trafficcontroller_z2/0 | running | small_z2 | 10.10.81.4 |
| nats_z1/0 | running | medium_z1 | 10.10.16.11 |
| nats_z2/0 | running | medium_z2 | 10.10.80.11 |
| nfs_z1/0 | running | medium_z1 | 10.10.16.36 |
| router_z1/0 | running | router_z1 | 10.10.16.15 |
| router_z2/0 | running | router_z2 | 10.10.80.15 |
| runner_z1/0 | running | runner_z1 | 10.10.17.5 |
| runner_z2/0 | running | runner_z2 | 10.10.81.2 |
| stats_z1/0 | running | small_z1 | 10.10.16.255 |
| uaa_z1/0 | running | medium_z1 | 10.10.17.0 |
| uaa_z2/0 | running | medium_z2 | 10.10.80.254 |

------------------------------------------------------------------------------------------------------

openssl s_client -connect api.cf.ronak.com:443
CONNECTED(00000003)
depth=0 C = US, O = Pivotal, CN = *.cf.ronak.com
verify error:num=18:self signed certificate
verify return:1
depth=0 C = US, O = Pivotal, CN = *.cf.ronak.com

verify return:1

Certificate chain
0 s:/C=US/O=Pivotal/CN=*.cf.ronak.com

i:/C=US/O=Pivotal/CN=*.cf.ronak.com

Server certificate
-----BEGIN CERTIFICATE-----
MIIC6TCCAdGgAwIBAgIBADANBgkqhkiG9w0BAQUFADA4MQswCQYDVQQGEwJVUzEQ
MA4GA1UECgwHUGl2b3RhbDEXMBUGA1UEAwwOKi5jZi5yb25hay5jb20wHhcNMTUw
NzE0MTAxNDA1WhcNMTgwNzE0MTAxNDA1WjA4MQswCQYDVQQGEwJVUzEQMA4GA1UE
CgwHUGl2b3RhbDEXMBUGA1UEAwwOKi5jZi5yb25hay5jb20wggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQDi2+NVSsR7/oCh40H+CfFWUS0BczyTubpV72Ir
6TCkjLitLdFgJFqNvaIcT0+2+rozxQs7Zr/IlH5OznYsFYNyOSx2l/xDKCqA7q4U
l6aGhFZSodIow6AKCRzVt2y5T/nmeRCWsVPjHMvANvJlM57PdWI1vIlaav3l3enF
FUs14MSEuXY+eWfeP74Sprg/Xc5TiD5RQPLZC8h2HeAmIMgTV5TAagWiGK5MUoQ9
hScJvsgBPKQuldRfRsk7NxuXmY+wdfOYKc5CZ7szl7QiLsT7Tdeei+UuhIAh874S
HjPP+JlFH4/whRJyDtv/h9rZzW1DJbx5ZeUtzFGv0jxmsvJrAgMBAAEwDQYJKoZI
hvcNAQEFBQADggEBAM7S9za5V2sJ8Gwb4QQ29F4bQxVNk5/u7AnbzvfmhcWgO9yt
oBUwtc04F/Ycz7sTlXXDe0f+nSo+Q0vowd4NmTSont5g8ZznD18k4krCcfvXCsAL
AvJ/yt2n+fW/gwZbZHS9kb4Esxu4SmjU8GFN10+DMRFaB9JkbRpJmRLsxZzE8w+E
MW7gi0V+IycOLyeJsfwXtjGZhKsLSq6fg/mwVax9Z0MsqVRbzO61RaJjMDiop+aN
kf/ktqGVBACwqvG7cxKu4/2cFMzi6dC9xEN7o5spinfdNt/uH3O0JHRcftUCICaL
ln6RtW7XXHNWnP2YfMXxPLvhjV/Cg49soz3D+os=
-----END CERTIFICATE-----
subject=/C=US/O=Pivotal/CN=*.cf.ronak.com

issuer=/C=US/O=Pivotal/CN=*.cf.ronak.com

No client certificate CA names sent

SSL handshake has read 1403 bytes and written 421 bytes

New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES128-GCM-SHA256
Session-ID: B845CA20842317DB12FB250C05D40686334A7C85D8BE2E5332B6C70632BF9256
Session-ID-ctx:
Master-Key: 3934F0F361C1A407B215D869F8142F3B3180BB8CD232D55D937430CDD3674F047A774594B6A3BA9DB7275D1E507AE0B5
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
0000 - 1b 21 b6 45 6b 48 d6 c5-6d 66 e4 97 58 ae 76 91 .!.EkH..mf..X.v.
0010 - 0c 85 3f 3b f8 79 3d 59-b5 55 57 bd a7 98 a2 90 ..?;.y=Y.UW.....
0020 - 20 81 2b 0b 8a 6a 13 8c-1e e7 c4 d2 f7 d1 f6 5b .+..j.........[
0030 - c7 d6 58 16 42 89 1e 51-01 7d 20 24 3f fa 2e f7 ..X.B..Q.} $?...
0040 - 76 06 d5 61 ff 4f 5c a1-46 77 41 62 fe fc c9 50 v..a.O.FwAb...P
0050 - 55 b6 00 98 15 22 8a 81-e2 e0 0e 9d da 83 fc 7b U....".........{
0060 - ef 33 16 ec 88 60 ca 38-3f 35 85 6d fe 68 26 f6 .3...`.8?5.m.h&.
0070 - 24 48 65 47 8b c4 f6 20-f9 31 63 74 56 1a 67 d5 $HeG... .1ctV.g.
0080 - 26 d1 4c 0d fa 5f 01 da-ec d9 a6 88 9d ab cd fa &.L.._..........
0090 - 05 17 bd e4 b4 78 f4 02-6b 5e 86 83 04 b7 f2 33 .....x..k^.....3

Start Time: 1438453185
Timeout : 300 (sec)
Verify return code: 18 (self signed certificate)

------------------------------------------------------------------------------------------------------------------------


I am using self signed certificate.. so if I have to continue without
--skip-ssl-validation, I should add this ELB certificate in all the
VMS as trusted keys. Is it correct ? OR anyother option ?

--------------------------------------------------------------------------------------------------------------


In CF-AWS-Stub.yml I found two -
a) jwt: signing_key & verification_key
b) router . ssl_cert & ssl_key
Both should be same as AWS ELB ssl certificate ??


------------------------------------------------------------------------------------------


I think core problem is cf push error which I mentioned above -

1) I can see in Response - "detected_buildpack": null, I am not sure
why its null because I am uploading system buildpack app which of
Nodejs and when I do - cf buildpacks I can see 4 buildpacks below -

buildpack position enabled locked filename
staticfile_buildpack 1 true false
java_buildpack 2 true false
node_buildpack 3 true false
php_buildpack 6 true false

I am not sure why filename is null ??

2) Unknown Error Code - 10001 explained more below


---------------------------------------------------------------------------------------

'CF_TRACE=true cf push' gives below error -

REQUEST: [2015-08-02T10:40:17Z]
GET /v2/jobs/fd682f50-c857-40dc-a190-abc0f59492c5 HTTP/1.1
Host: api.cf.ronak.com
Accept: application/json
Authorization: [PRIVATE DATA HIDDEN]
Content-Type: application/json
User-Agent: go-cli 6.12.2-24abed3 / linux

RESPONSE: [2015-08-02T10:40:17Z]
HTTP/1.1 200 OK
Content-Length: 491
Connection: keep-alive
Content-Type: application/json;charset=utf-8
Date: Sun, 02 Aug 2015 10:40:17 GMT
Server: nginx
X-Cf-Requestid: f423947e-8512-41f0-7fd1-21ba6b89178d
X-Content-Type-Options: nosniff
X-Vcap-Request-Id:
aa782bd8-d758-4c65-505c-af71f2bc212d::a0ac2db0-3f3e-4a49-b011-2f9e7f02660b

{
"metadata": {
"guid": "fd682f50-c857-40dc-a190-abc0f59492c5",
"created_at": "2015-08-02T10:36:11Z",
"url": "/v2/jobs/fd682f50-c857-40dc-a190-abc0f59492c5"
},
"entity": {
"guid": "fd682f50-c857-40dc-a190-abc0f59492c5",
"status": "failed",
"error": "Use of entity>error is deprecated in favor of entity>error_details.",
"error_details": {
"error_code": "UnknownError",
"description": "An unknown error occurred.",
"code": 10001
}
}
}
FAILED
Error uploading application.
An unknown error occurred.
FAILED
Error uploading application.
An unknown error occurred.

________________________________

I found post in which its mentioned - The point was that S3 buckets
name (specified by following options: resource_directory_key,
app_package_directory_key, droplet_directory_key, and
buildpack_directory_key) had dots in their names. Removing dots from
this parameters will solve the problem.

I removing dots and replaced with '-' and again did 'bosh deploy' ---
I can't find these directories getting created after deployment under
S3 ?? is it normal ?
I tried cf push anyways to check if its working - but gave me same
'Unkown Error code 10001.

Please help me to solve the problem.

---------------------------------------------------------------------------------------------------

cf logs nodeapp --recent

RESPONSE: [2015-08-02T10:41:51Z]
HTTP/1.1 200 OK
Content-Length: 4525
Connection: keep-alive
Content-Type: application/json;charset=utf-8
Date: Sun, 02 Aug 2015 10:41:50 GMT
Server: nginx
X-Cf-Requestid: c5508a55-a9f4-4be0-49a4-23a4f14fb5d3
X-Content-Type-Options: nosniff
X-Vcap-Request-Id:
ae35d7fc-659f-4811-4d7c-077a78963951::4bae904f-6903-4a76-9d0e-314098266502

{
"total_results": 1,
"total_pages": 1,
"prev_url": null,
"next_url": null,
"resources": [
{
"metadata": {
"guid": "41657738-cc7c-4237-ab52-e4f9683e16f4",
"url": "/v2/apps/41657738-cc7c-4237-ab52-e4f9683e16f4",
"created_at": "2015-08-02T10:36:10Z",
"updated_at": "2015-08-02T10:36:11Z"
},
"entity": {
"name": "nodeapp",
"production": false,
"space_guid": "6ffcaf95-f30b-41b6-88ce-d67f59584e89",
"stack_guid": "612874d8-144e-4599-88a7-e38e333ca93e",
"buildpack": null,
"detected_buildpack": null,
"environment_json": {

},
"memory": 1024,
"instances": 1,
"disk_quota": 1024,
"state": "STOPPED",
"version": "d2fa841d-17d6-4bae-9400-409966082443",
"command": "node main.js",
"console": false,
"debug": null,
"staging_task_id": null,
"package_state": "PENDING",
"health_check_type": "port",
"health_check_timeout": null,
"staging_failed_reason": null,
"staging_failed_description": null,
"diego": false,
"docker_image": null,
"package_updated_at": null,
"detected_start_command": "",
"enable_ssh": true,
"docker_credentials_json": {
"redacted_message": "[PRIVATE DATA HIDDEN]"
},
"space_url": "/v2/spaces/6ffcaf95-f30b-41b6-88ce-d67f59584e89",
"space": {
"metadata": {
"guid": "6ffcaf95-f30b-41b6-88ce-d67f59584e89",
"url": "/v2/spaces/6ffcaf95-f30b-41b6-88ce-d67f59584e89",
"created_at": "2015-07-30T09:08:36Z",
"updated_at": null
},
"entity": {
"name": "ronak",
"organization_guid": "66e33d43-92fa-4f30-809d-1f5d9adaf921",
"space_quota_definition_guid": null,
"allow_ssh": true,
"organization_url":
"/v2/organizations/66e33d43-92fa-4f30-809d-1f5d9adaf921",
"developers_url":
"/v2/spaces/6ffcaf95-f30b-41b6-88ce-d67f59584e89/developers",
"managers_url":
"/v2/spaces/6ffcaf95-f30b-41b6-88ce-d67f59584e89/managers",
"auditors_url":
"/v2/spaces/6ffcaf95-f30b-41b6-88ce-d67f59584e89/auditors",
"apps_url": "/v2/spaces/6ffcaf95-f30b-41b6-88ce-d67f59584e89/apps",
"routes_url": "/v2/spaces/6ffcaf95-f30b-41b6-88ce-d67f59584e89/routes",
"domains_url":
"/v2/spaces/6ffcaf95-f30b-41b6-88ce-d67f59584e89/domains",
"service_instances_url":
"/v2/spaces/6ffcaf95-f30b-41b6-88ce-d67f59584e89/service_instances",
"app_events_url":
"/v2/spaces/6ffcaf95-f30b-41b6-88ce-d67f59584e89/app_events",
"events_url": "/v2/spaces/6ffcaf95-f30b-41b6-88ce-d67f59584e89/events",
"security_groups_url":
"/v2/spaces/6ffcaf95-f30b-41b6-88ce-d67f59584e89/security_groups"
}
},
"stack_url": "/v2/stacks/612874d8-144e-4599-88a7-e38e333ca93e",
"stack": {
"metadata": {
"guid": "612874d8-144e-4599-88a7-e38e333ca93e",
"url": "/v2/stacks/612874d8-144e-4599-88a7-e38e333ca93e",
"created_at": "2015-07-23T12:10:53Z",
"updated_at": null
},
"entity": {
"name": "cflinuxfs2",
"description": "Cloud Foundry Linux-based filesystem"
}
},
"events_url": "/v2/apps/41657738-cc7c-4237-ab52-e4f9683e16f4/events",
"service_bindings_url":
"/v2/apps/41657738-cc7c-4237-ab52-e4f9683e16f4/service_bindings",
"service_bindings": [

],
"routes_url": "/v2/apps/41657738-cc7c-4237-ab52-e4f9683e16f4/routes",
"routes": [
{
"metadata": {
"guid": "2489386f-973b-45db-bc86-412b57bfffb0",
"url": "/v2/routes/2489386f-973b-45db-bc86-412b57bfffb0",
"created_at": "2015-07-31T06:53:17Z",
"updated_at": null
},
"entity": {
"host": "nodeapp",
"path": "",
"domain_guid": "c3c27b28-9fef-4130-8942-41dbeb8220a0",
"space_guid": "6ffcaf95-f30b-41b6-88ce-d67f59584e89",
"domain_url": "/v2/domains/c3c27b28-9fef-4130-8942-41dbeb8220a0",
"space_url": "/v2/spaces/6ffcaf95-f30b-41b6-88ce-d67f59584e89",
"apps_url": "/v2/routes/2489386f-973b-45db-bc86-412b57bfffb0/apps"
}
}
]
}
}

]
}
Connected, dumping recent logs for app nodeapp in org ronak / space
ronak as admin...

FAILED
Error dialing loggregator server: Get
https://loggregator.cf.ronak.com:4443/recent?app=41657738-cc7c-4237-ab52-e4f9683e16f4:
EOF.
Please ask your Cloud Foundry Operator to check the platform
configuration (loggregator endpoint is
wss://loggregator.cf.ronak.com:4443).
FAILED
Error dialing loggregator server: Get
https://loggregator.cf.ronak.com:4443/recent?app=41657738-cc7c-4237-ab52-e4f9683e16f4:
EOF.
Please ask your Cloud Foundry Operator to check the platform
configuration (loggregator endpoint is
wss://loggregator.cf.ronak.com:4443).


----------------------------------------------------------------------------------------------------------


Please go through all my above research and let me know what can be
done to resolve this issue??


Thanks
Ronak


Re: AWS deployment manifest with HAproxy

CF Runtime
 

Also Stephen, the templates by default attempt to use an ELB named
cfrouter. So if you want to try to use an ELB again, just create one with
that name and when you deploy BOSH should connect it to your routers.

In either case, you shouldn't need to worry about the DEAs, those are
behind the routers. The only thing the load balancer talks to are the
routers.

Joseph
CF Release Integration Team

On Mon, Aug 3, 2015 at 12:50 AM, Amit Gupta <agupta(a)pivotal.io> wrote:

Hi Stephen,

You generally never want to alter the manifest templates unless you're
making a PR with general improvements to the templates. Customizing your
own deployment should be done either within your stub(s), or modifying your
spiff-generated manifest with your desired changes before deploying.

Try making the following additions to your stub:

jobs:
- name: ha_proxy_z1
instances: 1
networks:
- name: ha_proxy_z1_elastic
static_ips: [YOUR_STATIC_IP_HERE]
- name: cf1
default: [gateway, dns]

networks:
- name: ha_proxy_z1_elastic # Add this network to the existing cf1 and
cf2 networks, don't remove those
type: vip

resource_pools:
- name: router_z1
cloud_properties:
elbs: []
- name: router_z2
cloud_properties:
elbs: []

See if that works for you. You will need to make sure that you've
configured DNS records so that your system domain and app domains point to
YOUR_STATIC_IP for ha_proxy. If you're already using
YOUR_STATIC_IP.xip.io as your system and apps domains, then this will
work without having to create any DNS records.

Best,
Amit

On Sun, Aug 2, 2015 at 11:11 PM, Stephen Knight <sknight(a)pivotal.io>
wrote:

Hi All,

The default manifests for CF seem to use ELB's on AWS for load balancing,
I am still getting to grips with manifests so in the meantime, can anyone
tell me how you would insert an HAproxy with an elastic IP into a standard
manifest?

And should it go in the stub or in the cf-infrastructure-xxx.yml file? As
well as ensuring that the DEA pool goes behind the LB pair?

I'm using spiff as per the deployment instructions on Github, filling out
the spec/fixtures/stub but I still can't get HAproxy to deploy despite
trying to munge something together from other manifests.

Thx
Stephen

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

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


Re: AWS deployment manifest with HAproxy

Amit Kumar Gupta
 

Hi Stephen,

You generally never want to alter the manifest templates unless you're
making a PR with general improvements to the templates. Customizing your
own deployment should be done either within your stub(s), or modifying your
spiff-generated manifest with your desired changes before deploying.

Try making the following additions to your stub:

jobs:
- name: ha_proxy_z1
instances: 1
networks:
- name: ha_proxy_z1_elastic
static_ips: [YOUR_STATIC_IP_HERE]
- name: cf1
default: [gateway, dns]

networks:
- name: ha_proxy_z1_elastic # Add this network to the existing cf1 and cf2
networks, don't remove those
type: vip

resource_pools:
- name: router_z1
cloud_properties:
elbs: []
- name: router_z2
cloud_properties:
elbs: []

See if that works for you. You will need to make sure that you've
configured DNS records so that your system domain and app domains point to
YOUR_STATIC_IP for ha_proxy. If you're already using YOUR_STATIC_IP.xip.io
as your system and apps domains, then this will work without having to
create any DNS records.

Best,
Amit

On Sun, Aug 2, 2015 at 11:11 PM, Stephen Knight <sknight(a)pivotal.io> wrote:

Hi All,

The default manifests for CF seem to use ELB's on AWS for load balancing,
I am still getting to grips with manifests so in the meantime, can anyone
tell me how you would insert an HAproxy with an elastic IP into a standard
manifest?

And should it go in the stub or in the cf-infrastructure-xxx.yml file? As
well as ensuring that the DEA pool goes behind the LB pair?

I'm using spiff as per the deployment instructions on Github, filling out
the spec/fixtures/stub but I still can't get HAproxy to deploy despite
trying to munge something together from other manifests.

Thx
Stephen

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


Re: Any problem with cloudfoundry.org?

Noburou TANIGUCHI
 

I can access them now.
Thanks!


Tushar Dadlani wrote
Hi all,

The issue has been resolved and all docs links should be back up. Sorry
for
the inconvenience.

Thanks,
Tushar

On Sun, Aug 2, 2015 at 6:55 PM, James Bayer &lt;
jbayer@
&gt; wrote:

linux foundation IT team is looking into the issue.

On Sun, Aug 2, 2015 at 6:37 PM, Dieu Cao &lt;
dcao@
&gt; wrote:

Hi all,

You can reach those apps for now at their cfapps.io addresses.
We're reaching out to the foundation to have them look into why the ip
for *.cloudfoundry.org is not redirecting properly.

http://apidocs.cfapps.io/
http://docs-cloudfoundry-production.cfapps.io/

-Dieu

On Sun, Aug 2, 2015 at 5:41 PM, Amit Gupta &lt;
agupta@
&gt; wrote:

Yes, I'm seeing the same issue. Will investigate.

Best,
Amit


On Sunday, August 2, 2015, Noburou TANIGUCHI &lt;
dev(a).m001
&gt; wrote:

Right now, I cannnot access:

* https://docs.cloudfoundry.org/
* http://apidocs.cloudfoundry.org/

I am able to access http://blog.cloudfoundry.org/

I'm accessing from Japan.

Don't you have any trouble?



--
View this message in context:
http://cf-dev.70369.x6.nabble.com/cf-dev-Any-problem-with-cloudfoundry-org-tp1018.html
Sent from the CF Dev mailing list archive at Nabble.com.
_______________________________________________
cf-dev mailing list
cf-dev(a).cloudfoundry
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev(a).cloudfoundry
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

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


--
Thank you,

James Bayer

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


--
- Tushar Dadlani
CloudOps at CF

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




--
View this message in context: http://cf-dev.70369.x6.nabble.com/cf-dev-Any-problem-with-cloudfoundry-org-tp1018p1027.html
Sent from the CF Dev mailing list archive at Nabble.com.


Re: Troubleshooting tips ...

Vish
 

Thanks CFR.

On Friday, 31 July 2015 9:33 PM, CF Runtime <cfruntime(a)gmail.com> wrote:


Set CF_TRACE=true to see the exact request that results in the 404. Most likely it is a request to api.cf.fxlab.net/v2/info. Double check that that url does in fact return a 404.
From there, the problem will probably be in either the router or the api instance. If you ssh onto the api instance, you can try to curl localhost:9022/v2/info to see if it is working.
On Fri, Jul 31, 2015 at 5:55 AM, Vishwanath V <thelinuxguyis(a)yahoo.co.in> wrote:

Hi Folks,
I see the below  error , when trying to connect to api end point :
cf api api.cf.fxlab.net --skip-ssl-validation
Setting api endpoint to api.cf.fxlab.net...
FAILED
Server error, status code: 404, error code: 0, message:


This was working yesterday, I already checked that all the cf components are active and running.
Need pointers on where to start the troubleshooting.

Kindly assist.
Regards,Vish.

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


AWS deployment manifest with HAproxy

Stephen Knight
 

Hi All,

The default manifests for CF seem to use ELB's on AWS for load balancing, I
am still getting to grips with manifests so in the meantime, can anyone
tell me how you would insert an HAproxy with an elastic IP into a standard
manifest?

And should it go in the stub or in the cf-infrastructure-xxx.yml file? As
well as ensuring that the DEA pool goes behind the LB pair?

I'm using spiff as per the deployment instructions on Github, filling out
the spec/fixtures/stub but I still can't get HAproxy to deploy despite
trying to munge something together from other manifests.

Thx
Stephen


Re: Any problem with cloudfoundry.org?

Tushar Dadlani
 

Hi all,

The issue has been resolved and all docs links should be back up. Sorry for
the inconvenience.

Thanks,
Tushar

On Sun, Aug 2, 2015 at 6:55 PM, James Bayer <jbayer(a)pivotal.io> wrote:

linux foundation IT team is looking into the issue.

On Sun, Aug 2, 2015 at 6:37 PM, Dieu Cao <dcao(a)pivotal.io> wrote:

Hi all,

You can reach those apps for now at their cfapps.io addresses.
We're reaching out to the foundation to have them look into why the ip
for *.cloudfoundry.org is not redirecting properly.

http://apidocs.cfapps.io/
http://docs-cloudfoundry-production.cfapps.io/

-Dieu

On Sun, Aug 2, 2015 at 5:41 PM, Amit Gupta <agupta(a)pivotal.io> wrote:

Yes, I'm seeing the same issue. Will investigate.

Best,
Amit


On Sunday, August 2, 2015, Noburou TANIGUCHI <dev(a)nota.m001.jp> wrote:

Right now, I cannnot access:

* https://docs.cloudfoundry.org/
* http://apidocs.cloudfoundry.org/

I am able to access http://blog.cloudfoundry.org/

I'm accessing from Japan.

Don't you have any trouble?



--
View this message in context:
http://cf-dev.70369.x6.nabble.com/cf-dev-Any-problem-with-cloudfoundry-org-tp1018.html
Sent from the CF Dev mailing list archive at Nabble.com.
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

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


--
Thank you,

James Bayer

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

--
- Tushar Dadlani
CloudOps at CF


Re: Any problem with cloudfoundry.org?

James Bayer
 

linux foundation IT team is looking into the issue.

On Sun, Aug 2, 2015 at 6:37 PM, Dieu Cao <dcao(a)pivotal.io> wrote:

Hi all,

You can reach those apps for now at their cfapps.io addresses.
We're reaching out to the foundation to have them look into why the ip for
*.cloudfoundry.org is not redirecting properly.

http://apidocs.cfapps.io/
http://docs-cloudfoundry-production.cfapps.io/

-Dieu

On Sun, Aug 2, 2015 at 5:41 PM, Amit Gupta <agupta(a)pivotal.io> wrote:

Yes, I'm seeing the same issue. Will investigate.

Best,
Amit


On Sunday, August 2, 2015, Noburou TANIGUCHI <dev(a)nota.m001.jp> wrote:

Right now, I cannnot access:

* https://docs.cloudfoundry.org/
* http://apidocs.cloudfoundry.org/

I am able to access http://blog.cloudfoundry.org/

I'm accessing from Japan.

Don't you have any trouble?



--
View this message in context:
http://cf-dev.70369.x6.nabble.com/cf-dev-Any-problem-with-cloudfoundry-org-tp1018.html
Sent from the CF Dev mailing list archive at Nabble.com.
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

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

--
Thank you,

James Bayer


Re: Any problem with cloudfoundry.org?

Dieu Cao <dcao@...>
 

Hi all,

You can reach those apps for now at their cfapps.io addresses.
We're reaching out to the foundation to have them look into why the ip for
*.cloudfoundry.org is not redirecting properly.

http://apidocs.cfapps.io/
http://docs-cloudfoundry-production.cfapps.io/

-Dieu

On Sun, Aug 2, 2015 at 5:41 PM, Amit Gupta <agupta(a)pivotal.io> wrote:

Yes, I'm seeing the same issue. Will investigate.

Best,
Amit


On Sunday, August 2, 2015, Noburou TANIGUCHI <dev(a)nota.m001.jp> wrote:

Right now, I cannnot access:

* https://docs.cloudfoundry.org/
* http://apidocs.cloudfoundry.org/

I am able to access http://blog.cloudfoundry.org/

I'm accessing from Japan.

Don't you have any trouble?



--
View this message in context:
http://cf-dev.70369.x6.nabble.com/cf-dev-Any-problem-with-cloudfoundry-org-tp1018.html
Sent from the CF Dev mailing list archive at Nabble.com.
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


Re: Garden is Moving!

Gwenn Etourneau
 

Awesome, yes it's a big win for everyome and according to Solomonstre tweet
is just natural things
"@chanezon <https://twitter.com/chanezon/> @wattersjames
<https://twitter.com/wattersjames/> @charlesfitz
<https://twitter.com/charlesfitz/> @diogomonica
<https://twitter.com/diogomonica/> @justinjsmith
<https://twitter.com/justinjsmith/> nice! We did runC partly based on
cloudfoundry feedback."

On Sat, Aug 1, 2015 at 12:47 PM, James Bayer <jbayer(a)pivotal.io> wrote:

thanks julz for summarizing all of this. i'm very excited that cloud
foundry will be able to use runc and contribute to the open container
initiative. by joining with the other members and working together, we'll
be able to use the same base runtime as docker, coreos and others. we'll
also preserve the flexibility to do the innovations and user experience we
want for CF users above the core container runtime. this seems like a big
win for everyone.

On Fri, Jul 31, 2015 at 3:06 PM, Deepak Vij (A) <deepak.vij(a)huawei.com>
wrote:

Hi Julz & the whole garden team, it is great to know that Garden
Container is moving towards Open-Container-Project (OCP) App-Container
specifications. Great work.

I am hoping that down the road we will also see App Container Pods
(Co-locating Containers) capabilities enabled as well. A pod is a list of
apps that will be launched together inside a shared execution context (
single Unit of Deployment, migration etc. sharing IP address Space, Storage
etc.). Kubernetes also supports similar Pod concept.

Pod architecture allows me to enable design patters such as Sidecar,
Ambassador & Adaptor. All of this is really helpful from the standpoint of
refactoring the core telecom capabilities such as vEPC (virtual Evolved
packet Core network) and many more NFV/telecom capabilities - Network
Function Virtualization.

- Deepak Vij

----------------------------------------------------------------------

Message: 1
Date: Fri, 31 Jul 2015 18:49:25 +0100
From: Julz Friedman <julz.friedman(a)gmail.com>
To: "Discussions about Cloud Foundry projects and the system overall."
<cf-dev(a)lists.cloudfoundry.org>
Subject: [cf-dev] Garden is Moving!
Message-ID:
<
CAHfHzfOrrdEn_QBZwnoq7qQtXbBW1K2fk-NbbqgLSKaacMcPsw(a)mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hi cf-dev, I?d like to discuss some exciting changes the Garden team is
planning to make in Diego?s container subsystem, Garden.

Garden? What?s that?

Garden is the containerisation layer used by Diego. Garden provides a
platform-neutral, lightweight container abstraction that can be backed by
multiple backends (most importantly, a Linux backend and a Windows
backend). Currently the linux backend is based on our own code which
evolved from Warden and which has been used to power Cloud Foundry for
many
years. Garden enables diego to support buildpack apps and docker apps (via
the Linux backend) and windows apps (via the Windows backend).

So: What's changing?

We're planning to use runC [1] as the Linux backend for Garden.

Why?

Garden has always been an unopinionated container system - we like to have
the opinionation happen at the higher levels (i.e. in Diego). Docker, on
the other hand, is quite an opinionated container technology: it tightly
couples containerisation and the user experience (which is one of the
reasons docker is so great to use, I?m not knocking docker here!).
Recently, docker and others (including IBM and Pivotal) have come together
under the Open Container Initiative to spin out an unopinionated common
containerisation runtime, ?runC?, which gives us a fantastic opportunity
to
be part of this community while letting us ensure we can retain the
flexibility required by our broader use cases. RunC is a reference
implementation of the Open Container spec, which means both Docker and
Cloud Foundry will be running the same code, and both Docker and Cloud
Foundry apps will be using Open Containers.

Using runC as the garden backend has two major advantages. Firstly it lets
us reuse some awesome code and be part of the Open Container community.
Secondly it means CF applications will be using not only the same kernel
primitives as docker apps (as they already are today), but also the exact
same runtime container engine. This will minimise incompatibility for our
docker lifecycle and result in a first class experience for users, as well
as letting us reuse and contribute back to a great open-source code base.
We have some remaining features in the Garden Linux backend that we?d like
to see in RunC, but we?re excited to engage with the Open Container
community to close these gaps.

What about regular CF buildpack apps and the other nice features of
Garden?

Moving to runC gives us all the above advantages without compromising our
ability to also deliver the buildpack-based platform-centric workflows
that
make CF great. We will retain the garden abstraction to make it easy for
Diego to support both buildpack apps, windows apps and docker apps, and we
will maintain a small layer above runC to manage the containers, pull down
native warden and docker root filesystems, let us perform live upgrades
and
so on.

Why not use the full docker-engine as the backend?

Docker-engine has both more capabilities than we need at the layer Garden
runs and different opinions than Cloud Foundry currently requires. This
means it?s harder for us to maintain (because it?s larger and does more
stuff), harder for us to contribute to (for similar reasons) and for some
of our use cases (particularly with Diego?s more generic lifecycles) we?d
have to actively work around things that would be quite easy to expose if
we use runC directly (for example docker-engine intentionally doesn?t
support signalling `docker exec`ed processes, which is required by
Diego[2]).

Most of the reasons you might want to use docker-engine (e.g. being able
to
?docker push?) make much more sense to expose at the platform level in a
multi-host environment (you want to push to the cluster, not a single
host)
or need to be integrated with multi-tenancy (which again should happen at
the platform level - you need access control on storage and networks to
integrate with the rest of a multi-tenant platform). For these reasons
Cloud Foundry prefers to implement many features at the Diego layer
whereas
docker-engine implements some of these capabilities at the host layer. As
the capabilities for running distributed applications in containers
continue to evolve, CF prefers the flexibility to implement the opinions
of
our developers and community for areas like networking and storage even if
those may differ from other orchestration solutions like docker-engine,
and
in turn Garden needs to retain that flexibility.

We also note that many new features have come to runC first (e.g. criu
snapshot restore and - importantly for us - user namespaces were first
available in runC before being added to docker-engine; at the time of
writing these are still not fully available in docker-engine). We?d like
to
be able to consume new features as they come out in runC, rather than
waiting for them to make it in to docker-engine. We also hope to be
contributing new features of our own and this is much easier for us to
accomplish against the smaller surface area of runC, and within the open
context of the Open Container Initiative.

When will this happen?

Our first goal is completing the work of improving Garden?s security
profile around supporting docker apps in production, we're about two weeks
out from this according to Tracker and plan to do this with the current
code. As soon as we hit this milestone we plan to shift our focus to runC.
We have an initial prototype working and will iterate quickly to bring
this
to production quality and switch over when we feel confident.


I?m excited to hear the community?s views and input on this, so let us
know
what you think!


Thanks!

- Julz, on behalf the Garden Team

[1]: https://github.com/opencontainers/runc

[2]: https://github.com/docker/docker/pull/9167,
https://github.com/docker/docker/pull/9402

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


--
Thank you,

James Bayer

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


Re: How to use /v2/app_usage_events for billing purpose

王小锋 <zzuwxf at gmail.com...>
 

This is very helpful, thanks for help.

2015-08-02 12:06 GMT+08:00 CF Runtime <cfruntime(a)gmail.com>:

The app_usage_events endpoint was not designed to be a live billing
interface. Typically what you would do is have another app that polls the
endpoint, collects the billing data, and saves it off in a format that is
easy to generate bills from.


http://apidocs.cloudfoundry.org/214/app_usage_events/list_all_app_usage_events.html

This is the reason the app_usage_events endpoint has the after_guid query
parameter. Ideally your billing system would keep track of the last guid
that it fetched, then when it polled again, it could get everything after
that event.

Be aware of the warnings at the top of the api docs. In general you should
not process app usage events that are close to the current time (within a
couple of minutes is probably fine). The reason for this is that you could
miss events that are being created in a transaction that has not yet been
committed.

The destructively_purge_all_and_reseed_started_apps endpoint is not
intended to be used monthly. This endpoint exists because the billing data
only goes back so far, and if you haven't been collecting it from the
very beginning, you don't know what apps have been started before the usage
data starts. What you should do is get your billing infrastructure in
place, then call this endpoint one time. This will seed the usage events
feed with a STARTED record for each app that is currently running. You can
then just process the changes you get from the usage endpoint after that.

And of course, as Noburou mentioned, you can always increase the
cc.app_usage_events.cutoff_age_in_days manifest parameter.

Joseph
OSS Release Integration Team

On Tue, Jul 28, 2015 at 6:10 PM, 王小锋 <zzuwxf(a)gmail.com> wrote:

Hi, there

I have deployed CF env in AWS, and there are some applications running on
it. I found one useful article talking about billing CF users :
https://blog.starkandwayne.com/2015/01/22/billing-your-cloud-foundry-users/
.

I tried cf curl /v2/app_usage_events in my CF env, I found that I could
only retrieve app events for one month, is this exepcted? Is it able to
change the default "one month" in CF deployment manifest?

If I want to track the app usage for one org, for example org1, and org1
have one app running for more than one month, then there will be no app
usage for this long running app, then how to meter such app? Should I list
all apps available in the org currenlty, if the app is not in the app usage
event, I could image the app has been created more than one month?

Another thing, if I want to bill app usage by month, should I call
/v2/app_usage_events/destructively_purge_all_and_reseed_started_apps at the
end of each month?

Is there anyone have done similar things in the past and share your
experience? Many thanks.

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

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


Re: Any problem with cloudfoundry.org?

Amit Kumar Gupta
 

Yes, I'm seeing the same issue. Will investigate.

Best,
Amit

On Sunday, August 2, 2015, Noburou TANIGUCHI <dev(a)nota.m001.jp> wrote:

Right now, I cannnot access:

* https://docs.cloudfoundry.org/
* http://apidocs.cloudfoundry.org/

I am able to access http://blog.cloudfoundry.org/

I'm accessing from Japan.

Don't you have any trouble?



--
View this message in context:
http://cf-dev.70369.x6.nabble.com/cf-dev-Any-problem-with-cloudfoundry-org-tp1018.html
Sent from the CF Dev mailing list archive at Nabble.com.
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org <javascript:;>
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


Any problem with cloudfoundry.org?

Noburou TANIGUCHI
 

Right now, I cannnot access:

* https://docs.cloudfoundry.org/
* http://apidocs.cloudfoundry.org/

I am able to access http://blog.cloudfoundry.org/

I'm accessing from Japan.

Don't you have any trouble?



--
View this message in context: http://cf-dev.70369.x6.nabble.com/cf-dev-Any-problem-with-cloudfoundry-org-tp1018.html
Sent from the CF Dev mailing list archive at Nabble.com.


Re: How to use /v2/app_usage_events for billing purpose

CF Runtime
 

The app_usage_events endpoint was not designed to be a live billing
interface. Typically what you would do is have another app that polls the
endpoint, collects the billing data, and saves it off in a format that is
easy to generate bills from.

http://apidocs.cloudfoundry.org/214/app_usage_events/list_all_app_usage_events.html

This is the reason the app_usage_events endpoint has the after_guid query
parameter. Ideally your billing system would keep track of the last guid
that it fetched, then when it polled again, it could get everything after
that event.

Be aware of the warnings at the top of the api docs. In general you should
not process app usage events that are close to the current time (within a
couple of minutes is probably fine). The reason for this is that you could
miss events that are being created in a transaction that has not yet been
committed.

The destructively_purge_all_and_reseed_started_apps endpoint is not
intended to be used monthly. This endpoint exists because the billing data
only goes back so far, and if you haven't been collecting it from the
very beginning, you don't know what apps have been started before the usage
data starts. What you should do is get your billing infrastructure in
place, then call this endpoint one time. This will seed the usage events
feed with a STARTED record for each app that is currently running. You can
then just process the changes you get from the usage endpoint after that.

And of course, as Noburou mentioned, you can always increase the
cc.app_usage_events.cutoff_age_in_days manifest parameter.

Joseph
OSS Release Integration Team

On Tue, Jul 28, 2015 at 6:10 PM, 王小锋 <zzuwxf(a)gmail.com> wrote:

Hi, there

I have deployed CF env in AWS, and there are some applications running on
it. I found one useful article talking about billing CF users :
https://blog.starkandwayne.com/2015/01/22/billing-your-cloud-foundry-users/
.

I tried cf curl /v2/app_usage_events in my CF env, I found that I could
only retrieve app events for one month, is this exepcted? Is it able to
change the default "one month" in CF deployment manifest?

If I want to track the app usage for one org, for example org1, and org1
have one app running for more than one month, then there will be no app
usage for this long running app, then how to meter such app? Should I list
all apps available in the org currenlty, if the app is not in the app usage
event, I could image the app has been created more than one month?

Another thing, if I want to bill app usage by month, should I call
/v2/app_usage_events/destructively_purge_all_and_reseed_started_apps at the
end of each month?

Is there anyone have done similar things in the past and share your
experience? Many thanks.

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


Re: Recreating uaadb and ccdb databases

CF Runtime
 

No, there are no special scripts that run on job instance creation,
everything is embedded in the startup control scripts. So while recreate
would work too, restart should be fine.

Joseph
OSS Release Integration Team

On Sat, Aug 1, 2015 at 5:31 AM, James Bayer <jbayer(a)pivotal.io> wrote:

joseph, did you mean "bosh recreate" instead of "bosh restart"?

On Sat, Aug 1, 2015 at 5:28 AM, CF Runtime <cfruntime(a)gmail.com> wrote:

If you are using the default postgres job, you should just be able to
"bosh restart postgres_z1/0". This will create both the databases, but they
will not have the schemas.

The individual jobs should recreate the schemas, so you'll probably need
to "bosh restart api_z1/0" and "bosh restart uaa_z1/0".

Joseph
OSS Release Integration Team

On Sat, Aug 1, 2015 at 3:36 AM, rmi <rishi.investigate(a)gmail.com> wrote:

Hi Amit - since this is a fresh install I an just trying to recreate
ccdb and
uaadb from scratch. What is the best way of deleting/redeploying my
environment? Note that due to I am only able to use cf_nise installer
for
this deployment. This is another reason I wanted to just recreate dbs if
possible.

Thanks.



--
View this message in context:
http://cf-dev.70369.x6.nabble.com/cf-dev-Recreating-uaadb-and-ccdb-databases-tp1007p1011.html
Sent from the CF Dev mailing list archive at Nabble.com.
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

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


--
Thank you,

James Bayer

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


Re: V3 Rest API

Dieu Cao <dcao@...>
 

Hi!

Yes, there are plans to change the cf command line to use the v3 cloud
controller rest api.
You can follow along on progress on stories related to v3 in the CAPI
backlog [1] looking at the process types epic [2].
The largest chunks of work left involve modeling service bindings in v3 and
making the transition for users from v2 apps to v3 apps as seamless as
possible.
Our plan is that we'll be able to migrate v2 app to the v3 set of
equivalent objects and to modify the v2 end points such that they will
update the equivalent v3 objects. The goal here is that if you are using a
client still using the v2 end points, things should continue to just work
and if you have a user with some clients using v2 and some clients using
v3, it should also be seamless.
As we go through different phases of the migration, we plan to work with
the cli on updating commands to use the new v3 end points.
I'm hoping that we start this work at some point in September.

You can find documentation on the v3 api here [3] in the sections marked
experimental.
You can find basic instructions on how to create and push a v3 app here [4]
We are also working on a v3 style guide that we hope to share with the
community in the next week or so for feedback.
You can also find this talk from cf summit describing why we embarked on
v3. [5]

-Dieu


[1] https://www.pivotaltracker.com/n/projects/966314
[2] https://www.pivotaltracker.com/epic/show/1334418
[3] http://apidocs.cloudfoundry.org/214/
[4]
https://github.com/cloudfoundry/cloud_controller_ng/blob/master/docs/create_v3_app.md
[5]
https://www.youtube.com/watch?v=Cz3rKCHicf4&index=33&list=PLhuMOCWn4P9g-UMN5nzDiw78zgf5rJ4gR

On Fri, Jul 31, 2015 at 11:39 AM, Ethan Vogel <evogel(a)us.ibm.com> wrote:

Can anyone answer these questions please:

Are there plans to change the cf command line to use the V3 Rest API? If
so, when?
Where can I find documentation on the V3 API?

Thanks,
Ethan

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


Re: Php build pack offline version availability

James Bayer
 

did you try building it with the "cached" option as referenced in the
readme [1]:

BUNDLE_GEMFILE=cf.Gemfile bundle exec buildpack-packager cached


[1] https://github.com/cloudfoundry/php-buildpack#building

On Fri, Jul 31, 2015 at 5:25 PM, Amishi Shah (amishish) <amishish(a)cisco.com>
wrote:

Hi team,

We are a team at Cisco trying to use the Buildpack for Php-Httpd. We tried
couple of ways,

1. Cloning a git repo and creating the build pack, uploading the same
and using the same for the app.
2. Downloading the readymade build pack available in the github
releases pages and uploading, using the same for the app.

What we are looking for is an offline version, both of these build packs
connects to internet while we are deploying the app.

The details are as below.

AMISHISH-M-91EG:webapp ashah$ cf push

Using manifest file
*/Users/ashah/workspace/Symphony/sample_httpd_app/webapp/manifest.yml*


Using stack *cflinuxfs2*...

*OK*

Creating app *sample_app* in org *admin* / space *skyfall* as *admin*...

*OK*


Using route *sample-app.203.35.248.123.xip.io
<http://sample-app.203.35.248.123.xip.io>*

Binding *sample-app.203.35.248.123.xip.io
<http://sample-app.203.35.248.123.xip.io>* to *sample_app*...

*OK*


Uploading *sample_app*...

Uploading app files from:
/Users/ashah/workspace/Symphony/sample_httpd_app/webapp

Uploading 185, 1 files

Done uploading

*OK*


Starting app *sample_app* in org *admin* / space *skyfall* as *admin*...

-----> Downloaded app package (4.0K)

-------> Buildpack version 4.0.0

Installing HTTPD

Downloaded [
https://pivotal-buildpacks.s3.amazonaws.com/php/binaries/trusty/httpd/2.4.12/httpd-2.4.12.tar.gz]
to [/tmp]

Installing PHP

PHP 5.5.27

Downloaded [
https://pivotal-buildpacks.s3.amazonaws.com/php/binaries/trusty/php/5.5.27/php-5.5.27.tar.gz]
to [/tmp]

Finished: [2015-07-31 21:28:46.871154]


-----> Uploading droplet (51M)


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

1 of 1 instances running


*App started*



*OK*


App *sample_app* was started using this command `$HOME/.bp/bin/start`


Showing health and status for app *sample_app* in org *admin* / space
*skyfall* as *admin*...

*OK*


*requested state:* started

*instances:* 1/1

*usage:* 64M x 1 instances

*urls:* sample-app.203.35.248.123.xip.io

*last uploaded:* Fri Jul 31 21:28:35 UTC 2015

*stack:* cflinuxfs2

*buildpack:* readymade_httpd_buildpack


*state* *since* *cpu* *memory*
*disk* *details*

*#0* running 2015-07-31 02:29:39 PM 0.0% 40.3M of 64M 136.6M of
1G


Do we have any offline Php-httpd buildpack available? We want the build
pack which would be sufficient enough and it works even without the
internet connectivity.


Your timely response will be really appreciated.


Thanks,

Amishi Shah

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


--
Thank you,

James Bayer

8361 - 8380 of 9426