curl exit code 6 means DNS failed. xip.io is flaky, so we this often in
our dev environments where our app domains tend to be HA_PROXY_IP.xip.io.

The CATS expect the apps to finish uploading, staging, and running in 2
minutes, although in reality this can take longer depending on the size of
the app, the number of dependencies it needs to fetch, etc. The CATS apps
are designed to generally get up and running within the 2 minute period,
but can't account for all possible types of network slowness.

openjdk is 43M and downloading on my machine takes about 7 seconds. In
your test output, we see it took 55 seconds. The last thing it was trying
to do was upload the 51M droplet, then at some point the 2min time limit
for everything to finish gets hit and the test fails. My guess is you're
experiencing network issues. If you can't fix those, you may want to
configure a more lenient push timeout in your acceptance_tests errand:


https://github.com/cloudfoundry/cf-release/blob/5fa14702bca4d36d1fdc7241c63d0b3e40dcbe90/jobs/acceptance-tests/spec#L69

Note, the above value is in seconds, so for e.g. if you want 3 minutes,
set it to 180.

On Fri, Sep 4, 2015 at 10:52 AM, Quintessence Anx <qanx(a)starkandwayne.com>
wrote:

Good afternoon!

Our CF deployment fails 4 of the CATs. I have put the errors and the full
output in a GIST here:

https://gist.github.com/qanx/677d64df27d911f39acd

Summary:

* There's a curl error even though the curl succeeds when I run it in
terminal.
* There's a Java buildpack error I can't figure out.
* There are two other buildpack errors, one each for the binary and
staticfile buildpacks. I believe these are expected, though, since we don't
have these two buildpacks in our deployment.

Does anyone know what could be causing these failures?

Thanks!

Quinn

ok, so we can validate that

uaac target http://localhost:8080
uaac token client get admin -s <your admin client secret>
uaac clients

Should show your 'cf' client in the list

then we can do

uaac token owner get cf <username> -s "" -p <user password>

and if that works, we can take it to the next step



On Fri, Sep 4, 2015 at 1:26 PM, kyle havlovitz <kylehav(a)gmail.com> wrote:

I started the uaa by building from the tagged version in cf-release v215
and running it via tomcat with a custom config file, but I didn't specify a
database. I have both a cf and admin section in the uaa clients config:

cf:

id: cf
override: true
authorized-grant-types: password,implicit,refresh_token
authorities: uaa.none
scope:
cloud_controller.read,cloud_controller.write,openid,password.write,cloud_controller.admin,scim.read,scim.write
secret: 'xxxxxxxxxx'

admin:

id: admin
authorized-grant-types: client_credentials
authorities:
clients.read,clients.write,clients.secret,password.write,scim.read,uaa.admin
scope: read,write,password
resource-ids: clients
secret: 'xxxxxxxxxx'


On Fri, Sep 4, 2015 at 3:09 PM, Filip Hanik <fhanik(a)pivotal.io> wrote:

ok, so the URL you have is /oauth/token, that's fine. your trace returns

"authorization_endpoint":"http://localhost:8080","token_endpoint":"
http://localhost:8080/uaa"

indicating that there is a misconfiguration somewhere, but we can fix
that later.

How did you start the UAA? Are you sure that your UAA has a client named
'cf' in its database?



On Fri, Sep 4, 2015 at 1:05 PM, kyle havlovitz <kylehav(a)gmail.com>
wrote:

Running that command against /uaa/oauth/token gives just a redirect to
/login. Doing it with /oauth/token gives a 401 unauthorized, same as the cf
cli.

What do you mean by deploy it as root "/"? As in, a override the url it
hosts the endpoints at?

I started the uaa by building from the tagged version in cf-release v215
and running it via tomcat with a custom config file, but I didn't specify a
database. I have both a cf and admin section in the uaa clients config:

cf:

id: cf
override: true
authorized-grant-types: password,implicit,refresh_token
authorities: uaa.none
scope:
cloud_controller.read,cloud_controller.write,openid,password.write,cloud_controller.admin,scim.read,scim.write
secret: 'xxxxxxxxxx'

admin:

id: admin
authorized-grant-types: client_credentials
authorities:
clients.read,clients.write,clients.secret,password.write,scim.read,uaa.admin
scope: read,write,password
resource-ids: clients
secret: 'xxxxxxxxxx'


On Fri, Sep 4, 2015 at 3:09 PM, Filip Hanik <fhanik(a)pivotal.io> wrote:

ok, so the URL you have is /oauth/token, that's fine. your trace returns

"authorization_endpoint":"http://localhost:8080","token_endpoint":"
http://localhost:8080/uaa"

indicating that there is a misconfiguration somewhere, but we can fix
that later.

How did you start the UAA? Are you sure that your UAA has a client named
'cf' in its database?



On Fri, Sep 4, 2015 at 1:05 PM, kyle havlovitz <kylehav(a)gmail.com> wrote:

