Date   

Re: CATs failing

Amit Kumar Gupta
 

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


Re: can't login with cf CLI but the UAAC tool works

Filip Hanik
 

Turn on trace, and post your data here. remember, if this is a prod
environment, you may want to send me the token directly
We can show you how to decode this token, and see why it is invalid.

Filip

On Fri, Sep 4, 2015 at 11:59 AM, kyle havlovitz <kylehav(a)gmail.com> wrote:

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?



can't login with cf CLI but the UAAC tool works

kyle havlovitz <kylehav@...>
 

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?


Re: Generic data points for dropsonde

Benjamin Black
 

johannes,

the problem of upstream schema changes causing downstream change or
breakage is the current situation: every addition of a metric type implies
a change to the dropsonde-protocol requiring everything downstream to be
updated.

the schema concerns are similar. currently there is no schema whatsoever
beyond the very fine grained "this is a name and this is a value". this
means every implementation of redis info export, for example, can, and
almost certainly will, be different. this results in every downstream
consumer having to know every possible variant or to only support specific
variants, both exactly the problem you are looking to avoid.

i share the core concern regarding ensuring points are "sufficiently" self
describing. however, there is no clear line delineating what is sufficient.
the current proposal pushes almost everything out to schema. we could
imagine a change to the attributes that includes what an attribute is
(gauge, counter, etc), what the units are for the attribute, and so on.

it is critical that we balance the complexity of the points against
complexity of the consumers as there is no free lunch here. which specific
functionality would you want to see in the generic points to achieve the
balance you prefer?


b



On Wed, Sep 2, 2015 at 2:07 PM, Johannes Tuchscherer <
jtuchscherer(a)pivotal.io> wrote:

The current way of sending metrics as either Values or Counters through
the pipeline makes the development of a downstream consumer (=nozzle)
pretty easy. If you look at the datadog nozzle[0], it just takes all
ValueMetrics and Counters and sends them off to datadog. The nozzle does
not have to know anything about these metrics (e.g. their origin, name, or
layout).

Adding a new way to send metrics as a nested object would make the
downstream implementation certainly more complicated. In that case, the
nozzle developer has to know what metrics are included inside the generic
point (basically the schema of the metric) and treat each point
accordingly. For example, if I were to write a nozzle that emits metrics to
Graphite with a StatsD client (like it is done here[1]), I need to know if
my int64 value is a Gauge or a Counter. Also, my consumer is under constant
risk of breaking when the upstream schema changes.

We are already facing this problem with the container metrics. But at
least the container metrics are in a defined format that is well documented
and not likely to change.

I agree with you, though, the the dropsonde protocol could use a mechanism
for easier extension. Having a GenericPoint and/or GenericEvent seems like
a good idea that I whole-heartedly support. I would just like to stay away
from nested metrics. I think the cost of adding more logic into the
downstream consumer (and making it harder to maintain) is not worth the
benefit of a more concise metric transport.


[0] https://github.com/cloudfoundry-incubator/datadog-firehose-nozzle
[1] https://github.com/CloudCredo/graphite-nozzle

On Tue, Sep 1, 2015 at 5:52 PM, Benjamin Black <bblack(a)pivotal.io> wrote:

great questions, dwayne.

1) the partition key is intended to be used in a similar manner to
partitioners in distributed systems like cassandra or kafka. the specific
behavior i would like to make part of the contract is two-fold: that all
data with the same key is routed to the same partition and that all data in
a partition is FIFO (meaning no ordering guarantees beyond arrival time).

this could help with the multi-line log problem by ensuring a single
consumer will receive all lines for a given log entry in order, allowing
simple reassembly. however, the lines might be interleaved with other lines
with the same key or even other keys that happen to map to the same
partition, so the consumer does require a bit of intelligence. this was
actually one of the driving scenarios for adding the key.

