1. cf-dev@lists.cloudfoundry.org
  2. Messages
   Date   
Re: Security group rules to allow HTTP communication between 2 apps deployed on CF

Matthew Sykes <matthew.sykes@...>
 

I'm afraid I don't really understand your questions or what you're trying
to accomplish.

Security groups intended to be managed by platform administrators so unless
you have admin access to your target environment, you will not be able to
create security groups.

If you're trying to access the cloud controller api or other applications,
you should be going through the front door (the external host names). The
security group rules should not be preventing you from doing that.

If you're trying to access something internal to the cloud foundry
deployment, you will need explicit support from the administrators.

On Tue, Sep 8, 2015 at 5:20 AM, Naveen Asapu <asapu.naveen(a)gmail.com> wrote:

How to get destination address for bluemix.net can you suggest any
command for getting destination address

actually i'm creating security group for abacus for that it needs
destination address how can i get


command:
cf create-security-group abacus abacus_group.json

error:
Creating security group abacus as xxxx(a)xxxx.in
FAILED
Server error, status code: 403, error code: 10003, message: You are not
authorized to perform the requested action
--
Matthew Sykes
matthew.sykes(a)gmail.com

?
attachment.html

Re: So many hard-coded dropsonde destinations to metrons

Noburou TANIGUCHI
 

Thank you, Warren.

So "localhost" is ok, but what about port numbers?


Warren Fernandes wrote
Dropsonde is a go library that allows the CF components using it to emit
logs and metrics. The current flow for CF components is to emit their logs
and metrics to their local metron agent which then forwards them to the
Doppler servers in Loggregator. The metron agents only listen on the local
interface and immediately signs the messages before sending them off to
the Dopplers. So for now, the destination parameter for dropsonde will
always point to the local metron agent.

Here is some more info on Metron
https://github.com/cloudfoundry/loggregator/tree/develop/src/metron
Here is some more info on Dropsonde
https://github.com/cloudfoundry/dropsonde




-----
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-tp1474p1543.html
Sent from the CF Dev mailing list archive at Nabble.com.
Re: Public access to Pivotal Tracker stories for BOSH and CF.

Christopher B Ferris <chrisfer@...>
 

Look in the right-hand margin of the wiki [1] for the list of CFF public trackers.
 
 
Cheers,

Christopher Ferris
IBM Distinguished Engineer, CTO Open Technology
IBM Cloud, Open Technologies
email: chrisfer@...
twitter: @christo4ferris
blog: http://thoughtsoncloud.com/index.php/author/cferris/
phone: +1 508 667 0402
 
 

----- Original message -----
From: Lomov Alexander <alexander.lomov@...>
To: "Discussions about Cloud Foundry projects and the system overall." <cf-dev@...>
Cc:
Subject: [cf-dev] Public access to Pivotal Tracker stories for BOSH and CF.
Date: Tue, Sep 8, 2015 7:08 AM
 
Hi, all.
 
Last few months I started to find more and more extremely interesting trends in BOSH and CF development. For instance BOSH AZ [1] or Garden OCS support [2]. I would like to somehow to follow this changes and I’m sure that Pivatal Tracker can be the tool to do so. Still I found only this Pivotal Tracker instructions in cf-docs-contrib [3], that is discussed in BOSH Users group some time ago [4].
 
Still links from cf-docs-contrib page are missing (or I don’t have access to them) [5]. 
 
Could you please tell if there is any public access to Pivatal Tracker to follow this changes.
 
Thank you,
Alex L.
 
 
 
 
Re: How to deploy a Web application using HTTPs

Matthew Sykes <matthew.sykes@...>
 

There isn't a way to tell CF that you want https only at this time. You'll
have to check the x-forwarded-proto header in your application and redirect
to the secure endpoint if needed.

On Tue, Sep 8, 2015 at 6:16 AM, Juan Antonio Breña Moral <
bren(a)juanantonio.info> wrote:

Hi,

I would like to deploy an App but I would like to use it using only https.

What is the way to indicate CF that the Application X will use https only?

Juan Antonio


--
Matthew Sykes
matthew.sykes(a)gmail.com

?
attachment.html

Public access to Pivotal Tracker stories for BOSH and CF.

Alexander Lomov <alexander.lomov@...>
 

Hi, all.