Running that command against /uaa/oauth/token gives just a redirect to
/login. Doing it with /oauth/token gives a 401 unauthorized, same as the cf
cli.

What do you mean by deploy it as root "/"? As in, a override the url it
hosts the endpoints at?

ok, so the URL you have is /oauth/token, that's fine. your trace returns

"authorization_endpoint":"http://localhost:8080","token_endpoint":"
http://localhost:8080/uaa"

indicating that there is a misconfiguration somewhere, but we can fix that
later.

How did you start the UAA? Are you sure that your UAA has a client named
'cf' in its database?



On Fri, Sep 4, 2015 at 1:05 PM, kyle havlovitz <kylehav(a)gmail.com> wrote:

Running that command against /uaa/oauth/token gives just a redirect to
/login. Doing it with /oauth/token gives a 401 unauthorized, same as the cf
cli.

What do you mean by deploy it as root "/"? As in, a override the url it
hosts the endpoints at?

Running that command against /uaa/oauth/token gives just a redirect to
/login. Doing it with /oauth/token gives a 401 unauthorized, same as the cf
cli.

What do you mean by deploy it as root "/"? As in, a override the url it
hosts the endpoints at?

Hi,
(This is a post in proxy of my collegue.)

There are so many hard-coded dropsonde destinations (actually each of them
is a metron's listening port) in multiple repositories, while metron's
listening port itself is configurable.

Below is the list that we've found it is hard-coded:



Are they going to be finally configurable in the near future, or is there
any reason to hard-code them?

Thanks in advance.



-----
I'm not a ...
noburou taniguchi
--
View this message in context:
http://cf-dev.70369.x6.nabble.com/So-many-hard-coded-dropsonde-destinations-to-metrons-tp1474.html
Sent from the CF Dev mailing list archive at Nabble.com.

cf login

API endpoint: http://localhost:8181
REQUEST: [2015-09-04T17:53:29Z]
GET /v2/info HTTP/1.1
Host: localhost:8181
Accept: application/json
Content-Type: application/json
User-Agent: go-cli 6.12.3-c0c9a03 / linux


RESPONSE: [2015-09-04T17:53:29Z]
HTTP/1.1 200 OK
Content-Length: 406
Connection: keep-alive
Content-Type: application/json;charset=utf-8
Server: thin
X-Content-Type-Options: nosniff
X-Vcap-Request-Id: 9d81e286-dcae-4673-868a-ea4982713581
{"name":"vcap","build":"2222","support":"http://support.local.example.com","version":2,"description":"CF
v2 test environment","authorization_endpoint":"http://localhost:8080
","token_endpoint":"http://localhost:8080/uaa
","min_cli_version":null,"min_recommended_cli_version":null,"api_version":"2.34.0","app_ssh_endpoint":null,"app_ssh_host_key_fingerprint":null,"logging_endpoint":"ws://
127.0.0.1:9090"}
Warning: Insecure http API endpoint detected: secure https API endpoints
are recommended

REQUEST: [2015-09-04T17:53:29Z]
GET /login HTTP/1.1
Host: localhost:8080
Accept: application/json
Content-Type: application/json
User-Agent: go-cli 6.12.3-c0c9a03 / linux


RESPONSE: [2015-09-04T17:53:29Z]
HTTP/1.1 200 OK
Transfer-Encoding: chunked
Access-Control-Allow-Origin: *
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Cache-Control: no-cache, no-store, max-age=0
Content-Language: en-US
Content-Type: application/json;charset=UTF-8
Date: Fri, 04 Sep 2015 17:53:29 GMT
Expires: 0
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Pragma: no-cache
Pragma: no-cache
Server: Apache-Coyote/1.1
Strict-Transport-Security: max-age=31536000
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
X-Xss-Protection: 1; mode=block
1fd

{"timestamp":"2015-08-05T00:00:41+0000","app":{"version":"2.5.1"},"idpDefinitions":[],"fieldUsernameShow":true,"zone_name":"uaa","commit_id":"eae6724","prompts":{"username":["text","Email"],"password":["password","Password"]},"forgotPasswordLink":"/forgot_password","createAccountLink":"/create_account","links":{"register":"/create_account","passwd":"/forgot_password","login":"
http://localhost:8080/login","uaa":"http://localhost:8080/uaa
"},"entityID":"cloudfoundry-saml-login","linkCreateAccountShow":true}
0


Email> admin
Password>
Authenticating...
REQUEST: [2015-09-04T17:53:37Z]
POST /oauth/token HTTP/1.1
Host: localhost:8080
Accept: application/json
Authorization: [PRIVATE DATA HIDDEN]
Content-Type: application/x-www-form-urlencoded
User-Agent: go-cli 6.12.3-c0c9a03 / linux
grant_type=password&password=[PRIVATE DATA HIDDEN]&scope=&username=admin
RESPONSE: [2015-09-04T17:53:37Z]
HTTP/1.1 401 Unauthorized
Transfer-Encoding: chunked
Access-Control-Allow-Origin: *
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Cache-Control: no-store
Content-Type: application/json
Date: Fri, 04 Sep 2015 17:53:37 GMT
Expires: 0
Pragma: no-cache
Pragma: no-cache
Server: Apache-Coyote/1.1
Www-Authenticate: Basic realm="UAA/client", error="unauthorized",
error_description="Bad credentials"
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
X-Xss-Protection: 1; mode=block
3e
{"error":"unauthorized","error_description":"Bad credentials"}
0

Also: when i do 'uaac token get' with those same credentials, it succeeds.

I'm having an issue with my cloud controller/UAA setup where when I do cf
login I get '401 unauthorized' back, but when I use the uaac command line
tool to get a token it works fine. This makes me think the UAA is working
but something is off with the cloud controller config, but I'm not sure
what. The only strange thing I see is that the CLI is POSTing to
/oauth/token and the uaac goes to /oauth/authorize.

This is all using v215 of cloudfoundry running/built locally and 6.12.3 of
the cli. Is there some endpoint that needs to be set correctly in the cloud
controller config?

Shannon recently pulled the story over into the Routing team's tracker [1]
with the intention to submit a PR for it to the CLI team.

-Dieu
CF CAPI PM

[1] https://www.pivotaltracker.com/story/show/93368928

On Fri, Sep 4, 2015 at 9:09 AM, Mike Youngstrom <youngm(a)gmail.com> wrote:

Route path support has been in the CC and Router for several months now.
What is the status of getting these into the CLI? I did a quick search for
a CLI tracker story and couldn't find one.

Mike

Route path support has been in the CC and Router for several months now.
What is the status of getting these into the CLI? I did a quick search for
a CLI tracker story and couldn't find one.

Mike

i would trace through the various system component logs to see where the
timeout is starting with each component that the client connects to and
seeing if that request came through. by submitting a silly uniquely
identifiable hostname you can usually find something quickly by grepping
logs.

On Thu, Sep 3, 2015 at 6:47 AM, Kayode Odeyemi <dreyemi(a)gmail.com> wrote:

Hi,

I'm experiencing this same issue.

I have a NodeJS app, using the nodejs buildpack. A request taking
approximately 80 secs long gets timed out (502 response). We're using the
default CF ELBs (gorouter and ha_proxy).

On Tue, Aug 25, 2015 at 10:57 PM, CF Runtime <cfruntime(a)gmail.com> wrote:

Hi,

We think this message was dropped and so we are posting it again.

How long of a timeout are you seeing? The gorouter and ha_proxy have a
default timeout of 15 minutes. If you are using an ELB or some other
load balancer they may have their own timeout set. I'm not sure if any
of the app servers installed by buildpacks have a build in timeout or
not, what type of app is it?

Joseph and Dan
OSS Release Integration Team

On Mon, Aug 17, 2015 at 2:18 PM, Flávio Henrique Schuindt da Silva <
flavio.schuindt(a)gmail.com> wrote:

Hi guys,

How can I increase the request timeout in CF? I would like to give more
time to my app to send a response to the requests before getting a timeout.
Should I increase it in the buildpack? If yes, where should I change it on
java buildpack?

Thanks in advance!

--
Thank you,

James Bayer

I planned to put together a proposal for this a couple of weeks ago as a
strawman to describe use cases, but just have not had the time.
I still hope to tackle this in the next week or so and will post to this
list.

For reference, see this thread [1] where this was previously discussed.

-Dieu
CF CAPI PM

[1]
http://cf-dev.70369.x6.nabble.com/cf-dev-Notifications-on-ORG-SPACE-and-USER-modifications-tt827.html#none

On Tue, Aug 18, 2015 at 5:47 PM, Vineet Banga <vineetbanga1(a)gmail.com
<javascript:_e(%7B%7D,'cvml','vineetbanga1(a)gmail.com');>> wrote:

Thanks Juan, I will try to setup a poller for this to achieve similar
functionality. Do you know if there is already proposal for the better
notifications - if yes, could you point me to it? I Would like to see if
it would meet our needs at some point in the future.

On Fri, Aug 14, 2015 at 4:26 PM, Juan Pablo Genovese <
juanpgenovese(a)gmail.com
<javascript:_e(%7B%7D,'cvml','juanpgenovese(a)gmail.com');>> wrote:

Vineet,

there is some proposals to add better notifications to CF in general and
the CC in particular, but for now you can poll the CC API to get those
events. See http://apidocs.cloudfoundry.org/214/

Thanks!

2015-08-14 18:31 GMT-03:00 Vineet Banga <vineetbanga1(a)gmail.com
<javascript:_e(%7B%7D,'cvml','vineetbanga1(a)gmail.com');>>:

Is there any notification pub/sub mechanism in cloud foundry when
services are created/updated/deleted. We are exposing few services in CF
using service brokers and we would like some common actions to occur when
our services are created/delete/updated.

--
Mis mejores deseos,
Best wishes,
Meilleurs vœux,

Juan Pablo
------------------------------------------------------
http://www.jpgenovese.com