2) i expect typical points to be in the hundreds of bytes to a few KB. if
we find ourselves regularly needing much larger points, especially near
that 64KB limit, i'd look to the JSON representation as the hierarchical
structure is more efficiently managed there.


b




On Tue, Sep 1, 2015 at 4:42 PM, <dschultz(a)pivotal.io> wrote:

Hi Ben,

I was wondering if you could give a concrete use case for the partition
key functionality.

In particular I am interested in how we solve multi line log entries. I
think it would be better to solve it by keeping all the data (the multiple
lines) together throughout the logging/metrics pipeline, but could see how
something like a partition key might help keep the data together as well.

Second question: how large do you see these point messages getting
(average and max)? There are still several stages of the logging/metrics
pipeline that use UDP with a standard 64K size limit.

Thanks,
Dwayne

On Aug 28, 2015, at 4:54 PM, Benjamin Black <bblack(a)pivotal.io> wrote:

All,

The existing dropsonde protocol uses a different message type for each
event type. HttpStart, HttpStop, ContainerMetrics, and so on are all
distinct types in the protocol definition. This requires protocol changes
to introduce any new event type, making such changes very expensive. We've
been working for the past few weeks on an addition to the dropsonde
protocol to support easier future extension to new types of events and to
make it easier for users to define their own events.

The document linked below [1] describes a generic data point message
capable of carrying multi-dimensional, multi-metric points as sets of
name/value pairs. This new message is expected to be added as an additional
entry in the existing dropsonde protocol metric type enum. Things are now
at a point where we'd like to get feedback from the community before moving
forward with implementation.

Please contribute your thoughts on the document in whichever way you are
most comfortable: comments on the document, email here, or email directly
to me. If you comment on the document, please make sure you are logged in
so we can keep track of who is asking for what. Your views are not just
appreciated, but critical to the continued health and success of the Cloud
Foundry community. Thank you!


b

[1]
https://docs.google.com/document/d/1SzvT1BjrBPqUw6zfSYYFfaW9vX_dTZZjn5sl2nxB6Bc/edit?usp=sharing





CATs failing

Quintessence Anx
 

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


Re: Status of support for route paths in cli

Mike Youngstrom
 

Great! Thanks Dieu.

Mike

On Fri, Sep 4, 2015 at 10:46 AM, Dieu Cao <dcao(a)pivotal.io> wrote:

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


Re: Status of support for route paths in cli

Dieu Cao <dcao@...>
 

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


Status of support for route paths in cli

Mike Youngstrom
 

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


Re: Request timeout in CloudFoundry

Mike Youngstrom
 

I have disabled the timeout on the gorouter "-1" trusting our Front end
load balancer to manage the timeout. That way I only need to worry about
configuring timeout on one device in my proxy chain. That may simplify
your problem. Is there any theoretical issues with that approach? It
seems to have worked well for us.

Mike

On Fri, Sep 4, 2015 at 6:49 AM, James Bayer <jbayer(a)pivotal.io> wrote:

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


Re: Notifications for service brokers

Dieu Cao <dcao@...>
 

To follow up on this, I've been working with Simon Moser on an initial
proposal for this and he is now taking lead on it. Simon just completed a
PM dojo at the end of August.

Dieu

On Tuesday, August 18, 2015, Dieu Cao <dcao(a)pivotal.io> wrote:

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


Re: Need Help. How to register custom routes to gorouter

Mark St.Godard
 

The new routing-api and routing-api-cli allow you to register / unregister
routes

You will need to ensure you are also deploying routing-api with cf-release

Routing API
https://github.com/cloudfoundry-incubator/routing-api

Routing API CLI
https://github.com/cloudfoundry-incubator/routing-api-cli

Cheers

On Fri, Sep 4, 2015 at 7:53 AM, James Bayer <jbayer(a)pivotal.io> wrote:

which cf-release are you using?

newer versions support an http api for trusted components to register
routes. shannon is the PM for the routing team and can explain more and
perhaps point to documentation.