Last few months I started to find more and more extremely interesting trends in BOSH and CF development. For instance BOSH AZ [1] or Garden OCS support [2]. I would like to somehow to follow this changes and I’m sure that Pivatal Tracker can be the tool to do so. Still I found only this Pivotal Tracker instructions in cf-docs-contrib [3], that is discussed in BOSH Users group some time ago [4].

Still links from cf-docs-contrib page are missing (or I don’t have access to them) [5].

Could you please tell if there is any public access to Pivatal Tracker to follow this changes.

Thank you,
Alex L.

[1] https://github.com/cloudfoundry/bosh-notes/blob/master/availability-zones.md
[2] https://docs.google.com/document/d/1SCOlAquyUmNM-AQnekCOXiwhLs6gveTxAcduvDcW_xI/edit#
[3] https://github.com/cloudfoundry-community/cf-docs-contrib/wiki/Pivotal-Tracker-Instructions#pivotal-trackers
[4] https://groups.google.com/a/cloudfoundry.org/forum/#!topic/bosh-users/kSwYfQNwO54
[5] https://www.evernote.com/shard/s108/sh/d322f0a4-39e8-4825-9f3c-ae242aaa39d6/64a83b76dcb0b4d7/res/d2792e9a-3763-4d77-833c-0855d3cb25f5/skitch.png?resizeSmall&width=832

?
attachment.html

Re: When will dea be replaced by diego?

Matthew Sykes <matthew.sykes@...>
 

Hi Guillaume. The proposal document was created by Amit and I had assumed
it was public. I'll try to make sure he sees this chain today so he can
address it. Sorry to send a unusable link.

On Tue, Sep 8, 2015 at 3:02 AM, Guillaume Berche <bercheg(a)gmail.com> wrote:

Thanks Matthew for the additional details and pointers. It seems that the
deployment strategy proposal mentionned in [2] is lacking read/comment
permissions. Any chance to fix that ?

Guillaume.

On Tue, Sep 8, 2015 at 2:07 AM, Matthew Sykes <matthew.sykes(a)gmail.com>
wrote:

The notes you're pointing to were a straw man proposal; many of the dates
no longer seem relevant.

With that, I'm not in product management but, in my opinion, the
definition of "done" and "ready" are relative.

The current bar that the development team is focusing on is data and API
versioning. We feel it's necessary to maintain continuous operation across
deployments. In particular, we want to be sure that operators can perform
forward migration with minimal down time before it becomes the default
backend in production. We're currently referring to that target as v 0.9.

That said, the current path towards that goal has us going to a single
API server Diego[1]. With this change in architecture, the scaling and
performance characteristics will probably change. While it's likely these
changes won't have measurable impact to smaller environments, it remains to
be seen what will happen with the larger deployments operated by public
providers. This is where the whole notion of "replacement" starts to get a
bit murky.

As for "merging into cf-release," again, I'm not product management
(James and Amit are in a better position to comment) but the current
direction appears to be to break down Cloud Foundry into a number of
smaller releases. We already have a cf-release, garden-release, and
diego-release as part of a diego deployment but there are others like an
etcd-release that the MEGA team is managing and a uaa-release that the
identity team have done. These are all pieces of a new deployment strategy
that was proposed[2] a few months ago.

Given that path, I don't know that diego-release will ever be merged into
cf-release; it's more likely that it will be stitched into the
"cf-deployment" described in that proposal.

So, to your question, the 0.9 release may be cut in September. That's the
first release that operators will be able to roll forward from without
downtime. If you want Diego to be the default backend without having to
mess with plugins and configuration, you can already do that today via
configuration[3].

[1]: https://github.com/onsi/migration-proposal
[2]:
https://docs.google.com/document/d/1Viga_TzUB2nLxN_ILqksmUiILM1hGhq7MBXxgLaUOkY/edit#heading=h.qam414rpl0xe
[3]:
https://github.com/cloudfoundry/cloud_controller_ng/blob/aea2a53b123dc5104c11eb53b81a09a4c4eaba55/bosh-templates/cloud_controller_api.yml.erb#L287

On Mon, Sep 7, 2015 at 2:08 PM, Layne Peng <layne.peng(a)emc.com> wrote:

I think what he ask is, when the Diego-release will merge to cf-release.
And also no need to install cf cli diego plugin, no need to enabe-diego to
your app, then start. For the
https://github.com/cloudfoundry-incubator/diego-design-notes/blob/master/migrating-to-diego.md#a-detailed-transition-timeline
. it is said to be mid-september, is it right?


--
Matthew Sykes
matthew.sykes(a)gmail.com
--
Matthew Sykes
matthew.sykes(a)gmail.com

?
attachment.html

How to deploy a Web application using HTTPs

Juan Antonio Breña Moral <bren at juanantonio.info...>
 

Hi,

I would like to deploy an App but I would like to use it using only https.

What is the way to indicate CF that the Application X will use https only?

Juan Antonio
Re: Security group rules to allow HTTP communication between 2 apps deployed on CF

Naveen Asapu
 

How to get destination address for bluemix.net can you suggest any command for getting destination address

actually i'm creating security group for abacus for that it needs destination address how can i get


command:
cf create-security-group abacus abacus_group.json

error:
Creating security group abacus as xxxx(a)xxxx.in
FAILED
Server error, status code: 403, error code: 10003, message: You are not authorized to perform the requested action
Re: When will dea be replaced by diego?

Guillaume Berche
 

Thanks Matthew for the additional details and pointers. It seems that the
deployment strategy proposal mentionned in [2] is lacking read/comment
permissions. Any chance to fix that ?

Guillaume.

On Tue, Sep 8, 2015 at 2:07 AM, Matthew Sykes <matthew.sykes(a)gmail.com>
wrote:

The notes you're pointing to were a straw man proposal; many of the dates
no longer seem relevant.

With that, I'm not in product management but, in my opinion, the
definition of "done" and "ready" are relative.

The current bar that the development team is focusing on is data and API
versioning. We feel it's necessary to maintain continuous operation across
deployments. In particular, we want to be sure that operators can perform
forward migration with minimal down time before it becomes the default
backend in production. We're currently referring to that target as v 0.9.

That said, the current path towards that goal has us going to a single API
server Diego[1]. With this change in architecture, the scaling and
performance characteristics will probably change. While it's likely these
changes won't have measurable impact to smaller environments, it remains to
be seen what will happen with the larger deployments operated by public
providers. This is where the whole notion of "replacement" starts to get a
bit murky.

As for "merging into cf-release," again, I'm not product management (James
and Amit are in a better position to comment) but the current direction
appears to be to break down Cloud Foundry into a number of smaller
releases. We already have a cf-release, garden-release, and diego-release
as part of a diego deployment but there are others like an etcd-release
that the MEGA team is managing and a uaa-release that the identity team
have done. These are all pieces of a new deployment strategy that was
proposed[2] a few months ago.

Given that path, I don't know that diego-release will ever be merged into
cf-release; it's more likely that it will be stitched into the
"cf-deployment" described in that proposal.

So, to your question, the 0.9 release may be cut in September. That's the
first release that operators will be able to roll forward from without
downtime. If you want Diego to be the default backend without having to
mess with plugins and configuration, you can already do that today via
configuration[3].

[1]: https://github.com/onsi/migration-proposal
[2]:
https://docs.google.com/document/d/1Viga_TzUB2nLxN_ILqksmUiILM1hGhq7MBXxgLaUOkY/edit#heading=h.qam414rpl0xe
[3]:
https://github.com/cloudfoundry/cloud_controller_ng/blob/aea2a53b123dc5104c11eb53b81a09a4c4eaba55/bosh-templates/cloud_controller_api.yml.erb#L287

On Mon, Sep 7, 2015 at 2:08 PM, Layne Peng <layne.peng(a)emc.com> wrote:

I think what he ask is, when the Diego-release will merge to cf-release.
And also no need to install cf cli diego plugin, no need to enabe-diego to
your app, then start. For the
https://github.com/cloudfoundry-incubator/diego-design-notes/blob/master/migrating-to-diego.md#a-detailed-transition-timeline
. it is said to be mid-september, is it right?


--
Matthew Sykes
matthew.sykes(a)gmail.com

?
attachment.html

Re: How to execute multiple CF REST methods with an unique authentication

Juan Antonio Breña Moral <bren at juanantonio.info...>
 

Hi,

you had reason. I stored in the right way the token, and Now it is possible to reuse a token for multiple operations.

Example:

it.only("Using An unique Login, it is possible to execute 3 REST operations", function () {
this.timeout(2500);

CloudFoundry.setEndPoint(endPoint);

var token_endpoint = null;
var refresh_token = null;
var token_type = null;
var access_token = null;
return CloudFoundry.getInfo().then(function (result) {
token_endpoint = result.token_endpoint;
return CloudFoundry.login(token_endpoint, username, password);
}).then(function (result) {
token_type = result.token_type;
access_token = result.access_token;
return CloudFoundryApps.getApps(token_type, access_token);
}).then(function (result) {
return CloudFoundryApps.getApps(token_type, access_token);
}).then(function (result) {
return CloudFoundryApps.getApps(token_type, access_token);
}).then(function (result) {
expect(true).to.equal(true);
});
});

What is the usage of token_refresh?
How to check the pending time for current token?

Juan Antonio
Re: How to execute multiple CF REST methods with an unique authentication

CF Runtime
 

A token should be valid for any number of requests until the expiration
time is reached.

In your code example, is the "result" passed to your second call to
"getApps" the result from the login attempt, or the result from the first
"getApps" call? You might try console.log(results) before that second
getApps call.

Joseph
OSS Release Integration Team

On Mon, Sep 7, 2015 at 3:05 AM, Juan Antonio Breña Moral <
bren(a)juanantonio.info> wrote:

Currently,

If I execute 2 operations with the same token, I receive the following
message:

it.only("Using Login to execute 2 REST operations", function () {
this.timeout(2500);

CloudFoundry.setEndPoint(endPoint);

var token_endpoint = null;
var refresh_token = null;
return CloudFoundry.getInfo().then(function (result) {
token_endpoint = result.token_endpoint;
return CloudFoundry.login(token_endpoint, username, password);
}).then(function (result) {
return CloudFoundryApps.getApps(result.token_type,
result.access_token);
}).then(function (result) {
return CloudFoundryApps.getApps(result.token_type,
result.access_token);
}).then(function (result) {
console.log(result);
expect(true).to.equal(true);
});
});

Tests Response:

1) Cloud Foundry Using Login to execute 2 REST operations:
Error: the string "{\n \"code\": 10002,\n \"description\":
\"Authenticati
on error\",\n \"error_code\": \"CF-NotAuthenticated\"\n}\n" was thrown,
throw a
n Error :)

?
attachment.html

Re: When will dea be replaced by diego?

Matthew Sykes <matthew.sykes@...>
 

The notes you're pointing to were a straw man proposal; many of the dates
no longer seem relevant.

With that, I'm not in product management but, in my opinion, the definition
of "done" and "ready" are relative.

The current bar that the development team is focusing on is data and API
versioning. We feel it's necessary to maintain continuous operation across
deployments. In particular, we want to be sure that operators can perform
forward migration with minimal down time before it becomes the default
backend in production. We're currently referring to that target as v 0.9.

That said, the current path towards that goal has us going to a single API
server Diego[1]. With this change in architecture, the scaling and
performance characteristics will probably change. While it's likely these
changes won't have measurable impact to smaller environments, it remains to
be seen what will happen with the larger deployments operated by public
providers. This is where the whole notion of "replacement" starts to get a
bit murky.

As for "merging into cf-release," again, I'm not product management (James
and Amit are in a better position to comment) but the current direction
appears to be to break down Cloud Foundry into a number of smaller
releases. We already have a cf-release, garden-release, and diego-release
as part of a diego deployment but there are others like an etcd-release
that the MEGA team is managing and a uaa-release that the identity team
have done. These are all pieces of a new deployment strategy that was
proposed[2] a few months ago.

Given that path, I don't know that diego-release will ever be merged into
cf-release; it's more likely that it will be stitched into the
"cf-deployment" described in that proposal.

So, to your question, the 0.9 release may be cut in September. That's the
first release that operators will be able to roll forward from without
downtime. If you want Diego to be the default backend without having to
mess with plugins and configuration, you can already do that today via
configuration[3].

[1]: https://github.com/onsi/migration-proposal
[2]:
https://docs.google.com/document/d/1Viga_TzUB2nLxN_ILqksmUiILM1hGhq7MBXxgLaUOkY/edit#heading=h.qam414rpl0xe
[3]:
https://github.com/cloudfoundry/cloud_controller_ng/blob/aea2a53b123dc5104c11eb53b81a09a4c4eaba55/bosh-templates/cloud_controller_api.yml.erb#L287

