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

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

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

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!

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

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

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 <mailto: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# <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

On Sep 3, 2015, at 4:57 PM, Supraja Yasoda <ykmsupraja(a)gmail.com> wrote:



--
Regards,
Supraja.

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!