note there is an example of mysql registering a route with the previous
approach in a bosh release here:

https://github.com/cloudfoundry/cf-mysql-release/blob/master/jobs/cf-mysql-broker/templates/route-registrar_ctl.erb

On Thu, Sep 3, 2015 at 4:20 PM, Lakshman Mukkamalla (lmukkama) <
lmukkama(a)cisco.com> wrote:

Hi cf devs,
I want to register some custom routes to the gorouter component of
cloud foundry. What I understood was that this could be achieved by
nats-pub command but when I try this command on the gorouter VM it was not
recognized. Can anyone help me how to register custom routes to gorouter.
https://docs.cloudfoundry.org/concepts/architecture/router.html
What worked:
curl -vvv "
http://gorouterusername:gorouterpassword(a)gorouter_ip:gorouter_port/routes
"
This gives me the current routes that are registered.

*What did not work:*
nats-pub 'router.register' 'some custom route'
OR
Is there a rest call to register the custom routes?

It would be of great help if someone can guide me on how to achieve the
similar.

Thanks.


--
Thank you,

James Bayer


Re: Placement Pools

Dieu Cao <dcao@...>
 

Yes, I was just talking with Onsi and Mark Kropf about this yesterday and
plan to submit a talk on this with Mark Kropf for cf summit berlin.

I'll take on getting the proposal for isolation groups shared with cf-dev,
hopefully, in the next couple of weeks.

-Dieu
CF CAPI PM

On Friday, September 4, 2015, James Bayer <jbayer(a)pivotal.io> wrote:

i believe dieu is working on this in preparate for cf summit in berlin.
dieu, did i understand that correctly?

On Thu, Sep 3, 2015 at 4:50 PM, Carlo Alberto Ferraris <
cafxx(a)strayorange.com> wrote:

James, Onsi,
we’re also looking forward to this, for we have some peculiar
infrastructure requirements.

Carlo

On Aug 29, 2015, at 2:51 AM, James Bayer <jbayer(a)pivotal.io> wrote:

we've been using a new term for the same concept we've previously labeled
placement pools called "isolation groups".

onsi has been working on some documentation for what this may look like
and the requirements, but the work has not started. i believe onsi will
share something soon.

so today, the way to accomplish this need to place apps on specific
infrastructure is to use separate CF installations.

On Fri, Aug 28, 2015 at 8:50 AM, Matt Cholick <cholick(a)gmail.com> wrote:

More than a year ago, there was some discussion and a proposal around
adding placement pools so cloud foundry admins could better target how
applications were placed on runners:

https://docs.google.com/document/d/1GNjQwGBh0BvfAYpX0LTUYn6h4oLz7v4P9pNy0xHZtMw/edit#

Did this work gain traction? I've looked through the release notes as
well as MEGA and CF Diego's public trackers and don't see stories for this
work either done or planned, though it could also be that I'm just not
finding it.

My goal is to place canary apps in specifically Z1 or Z2, as well as
place some internally used apps that, for networking reasons, should be in
one zone or the other.

-Matt Cholick


--
Thank you,

James Bayer



--
Thank you,

James Bayer


Re: Need Help. How to register custom routes to gorouter

James Bayer
 

which cf-release are you using?

newer versions support an http api for trusted components to register
routes. shannon is the PM for the routing team and can explain more and
perhaps point to documentation.

note there is an example of mysql registering a route with the previous
approach in a bosh release here:
https://github.com/cloudfoundry/cf-mysql-release/blob/master/jobs/cf-mysql-broker/templates/route-registrar_ctl.erb

On Thu, Sep 3, 2015 at 4:20 PM, Lakshman Mukkamalla (lmukkama) <
lmukkama(a)cisco.com> wrote:

Hi cf devs,
I want to register some custom routes to the gorouter component of
cloud foundry. What I understood was that this could be achieved by
nats-pub command but when I try this command on the gorouter VM it was not
recognized. Can anyone help me how to register custom routes to gorouter.
https://docs.cloudfoundry.org/concepts/architecture/router.html
What worked:
curl -vvv "
http://gorouterusername:gorouterpassword(a)gorouter_ip:gorouter_port/routes"
This gives me the current routes that are registered.

*What did not work:*
nats-pub 'router.register' 'some custom route'
OR
Is there a rest call to register the custom routes?

It would be of great help if someone can guide me on how to achieve the
similar.

Thanks.


--
Thank you,

James Bayer


Re: Request timeout in CloudFoundry

James Bayer
 

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


Re: Placement Pools

James Bayer
 

i believe dieu is working on this in preparate for cf summit in berlin.
dieu, did i understand that correctly?

On Thu, Sep 3, 2015 at 4:50 PM, Carlo Alberto Ferraris <
cafxx(a)strayorange.com> wrote:

James, Onsi,
we’re also looking forward to this, for we have some peculiar
infrastructure requirements.

Carlo

On Aug 29, 2015, at 2:51 AM, James Bayer <jbayer(a)pivotal.io> wrote:

we've been using a new term for the same concept we've previously labeled
placement pools called "isolation groups".

onsi has been working on some documentation for what this may look like
and the requirements, but the work has not started. i believe onsi will
share something soon.

so today, the way to accomplish this need to place apps on specific
infrastructure is to use separate CF installations.

On Fri, Aug 28, 2015 at 8:50 AM, Matt Cholick <cholick(a)gmail.com> wrote:

More than a year ago, there was some discussion and a proposal around
adding placement pools so cloud foundry admins could better target how
applications were placed on runners:

https://docs.google.com/document/d/1GNjQwGBh0BvfAYpX0LTUYn6h4oLz7v4P9pNy0xHZtMw/edit#

Did this work gain traction? I've looked through the release notes as
well as MEGA and CF Diego's public trackers and don't see stories for this
work either done or planned, though it could also be that I'm just not
finding it.

My goal is to place canary apps in specifically Z1 or Z2, as well as
place some internally used apps that, for networking reasons, should be in
one zone or the other.

-Matt Cholick


--
Thank you,

James Bayer



--
Thank you,

James Bayer


Re: Application only starts when a bogus service is attached

Daniel Mikusa
 

On Fri, Sep 4, 2015 at 4:32 AM, Ramon Makkelie <ramon.makkelie(a)klm.com>
wrote:

we have some application that since our upgrade from 207 to 214 would not
run
What version of the Java build pack do you have installed? `cf
buildpacks`? What does your `cf push` command & manifest.yml look like?



If I push an app (java web/ Spring) on cf without any services, CF loop on
the push and sometime at the end (10 or 15minutes) the app running or not.

I have this trace in the events :

2015-08-26T13:19:28.00+0200 app.crash pocretform
index: 0, reason: CRASHED, exit_description: failed to accept
connections within health check timeout, exit_status: -1
2015-08-26T13:18:10.00+0200 app.crash pocretform
index: 0, reason: CRASHED, exit_description: failed to accept
connections within health check timeout, exit_status: -1
2015-08-26T13:16:48.00+0200 app.crash pocretform
index: 0, reason: CRASHED, exit_description: failed to accept
connections within health check timeout, exit_status: -1

and in the stdout :

2015-08-26T13:16:48.00+0200 [DEA/8] ERR Instance (index 0) failed to
start accepting connections

If I bind a fake service (like mongo), the app is pushed without any
problem
What do you mean by "fake"? Is it an actual service attached to a DB? Is
it a user provided service with no info?



and in the log (stdout) I have :