On Mon, Sep 7, 2015 at 2:08 PM, Layne Peng <layne.peng(a)emc.com> wrote:

I think what he ask is, when the Diego-release will merge to cf-release.
And also no need to install cf cli diego plugin, no need to enabe-diego to
your app, then start. For the
https://github.com/cloudfoundry-incubator/diego-design-notes/blob/master/migrating-to-diego.md#a-detailed-transition-timeline
. it is said to be mid-september, is it right?
--
Matthew Sykes
matthew.sykes(a)gmail.com

?
attachment.html

Re: v3 cc api style guide feedback requested

Guillaume Berche
 

Thanks for sharing this great spec.

Not sure if you're preferring feedback other the mailing list of GH issue.
Let me know.

General feedback:

+1 for a formal schema for the v3 api as to ease automatic client
generations (api explorer, java sdk, go sdk...) (e.g. swagger format)
Automated tests on the formal schema may also help checking the style guide
is respected. https://www.pivotaltracker.com/story/show/99237980 seems to
only consider documentation benefits so far and not yet client generation
benefits (e.g. https://github.com/swagger-api/swagger-codegen
https://github.com/swagger-api/swagger-codegen/issues/325 )

Would be nice to clarify support for non ascii characters in query params,
such as support for IRI
https://en.wikipedia.org/wiki/Internationalized_resource_identifier as to
avoid mojibake bugs such as the one presumed in
https://github.com/cloudfoundry/cli/issues/560

Would be nice to consider supporting gzip encoding for the json payload
responses as to speed up responses over internet connections
('Accept-Encoding' header)

It general it may make sense to clarify supported HTTP headers (+1 for
etag/if-modified-since support suggested at
https://github.com/cloudfoundry/cc-api-v3-style-guide/issues/2 ).

https://github.com/cloudfoundry/cc-api-v3-style-guide#pagination
*"order_by: a field on the resource to order the collection by; each
collection may choose a subset of fields that it can be sorted by "*

Would be nice to illustrate/precise if multiple sort order can be
supported, e.g. order_by=-state,-created

https://github.com/cloudfoundry/cc-api-v3-style-guide#query-parameters
Precise character escaping on query param values e.g. containing comma:
filtering on name="a,b"

https://github.com/cloudfoundry/cc-api-v3-style-guide#pagination-of-related-resources

GET /v3/apps/:guid?include=space,organization

with pluralized resource name should be GET /v3/apps/:guid?include=space*s*
,organization*s*

https://github.com/cloudfoundry/cc-api-v3-style-guide#pagination-of-related-resources
would be nice to include an example of a pagination request on a related
resource inclusion request (e.g,

/v2/spaces/ab09cd29-9420-f021-g20d-123431420768?include=apps&*include_apps_order_by*=-state,-date)

https://github.com/cloudfoundry/cc-api-v3-style-guide#proposal
Would useful to consider I18N of user-facing messages. Cf related thread
for service broker error messages at
http://cf-dev.70369.x6.nabble.com/cf-dev-Announcing-Experimental-support-for-Asynchronous-Service-Operations-tp287p1471.html
May be the CC API could accept a "Accept-Language: zh_Hans" header and try
to return localized messages when available in the accepted locale.

Thanks,

Guillaume.

On Wed, Sep 2, 2015 at 6:44 PM, Zach Robinson <zrobinson(a)pivotal.io> wrote:

Thanks James, I've just corrected the three issues you've noted so far

?
attachment.html

Re: So many hard-coded dropsonde destinations to metrons

Warren Fernandes
 

Dropsonde is a go library that allows the CF components using it to emit logs and metrics. The current flow for CF components is to emit their logs and metrics to their local metron agent which then forwards them to the Doppler servers in Loggregator. The metron agents only listen on the local interface and immediately signs the messages before sending them off to the Dopplers. So for now, the destination parameter for dropsonde will always point to the local metron agent.

Here is some more info on Metron https://github.com/cloudfoundry/loggregator/tree/develop/src/metron
Here is some more info on Dropsonde https://github.com/cloudfoundry/dropsonde
Re: Announcing Experimental support for Asynchronous Service Operations

Guillaume Berche
 

Great, thanks Dieu.

Guillaume.

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

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

?
attachment.html

Re: When will dea be replaced by diego?

Layne Peng
 

I think what he ask is, when the Diego-release will merge to cf-release. And also no need to install cf cli diego plugin, no need to enabe-diego to your app, then start. For the https://github.com/cloudfoundry-incubator/diego-design-notes/blob/master/migrating-to-diego.md#a-detailed-transition-timeline . it is said to be mid-september, is it right?
Re: When will dea be replaced by diego?

James Bayer
 

you can use diego today in place of DEAs.

diego requires the other cf components other than DEAs and Health Manager.

On Sun, Sep 6, 2015 at 11:49 PM, Meng, Xiangyi <xiangyi.meng(a)emc.com> wrote:

Hi,



Is there any plan when dea will not be supported and be replaced by diego?
Can I push application into diego without CF alongaside?



Any help will be appreciated.



Thanks,

Maggie
--
Thank you,

James Bayer

?
attachment.html

Re: How to execute multiple CF REST methods with an unique authentication

Juan Antonio Breña Moral <bren at juanantonio.info...>
 

Currently,

If I execute 2 operations with the same token, I receive the following message:

it.only("Using Login to execute 2 REST operations", function () {
this.timeout(2500);

CloudFoundry.setEndPoint(endPoint);

var token_endpoint = null;
var refresh_token = null;
return CloudFoundry.getInfo().then(function (result) {
token_endpoint = result.token_endpoint;
return CloudFoundry.login(token_endpoint, username, password);
}).then(function (result) {
return CloudFoundryApps.getApps(result.token_type, result.access_token);
}).then(function (result) {
return CloudFoundryApps.getApps(result.token_type, result.access_token);
}).then(function (result) {
console.log(result);
expect(true).to.equal(true);
});
});

Tests Response:

1) Cloud Foundry Using Login to execute 2 REST operations:
Error: the string "{\n \"code\": 10002,\n \"description\": \"Authenticati
on error\",\n \"error_code\": \"CF-NotAuthenticated\"\n}\n" was thrown, throw a
n Error :)
How to execute multiple CF REST methods with an unique authentication

Juan Antonio Breña Moral <bren at juanantonio.info...>
 

Hi,

Currently, I am developing a Web Application which interacts with CF REST API. At the moment, I have to log in the system every time when I execute any REST operation.

Example:

function createApp(appName, buildPack) {

var token_endpoint = null;
var app_guid = null;
var space_guid = null;
var domain_guid = null;
var routeName = null;
var route_guid = null;
var route_create_flag = false;

return new Promise(function (resolve, reject) {

CloudFoundry.getInfo().then(function (result) {
token_endpoint = result.token_endpoint;

return CloudFoundry.login(token_endpoint, username, password).then(function (result) {
return CloudFoundrySpaces.getSpaces(result.token_type, result.access_token).then(function (result) {
return new Promise(function (resolve) {
space_guid = result.resources[0].metadata.guid;
//console.log("Space guid: ", space_guid);
return resolve();
});
});
});
//Does exist the application?
}).then(function () {
var filter = {
'q': 'name:' + appName,
'inline-relations-depth': 1
};
return CloudFoundry.login(token_endpoint, username, password).then(function (result) {
return CloudFoundrySpaces.getSpaceApps(result.token_type, result.access_token, space_guid, filter);
});
}).then(function (result) {

//If exist the application, Stop
if (result.total_results === 1) {
console.log("Stop App: " + appName);
app_guid = result.resources[0].metadata.guid;
console.log("App guid: ", app_guid);
console.log(result.resources[0].entity.name);

return CloudFoundry.login(token_endpoint, username, password).then(function (result) {
return CloudFoundryApps.stopApp(result.token_type, result.access_token, app_guid);
});
}else {
//console.log("Create App");
return CloudFoundry.login(token_endpoint, username, password).then(function (result) {
return CloudFoundryApps.createApp(result.token_type, result.access_token, appName, space_guid, buildPack).then(function (result) {
return new Promise(function (resolve) {
//console.log(result);
app_guid = result.metadata.guid;
return resolve();
});
});
});
}
}).then(function () {
//TODO: How to make the inference?
return CloudFoundry.login(token_endpoint, username, password).then(function (result) {
return CloudFoundryDomains.getSharedDomains(result.token_type, result.access_token);
});
}).then(function () {
return CloudFoundry.login(token_endpoint, username, password).then(function (result) {
return CloudFoundryDomains.getDomains(result.token_type, result.access_token).then(function (result) {
return new Promise(function (resolve) {
domain_guid = result.resources[0].metadata.guid;
//console.log("Domain guid: " , domain_guid);
return resolve();
});
});
});
}).then(function () {
return CloudFoundry.login(token_endpoint, username, password).then(function (result) {
return CloudFoundryRoutes.checkRoute(result.token_type, result.access_token, appName, domain_guid).then(function (result) {
return new Promise(function (resolve) {
if (result.total_results === 1) {
console.log("Exist a Route");
//console.log(result.resources);
route_guid = result.resources[0].metadata.guid;
console.log("Route guid: ", route_guid);
return resolve(result);
}else {
//Add Route
route_create_flag = true; //Workaround
return resolve();
}

});
});
});
}).then(function () {
//TODO: Refactor syntax to code in the right place
if (route_create_flag) {
//Add Route
//console.log("Create a Route");
routeName = appName;
return CloudFoundry.login(token_endpoint, username, password).then(function (result) {
return CloudFoundryRoutes.addRoute(result.token_type, result.access_token, domain_guid, space_guid, routeName).then(function (result) {
return new Promise(function (resolve) {
//console.log(result);
route_guid = result.metadata.guid;
return resolve(result);
});
});
});
}else {
return new Promise(function (resolve) {
return resolve();
});
}
}).then(function () {
return CloudFoundry.login(token_endpoint, username, password).then(function (result) {
return CloudFoundryApps.associateRoute(result.token_type, result.access_token, appName, app_guid, domain_guid, space_guid, route_guid);
});
}).then(function (result) {
//console.log(result);
return resolve(result);
}).catch(function (reason) {
console.error("Error: " + reason);
return reject(reason);
});

});

}