2015-08-26T13:29:50.87+0200 [App/0] OUT [CONTAINER]
org.apache.catalina.startup.HostConfig INFO Deployment of
web application directory
/home/vcap/app/.java-buildpack/tomcat/webapps/ROOT has finished in 6,502 ms
2015-08-26T13:29:50.87+0200 [App/0] OUT [CONTAINER]
org.apache.coyote.http11.Http11NioProtocol INFO Starting
ProtocolHandler ["http-nio-61230"]
2015-08-26T13:29:50.88+0200 [App/0] OUT [CONTAINER]
org.apache.tomcat.util.net.NioSelectorPool INFO Using a shared
selector for servlet write/read
2015-08-26T13:29:50.88+0200 [App/0] OUT [CONTAINER]
org.apache.catalina.startup.Catalina INFO Server startup
in 6540 ms

This trace does not appear, if I unbind the service.
Some suggestions for troubleshooting...

1.) Run `cf logs <app>` in a second terminal. Then run `cf push`. After
the build pack completes, you should see a line that says CF is starting
the app. If you see no logging between that and the notice that the app
exited, you might try this. Sometimes when an app exits too fast, logging
is lost.

http://support.run.pivotal.io/entries/82506749-Help-My-app-is-crashing-and-I-don-t-see-any-thing-in-the-logs

2.) Because it's a Java app, you might also try this.

http://support.run.pivotal.io/entries/59869725-Java-Web-Applications-Slow-Startup-or-Failing

(sorry for the PWS links, those should be relevant for anyone running CF
though)