The login method sends the following parameters in the requests to uaa:

var options = {
method: 'POST',
url: url,
headers: {
'Authorization': 'Basic Y2Y6',
'Content-Type': 'application/x-www-form-urlencoded'
},
form : {
grant_type: "password",
client_id: "cf",
username: username,
password: password
}
};

When I log into CF I receive the following response:

{ access_token: 'eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiI4YzRkMDRmMC1iYmU4LTRjNWUtODFmMS
04Y2M5ZDc4Y2ZhZDciLCJzdWIiOiIwNTQ0ODY5MS04YWU1LTQwZDktODU2Mi1kOWI4N2E2MTJiMzMiLC
JzY29wZSI6WyJzY2ltLnJlYWQiLCJjbG91ZF9jb250cm9sbGVyLmFkbWluIiwic2NpbS53cml0ZSIsIm
Nsb3VkX2NvbnRyb2xsZXIud3JpdGUiLCJwYXNzd29yZC53cml0ZSIsIm9wZW5pZCIsImNsb3VkX2Nvbn
Ryb2xsZXIucmVhZCIsImRvcHBsZXIuZmlyZWhvc2UiXSwiY2xpZW50X2lkIjoiY2YiLCJjaWQiOiJjZi
IsImF6cCI6ImNmIiwiZ3JhbnRfdHlwZSI6InBhc3N3b3JkIiwidXNlcl9pZCI6IjA1NDQ4NjkxLThhZT
UtNDBkOS04NTYyLWQ5Yjg3YTYxMmIzMyIsInVzZXJfbmFtZSI6ImFkbWluIiwiZW1haWwiOiJhZG1pbi
IsImlhdCI6MTQ0MTYxODAyOCwiZXhwIjoxNDQxNjE4NjI4LCJpc3MiOiJodHRwczovL3VhYS4zNy40OC
44MS4xNzAueGlwLmlvL29hdXRoL3Rva2VuIiwiYXVkIjpbImNmIiwic2NpbSIsImNsb3VkX2NvbnRyb2
xsZXIiLCJwYXNzd29yZCIsIm9wZW5pZCIsImRvcHBsZXIiXX0.W8_LC1g5eNM8NWVh68Pfx5FKVQe6C6
bvEulELHG9_9qsy3A3S50tUKNFQNjIhBPR18DyAJvs5iQy1pEcU2AciRa_3w83nLnzsgIJgwEFQ4mlCK
j9ovpsE55cM2-5JpFgBi8b-em-ce4WwSvFN9y1BhOAc2njNdJKJllR5Gh5kPE',
token_type: 'bearer',
refresh_token: 'eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiI0ZGViNjE3Yy00NDMxLTQzYTQtODU5Y
y1hNWQ1MmIwNTI4ZTIiLCJzdWIiOiIwNTQ0ODY5MS04YWU1LTQwZDktODU2Mi1kOWI4N2E2MTJiMzMiL
CJzY29wZSI6WyJzY2ltLnJlYWQiLCJjbG91ZF9jb250cm9sbGVyLmFkbWluIiwic2NpbS53cml0ZSIsI
mNsb3VkX2NvbnRyb2xsZXIud3JpdGUiLCJwYXNzd29yZC53cml0ZSIsIm9wZW5pZCIsImNsb3VkX2Nvb
nRyb2xsZXIucmVhZCIsImRvcHBsZXIuZmlyZWhvc2UiXSwiaWF0IjoxNDQxNjE4MDI4LCJleHAiOjE0N
DQyMTAwMjgsImNpZCI6ImNmIiwiaXNzIjoiaHR0cHM6Ly91YWEuMzcuNDguODEuMTcwLnhpcC5pby9vY
XV0aC90b2tlbiIsImdyYW50X3R5cGUiOiJwYXNzd29yZCIsInVzZXJfbmFtZSI6ImFkbWluIiwidXNlc
l9pZCI6IjA1NDQ4NjkxLThhZTUtNDBkOS04NTYyLWQ5Yjg3YTYxMmIzMyIsImF1ZCI6WyJjZiIsInNja
W0iLCJjbG91ZF9jb250cm9sbGVyIiwicGFzc3dvcmQiLCJvcGVuaWQiLCJkb3BwbGVyIl19.ji7tWinO
U1Wq6Y77ygSdF12ETG_TD9xQf82bVU01si3OZ9Ou4FG_HWv-CvQlJ7yh1KpH8emGsz92Omu45YEOyNU7
dOIRIMtP7u2DO_aWb2mzMBOwVnpFongyRkz_lbnqPgixW88v1DOJ2PY5KYoNxzxbIP98UX2xht6XXSqO
qww',
expires_in: 599,
scope: 'scim.read cloud_controller.admin scim.write cloud_controller.write pas
sword.write openid cloud_controller.read doppler.firehose',
jti: '8c4d04f0-bbe8-4c5e-81f1-8cc9d78cfad7' }


How to use the refresh token?
It is possible to reuse some fields of login response to reuse the authentication?

My idea could be:

1. Login in the system.
2. Call CF API n times, sending some kind of token.

At the moment, I send in the authorization header the auth token:

var options = {
method: 'GET',
url: url,
headers: {
'Authorization': token_type + ' ' + access_token
}
};

Many thanks in advance.

Juan Antonio
valid org, space and service instance name?

Buchen, Andreas <andreas.buchen@...>
 

Hi,
 
do you know what makes a valid org, space and service instance name?
 
I was able to find regular expressions for org and space (see below).
For service instance names I was able to find a length restriction.
 
From the database migrations, it is unclear to me to what number of characters it is limited on the database.
 
 
Andreas.

 
 
 
# Org
 
https://github.com/cloudfoundry/cloud_controller_ng/blob/0fc14205ce043c1f22a398c67ad080326f9ad115/app/models/runtime/organization.rb
ORG_NAME_REGEX = /\A[[:alnum:][:punct:][:print:]]+\Z/.freeze
 
# Space
 
https://github.com/cloudfoundry/cloud_controller_ng/blob/0fc14205ce043c1f22a398c67ad080326f9ad115/app/models/runtime/space.rb
SPACE_NAME_REGEX = /\A[[:alnum:][:punct:][:print:]]+\Z/.freeze
 
# Service Instance
 
validates_max_length 50, :name
https://github.com/cloudfoundry/cloud_controller_ng/blob/0fc14205ce043c1f22a398c67ad080326f9ad115/app/models/services/service_instance.rb#L81
 
# Database Migrations

https://github.com/cloudfoundry/cloud_controller_ng/blob/0fc14205ce043c1f22a398c67ad080326f9ad115/db/migrations/20130131184954_new_initial_schema.rb
7841 - 7860 of 9398