I have also tried to push the Tomcat demo app (
https://tomcat.apache.org/tomcat-6.0-doc/appdev/sample/), same behaviour.
So it's not our app problem
You might try the samples for Tomcat 8, since that's what the Java build
pack has been deploying for a while.

Dan


So many hard-coded dropsonde destinations to metrons

Noburou TANIGUCHI
 

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.


Application only starts when a bogus service is attached

ramonskie
 

we have some application that since our upgrade from 207 to 214 would not run

If I push an app (java web/ Spring) on cf without any services, CF loop on the push and sometime at the end (10 or 15minutes) the app running or not.

I have this trace in the events :

2015-08-26T13:19:28.00+0200 app.crash pocretform index: 0, reason: CRASHED, exit_description: failed to accept connections within health check timeout, exit_status: -1
2015-08-26T13:18:10.00+0200 app.crash pocretform index: 0, reason: CRASHED, exit_description: failed to accept connections within health check timeout, exit_status: -1
2015-08-26T13:16:48.00+0200 app.crash pocretform index: 0, reason: CRASHED, exit_description: failed to accept connections within health check timeout, exit_status: -1

and in the stdout :

2015-08-26T13:16:48.00+0200 [DEA/8] ERR Instance (index 0) failed to start accepting connections

If I bind a fake service (like mongo), the app is pushed without any problem

and in the log (stdout) I have :

2015-08-26T13:29:50.87+0200 [App/0] OUT [CONTAINER] org.apache.catalina.startup.HostConfig INFO Deployment of web application directory /home/vcap/app/.java-buildpack/tomcat/webapps/ROOT has finished in 6,502 ms
2015-08-26T13:29:50.87+0200 [App/0] OUT [CONTAINER] org.apache.coyote.http11.Http11NioProtocol INFO Starting ProtocolHandler ["http-nio-61230"]
2015-08-26T13:29:50.88+0200 [App/0] OUT [CONTAINER] org.apache.tomcat.util.net.NioSelectorPool INFO Using a shared selector for servlet write/read
2015-08-26T13:29:50.88+0200 [App/0] OUT [CONTAINER] org.apache.catalina.startup.Catalina INFO Server startup in 6540 ms

This trace does not appear, if I unbind the service.

I have also tried to push the Tomcat demo app (https://tomcat.apache.org/tomcat-6.0-doc/appdev/sample/), same behaviour. So it's not our app problem

any suggestions?


Re: why does cf app show always 0.0% CPU

Amit Kumar Gupta
 

On Thu, Sep 3, 2015 at 11:25 PM, Lukas Lehner <weblehner(a)gmail.com> wrote:

Hi

see details here
http://stackoverflow.com/questions/32375162/cf-app-shows-always-0-0-cpu-how-is-that-value-measured

Can you provide me details how this value is measured?

Lukas


Re: Announcing Experimental support for Asynchronous Service Operations

Dieu Cao <dcao@...>
 

Thanks Guillaume for the feedback. I've now gathered enough feedback to
bring async operations out of the experimental phase and bump the service
broker api version.
I've added stories to the CAPI backlog [1] and we'll get the diagram
updated too.

Localized error messages is not something we are looking to work on right
now. I believe there was a previous attempt to have CC errors localized
that ended up not being merged due to issues with the way v2 constructed
error messages and not being backwards compatible. As these descriptions
passed from brokers via the last_operation end point don't go that route,
there's perhaps a path forward there.
Happy to discuss if it's work that anyone is interested in taking on via PR.

-Dieu
CF CAPI PM

[1] https://www.pivotaltracker.com/epic/show/2058352

On Wed, Sep 2, 2015 at 5:00 AM, Guillaume Berche <bercheg(a)gmail.com> wrote:

Thanks Dieu for your response.

We have successfully implemented an async service broker for out internal
dbaas [1], [2] which db farms provisionning sometimes takes longer than
30s.

Concerning improvement suggestions on the documentation, I could only spot
an inconsistency on the sequence diagram, where the last operation
description is mismatching between broker response (1/3 nodes") and CC api
response ("40% complete") whereas the 'description' is a string which
should be returned as is. Hard to propose a PR on that since the source
file for this diagram does not seem available under docs-services [4]. BTW,
It would be great if bookbinder would support rendering diagrams from a
text format such as plantuml [5], or rely on plantuml public service [6]
for such rendering.

Wouldn't is make sense to exit the experimental status of the async api,
even if it's not feature complete ? i.e. considering the api is stable
enough and won't change in an incompatible maneer soon, thereby enabling
clients such as cf-java-client to rely on them.

One other potential improvement I see to the API would be to support
localized user-facing operation status description. Having the CLI being
I18Ned but brokers enable to return user facing messages in the user
language seems limiting. Maybe it could be the case of having the CLI add a
usual 'Accept-Language: zh_Hans" matching the current CLI locale, and the
CC propagating this header in the last_operation broker endpoint [7] so
that they can return the status message in the smae language when
translations are available.

Thanks,

Guillaume.

[1]
https://github.com/Orange-OpenSource/elpaaso-brokers/blob/master/cf-service-broker-dbaas/src/main/java/com/orange/clara/cloud/cf/servicebroker/dbaas/service/DbaasServiceInstanceService.java#L60
[2]
https://github.com/Orange-OpenSource/elpaaso-brokers/blob/a3f150fc7d3bb889875aac202496a4f63efc3595/cf-service-broker-dbaas/src/main/java/com/orange/clara/cloud/cf/servicebroker/dbaas/service/DbaasServiceInstanceService.java#L67-L73
[3]
http://docs.cloudfoundry.org/services/images/async-service-broker-flow.png
[4]
https://github.com/cloudfoundry/docs-services/blob/master/images/async-service-broker-flow.png
[5] http://plantuml.com/sequence.html
[6] http://plantuml.com/plantuml/
[7]
http://docs.cloudfoundry.org/services/asynchronous-operations.html#polling

On Tue, Sep 1, 2015 at 5:50 PM, Dieu Cao <dcao(a)pivotal.io> wrote:

Hi Guillaume,

We are looking for a couple more pieces of feedback. All feedback I've
received so far has been positive.

There was one report recently from Robert Moss about being able to
provide the dashboard_url asynchronously instead of part of the original
response [1].
I'm also considering whether that needs to be addressed prior to marking
the feature complete, or if it should be a separate/additive change to the
service broker api.

If you've had success with the current implementation, I would be greatly
interested in hearing that.

-Dieu

[1]
https://lists.cloudfoundry.org/archives/list/cf-dev(a)lists.cloudfoundry.org/thread/LJ26K22WG7OJCAIXWYPTJQKELVAUBUZC/

On Tue, Sep 1, 2015 at 5:20 AM, Guillaume Berche <bercheg(a)gmail.com>
wrote:

Hi,

I'm wondering whether the experimental async service broker api is now
ready to become official, or whether the CAPI team and PMs are still
lacking feedback or have some outstanding issues that need to be addressed
before calling the spec official? I was not able to spot any async-related
stories in the CAPI backlog [1]

We have a pending PR in cf-java-client [2] which is waiting for the
async broker spec to be made official.

Thanks in advance,

Guillaume.

[1] https://www.pivotaltracker.com/n/projects/966314
[2]
https://github.com/cloudfoundry/cf-java-client/pull/282#issuecomment-115874984

On Fri, Jun 5, 2015 at 9:21 AM, James Bayer <jbayer(a)pivotal.io> wrote:

i'm very happy to see this work delivered as the 60 second limit has
come up so often as a pain point in the past. great job to all who
contributed!

On Wed, Jun 3, 2015 at 5:05 PM, Onsi Fakhouri <ofakhouri(a)pivotal.io>
wrote:

Well done Services API! This is an awesome milestone!

On Wed, Jun 3, 2015 at 5:04 PM, Chip Childers <
cchilders(a)cloudfoundry.org> wrote:

Awesome news! Long time coming, and it opens up a whole world of
additional capabilities for users.

Nice work everyone!



On Jun 4, 2015, at 9:00 AM, Shannon Coen <scoen(a)pivotal.io> wrote:

On behalf of the Services API team, including Dojo participants from
IBM and SAP, I'm pleased to announce experimental availability and
published documentation for this much-anticipated feature.

As of cf-release v208 and CLI v6.11.1, Cloud Foundry now supports an
enhanced service broker integration in support of long-running
provisioning, update, and delete operations. This significantly broadens
the supported use cases for Cloud Foundry Marketplace Services, and I can't
wait to hear what creative things the ecosystem does with it. Provision
VMs, orchestrate clusters, install software, move data... yes, your broker
can even open support tickets to have those things done manually!

This feature is currently considered experimental, as we'd like you
all to review our docs, try out the feature, and give us feedback. We very
interested to hear about any confusion in the docs or the UX, and any
sticky issues you encounter in implementation. Our goal is for our docs
enable a painless, intuitive (can we hope for joyful?) implementation
experience.

We have not bumped the broker API yet for this feature. You'll notice
that our documentation for the feature is separate from the stable API docs
at this point. Once we're confident in the design (we're relying on your
feedback!), we'll bump the broker API version, move the docs for
asynchronous operations into the stable docs, AND implement support for
asynchronous bind/create-key and unbind/delete-key.

Documentation:
- http://docs.cloudfoundry.org/services/asynchronous-operations.html
- http://docs.cloudfoundry.org/services/api.html
Example broker for AWS (contributed by IBM):
- http://docs.cloudfoundry.org/services/examples.html
- https://github.com/cloudfoundry-samples/go_service_broker
Demo of the feature presented at CF Summit 2015:
- https://youtu.be/Ij5KSKrAq9Q

tl;dr

Cloud Foundry expects broker responses within 60 seconds. Now a
broker can return an immediate response indicating that a provision,
update, or delete operation is in progress. Cloud Foundry then returns a
similar response to the client, and begins polling the broker for the
status of the operation. Users, via API clients, can discover the status of
the operation ("in progress", "succeeded", or "failed"), and brokers can
provide user-facing messages in response to each poll which are exposed to
users (e.g. "VMs provisioned, installing software, 30% complete").

Thank you,

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

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


_______________________________________________
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

7881 - 7900 of 9387