thx Erik

if you're using DEA's i believe the container stays around on the DEA for
about an hour or so by default before being removed.

assuming you're on a DEA, to investigate, you'd need to know the DEA and
the warden handle to investigate, log in to the DEA as an operator with
bosh, then go the warden depot directory, find the warden handle and
execute bin/wsh from the container handle directory.

see:
http://docs.cloudfoundry.org/running/troubleshooting/troubleshooting-apps.html#access-warden

in diego, removing containers happens right away, but diego is also going
to support ssh for active troubleshooting and could just increase the
memory and attach jvm tools for debugging purposes to troubleshoot.

good luck.

--
Thank you,

James Bayer

looks interesting, would love to hear if people try this approach. thanks
for sharing!

On Tue, Jun 23, 2015 at 12:11 PM, Leandro David Cacciagioni <
leandro.21.2008(a)gmail.com> wrote:

Guys here is the second post, this time featuring the new bosh-init CLI.
Any feedback from the community will be great, let me know your
experience!!!

Check it here: http://wp.me/p5G2dP-2z

Thanks,
Leandro.-

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

--
Thank you,

James Bayer

i personally don't like specifying the space in the "cf create-route"
command because it's one of the only cli commands i can think of that
requires specifying the space explicitly rather than using the currently
targeted space. i believe we should consider changing that now since a
single argument could be interpreted as the DOMAIN and the space could be
an explicit option parameter.

regarding the UX, i have tried some explicit examples with
comments/questions below:

cf create-service audit-service free-plan my-audit-service

this seems fine, it means create a service that is expected to have a
route-service endpoint the attributes, similar to a syslog drain service
right?

cf update-route foo example.com -s my-audit-service

we don't have "cf update-route" today. is the reason to make the
service_instance a parameter to account for more route options in the
future? what about a "naked domain" that does not have a hostname like
example.com? this cli pattern above does not really allow for that right?
perhaps it's better to have a similar syntax to the existing route commands:

cf update-route example.com -n foo -s my-audit-service

what about supplying an external URL that is not a service on the platform?
would we do that with a user provided service instance or an explicit URL
added to the route?

# using a service
cf create-route development example.com -n foo -s my-audit-service

# using an external URL
cf create-route development example.com -n foo -u https://audit.example.com

how would we remove a route-service from a route, by using a particular
option that means remove any route-service on the route?

cf update-route example.com -n foo -r

--
Thank you,

James Bayer

yes, this is how it should work.

The design proposal for route services
<https://docs.google.com/document/d/1bGOQxiKkmaw6uaRWGd-sXpxL0Y28d3QihcluI15FiIA/edit?usp=sharing>
suggests the following developer workflow to trigger forwarding app
requests to a route service:

cf create-service SERVICE PLAN SERVICE_INSTANCE
cf bind-service APP SERVICE_INSTANCE

This is a familiar workflow but for these kinds of services, this
introduces a lot of complexity and potentially surprising behavior. We are
seriously considering a slightly different UX that eliminates this
complexity and we believe is more intuitive. With this change, there is a
use case which would not be supported and we'd like to hear whether anyone
would miss it.

By binding different route services to applications that share a route,
requests could be forwarded to these different services according to
GoRouter's load balancing algorithm. Imagine a route (foo.example.com)
mapped to three applications A, B, and C. App A is bound to route service
X, app B is bound to route service Y, while app C is not bound to a route
service at all. Requests to the route would be forwarded to either route
service X or to route service Y or directly to app C.

Instead of associating the route service with an application, we are
proposing associating the route service with the route. This would mean
that all requests for a route would be forwarded to the same route service,
and could not bypass it. The following CLI usage demonstrates the developer
workflow:

cf create-service SERVICE PLAN SERVICE_INSTANCE
cf update-route HOST DOMAIN [-s SERVICE_INSTANCE]
or
cf create-route SPACE DOMAIN [-n HOSTNAME] [-s SERVICE_INSTANCE]

This change would also mean that route services would not need to be
bindable, simplifying service development, as applications are not expected
to need credentials to contact the route service directly and CF doesn't
need to know the application in order to make the forwarding decision.

Let me know if you have concerns about this change in approach.

Thank you,

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

Guys here is the second post, this time featuring the new bosh-init CLI.
Any feedback from the community will be great, let me know your
experience!!!

Check it here: http://wp.me/p5G2dP-2z

Thanks,
Leandro.-

The
/var/vcap/sys/log/loggregator_trafficcontroller/loggregator_trafficcontroller.stderr.log
file has frequent occurrences of this type of snippet


2015/06/16 18:16:13 http: panic serving <routerIP>:<port>: runtime error:
invalid memory address or nil pointer dereference
goroutine 1614338 [running]:
net/http.func·011()
/usr/local/go/src/pkg/net/http/server.go:1100 +0xb7
runtime.panic(0x7c1a40, 0xa4a993)
/usr/local/go/src/pkg/runtime/panic.c:248 +0x18d
github.com/cloudfoundry/loggregatorlib/server/handlers.(*httpHandler).ServeHTTP(0xc209a61e30,
0x7f5171a3b288, 0xc20abf5ae0, 0xc20b12bad0)

/var/vcap/data/compile/loggregator_trafficcontroller/loggregator/src/
github.com/cloudfoundry/loggregatorlib/server/handlers/http_handler.go:29
+0x2f5
trafficcontroller/dopplerproxy.(*Proxy).serveWithDoppler(0xc2080ac0d0,
0x7f5171a3b288, 0xc20abf5ae0, 0xc20b12bad0, 0xc20aaacd6b, 0xa,
0xc20aaacd46, 0x24, 0x0, 0x12a05f200, ...)

/var/vcap/data/compile/loggregator_trafficcontroller/loggregator/src/trafficcontroller/dopplerproxy/doppler_proxy.go:181
+0x152
trafficcontroller/dopplerproxy.(*Proxy).serveAppLogs(0xc2080ac0d0,
0x7f5171a3b288, 0xc20abf5ae0, 0xc20b12bad0)

/var/vcap/data/compile/loggregator_trafficcontroller/loggregator/src/trafficcontroller/dopplerproxy/doppler_proxy.go:170
+0x849
trafficcontroller/dopplerproxy.(*Proxy).ServeHTTP(0xc2080ac0d0,
0x7f5171a3b288, 0xc20abf5ae0, 0xc20b12b930)

/var/vcap/data/compile/loggregator_trafficcontroller/loggregator/src/trafficcontroller/dopplerproxy/doppler_proxy.go:86
+0x4d9
net/http.serverHandler.ServeHTTP(0xc2080046c0, 0x7f5171a3b288,
0xc20abf5ae0, 0xc20b12b930)
/usr/local/go/src/pkg/net/http/server.go:1673 +0x19f
net/http.(*conn).serve(0xc20a8c6f00)
/usr/local/go/src/pkg/net/http/server.go:1174 +0xa7e
created by net/http.(*Server).Serve
/usr/local/go/src/pkg/net/http/server.go:1721 +0x313
2015/06/22 11:28:58 http: panic serving <routerIP>:<port>: runtime error:
invalid memory address or nil pointer dereference
goroutine 2034572 [running]:
net/http.func·011()
/usr/local/go/src/pkg/net/http/server.go:1100 +0xb7
runtime.panic(0x7c1a40, 0xa4a993)
/usr/local/go/src/pkg/runtime/panic.c:248 +0x18d
github.com/cloudfoundry/loggregatorlib/server/handlers.(*httpHandler).ServeHTTP(0xc20bf2d820,
0x7f5171a3b288, 0xc20d33a000, 0xc20c8c9c70)

/var/vcap/data/compile/loggregator_trafficcontroller/loggregator/src/
github.com/cloudfoundry/loggregatorlib/server/handlers/http_handler.go:29
+0x2f5
trafficcontroller/dopplerproxy.(*Proxy).serveWithDoppler(0xc2080ac0d0,
0x7f5171a3b288, 0xc20d33a000, 0xc20c8c9c70, 0xc20c96e1eb, 0xa,
0xc20c96e1c6, 0x24, 0x0, 0x12a05f200, ...)

/var/vcap/data/compile/loggregator_trafficcontroller/loggregator/src/trafficcontroller/dopplerproxy/doppler_proxy.go:181
+0x152
trafficcontroller/dopplerproxy.(*Proxy).serveAppLogs(0xc2080ac0d0,
0x7f5171a3b288, 0xc20d33a000, 0xc20c8c9c70)

/var/vcap/data/compile/loggregator_trafficcontroller/loggregator/src/trafficcontroller/dopplerproxy/doppler_proxy.go:170
+0x849
trafficcontroller/dopplerproxy.(*Proxy).ServeHTTP(0xc2080ac0d0,
0x7f5171a3b288, 0xc20d33a000, 0xc20c8c9ad0)

/var/vcap/data/compile/loggregator_trafficcontroller/loggregator/src/trafficcontroller/dopplerproxy/doppler_proxy.go:86
+0x4d9
net/http.serverHandler.ServeHTTP(0xc2080046c0, 0x7f5171a3b288,
0xc20d33a000, 0xc20c8c9ad0)
/usr/local/go/src/pkg/net/http/server.go:1673 +0x19f
net/http.(*conn).serve(0xc20c9cc680)
/usr/local/go/src/pkg/net/http/server.go:1174 +0xa7e
created by net/http.(*Server).Serve
/usr/local/go/src/pkg/net/http/server.go:1721 +0x313


thx
GV

We encountered java out of memory issue in our CF env recently. We had enabled gc log for the application by setting JAVA_TOOL_OPTIONS: -Xloggc:gc.log. But when out of memory issue occurred, the application was stopped and removed. We can't get gc.log. Is there any way to keep the gc.log after application crashes? The CF version we are using is 197. Any advice would be appreciated.

Regards,
Maggie

Thanks Eric. I’ll pass this info along.

Josh Ghiloni
Senior Consultant
303.932.2202 o | 303.590.5427 m | 303.565.2794 f
jghiloni(a)ecsteam.com<mailto:jghiloni(a)ecsteam.com>

ECS Team
Technology Solutions Delivered
ECSTeam.com<http://ECSTeam.com>

Hi, Josh,

You're probably remembering some discussion about the 'placement pools' or
'placement constraints' feature. We haven't implemented any of that
functionality yet in Diego, but we do have a series of stories in the Diego
tracker (https://www.pivotaltracker.com/n/projects/1003146) with the
'+placement-constraints' label that represents the currently planned work
on that track. As we complete the necessary work to get Diego to be ready
for production use, we do expect it to be among the first of the new
features we start work on.

Thanks,
Eric, CF Runtime Diego PM

Hi Gianluca,

First: using the categories you described, this message is more of a
warning than an error - there should be no impact to your installation.

That said, it still shouldn't be happening. We will investigate further
why we are not providing a status before websocket closing. I'm creating a
chore to investigate further, and any additional info you could provide
would be great.

Thanks,
Erik

On Mon, Jun 22, 2015 at 8:07 AM, Gianluca Volpe <gvolpe1968(a)gmail.com>
wrote:

hi all

I'm having a long list of errors in loggregator_tc stdout log file, saying
:

{"timestamp":1433153574.809743166,"process_id":13854,"source":"loggregator
trafficcontroller","log_level":"error","message":"WebsocketListener.Start:
Error connecting to ws://
198.11.228.56:8081/apps/71725662-41b5-4b1f-a37f-da28b47ece75/stream:
websocket: close 1005
","data":null,"file":"/var/vcap/data/compile/loggregator_trafficcontroller/loggregator/src/trafficcontroller/listener/websocket_listen
er.go","line":73,"method":"trafficcontroller/listener.(*websocketListener).listenWithTimeout"}



found the source code responsible for the message:


https://github.com/gorilla/websocket/blob/master/conn.go
called from

https://github.com/cloudfoundry/loggregator/blob/develop/src/trafficcontroller/listener/websocket_listener.go



understood that 1005 is an error reporting to a connection being closed
missing the status information (as of RFC 6455, section 11.7)


// Close codes defined in RFC 6455, section 11.7.
const (
CloseNormalClosure = 1000
CloseGoingAway = 1001
CloseProtocolError = 1002
CloseUnsupportedData = 1003
CloseNoStatusReceived = 1005
CloseAbnormalClosure = 1006
CloseInvalidFramePayloadData = 1007
ClosePolicyViolation = 1008
CloseMessageTooBig = 1009
CloseMandatoryExtension = 1010
CloseInternalServerErr = 1011
CloseTLSHandshake = 1015
)


Each time a log is requested, this error is repeated for many of the
dopplers behind the traffic_controller (but rarely also for all of those),
and I'm still not able to understand if this should be a blocking error or
a sort of warning (I'm not receiving complaints from the users) due to
firehose connection method, but I need to know what is happening and how to
prevent any problem.

thx
GV


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

Hi MinhND,

The collector is not deprecated yet - where are you seeing this
property configured?

I found the minimal example AWS yml in release 210, where we have it
set to one I believe [1].

Thanks,
Erik

[1]
https://github.com/cloudfoundry/cf-release/blob/v210/example_manifests/minimal-aws.yml#L241-L250

On Sun, Jun 21, 2015 at 8:44 PM, Nguyen Dang Minh <nguyendangminh(a)gmail.com>
wrote:

Hi guys,

I've just upgraded to the CF 210 and see that the Collector is removed
(instance = 0). Is the Collector officially deprecated? I don't see any
notice in the CF release note.

If it is true, how could I get the DEA metrics now? It seems that the DEA
doesn't send metrics to Doppler at all.

Best regards,
MinhND

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

Shannon,

The polling API in the the Asynchronous Operations documentation suffers
from the same problem. Perhaps the .../last_operation request could include
a service_id query parameter?

Thanks,

-Mike

hi all

I'm having a long list of errors in loggregator_tc stdout log file, saying :

{"timestamp":1433153574.809743166,"process_id":13854,"source":"loggregator
trafficcontroller","log_level":"error","message":"WebsocketListener.Start:
Error connecting to ws://
198.11.228.56:8081/apps/71725662-41b5-4b1f-a37f-da28b47ece75/stream:
websocket: close 1005
","data":null,"file":"/var/vcap/data/compile/loggregator_trafficcontroller/loggregator/src/trafficcontroller/listener/websocket_listen
er.go","line":73,"method":"trafficcontroller/listener.(*websocketListener).listenWithTimeout"}



found the source code responsible for the message:


https://github.com/gorilla/websocket/blob/master/conn.go
called from
https://github.com/cloudfoundry/loggregator/blob/develop/src/trafficcontroller/listener/websocket_listener.go



understood that 1005 is an error reporting to a connection being closed
missing the status information (as of RFC 6455, section 11.7)


// Close codes defined in RFC 6455, section 11.7.
const (
CloseNormalClosure = 1000
CloseGoingAway = 1001
CloseProtocolError = 1002
CloseUnsupportedData = 1003
CloseNoStatusReceived = 1005
CloseAbnormalClosure = 1006
CloseInvalidFramePayloadData = 1007
ClosePolicyViolation = 1008
CloseMessageTooBig = 1009
CloseMandatoryExtension = 1010
CloseInternalServerErr = 1011
CloseTLSHandshake = 1015
)


Each time a log is requested, this error is repeated for many of the
dopplers behind the traffic_controller (but rarely also for all of those),
and I'm still not able to understand if this should be a blocking error or
a sort of warning (I'm not receiving complaints from the users) due to
firehose connection method, but I need to know what is happening and how to
prevent any problem.

thx
GV

Hi guys,

I've just upgraded to the CF 210 and see that the Collector is removed
(instance = 0). Is the Collector officially deprecated? I don't see any
notice in the CF release note.

If it is true, how could I get the DEA metrics now? It seems that the DEA
doesn't send metrics to Doppler at all.

Best regards,
MinhND

Thanks for clarifying this, Scott. There are still a few properties in the manifest file that I am not sure about: no-hostname, random-route, no-route.

On first reading I don’t see these in the maven plugin. But clearly the maven plugin was what I was looking for.

Thanks again.

Azad

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

Azad,

You are correct, the Java client does not support creating an application
based on the data in manifest.yml.

With the cf CLI and manifest.yml, you specify the host(s) (i.e. subdomain)
and domain(s) separately, and these are combined into one ore more routes.
So with a host of "myapp" and a domain of "apps.mycf.org", the full route
would be "myapp.apps.mycf.org". With the Java client, each route (host +
domain) is provided in absolute form in the "List<String> uris" parameter
of the "createApplication()" method. To match the CLI example, you would
specify one "uri" String with the value "myapp.apps.mycf.org". The domain
part of the uri must be a valid domain in your CF deployment (you can see
the list with "cf domains").

The best sample code for the Java client is the Maven and Gradle plugins
there are in the same GitHub repository.
The Maven plugin is here:
https://github.com/cloudfoundry/cf-java-client/tree/master/cloudfoundry-maven-plugin
.
The code in the Maven plugin that creates an application, uploads the bits,
and waits for the app to start is here:
https://github.com/cloudfoundry/cf-java-client/blob/master/cloudfoundry-maven-plugin/src/main/java/org/cloudfoundry/maven/AbstractPush.java

Scott

From: <Bolour>, GE Global Research <Azad>, GE <Azad.Bolour(a)ge.com<mailto:Azad.Bolour(a)ge.com>>
Date: Friday, June 19, 2015 at 10:05 AM
To: "cf-dev(a)lists.cloudfoundry.org<mailto:cf-dev(a)lists.cloudfoundry.org>" <cf-dev(a)lists.cloudfoundry.org<mailto:cf-dev(a)lists.cloudfoundry.org>>
Cc: "Vydra, David (GE Global Research)" <david.vydra(a)ge.com<mailto:david.vydra(a)ge.com>>
Subject: manifest files and the Java client

Hi,

Correct me if I am wrong, but as far as I can tell, the cloud foundry Java API does not directly support the creation of an application based on the the manifest file as defined in:

http://docs.cloudfoundry.org/devguide/deploy-apps/manifest.html

My reading of the code is that the implementation of the create application function in the Java client boils down to the createApplication method of the class CloudControllerClientImpl:

public void createApplication(
String appName, Staging staging, Integer disk, Integer memory,
List<String> uris, List<String> serviceNames)

But the uris parameters does not appear in the manifest specification.

How should I define the uris parameter in terms of the fields in the manifest? Is there sample code somewhere that would clue me into how to do this?

Many thanks.

Azad

Azad,

You are correct, the Java client does not support creating an application
based on the data in manifest.yml.

With the cf CLI and manifest.yml, you specify the host(s) (i.e. subdomain)
and domain(s) separately, and these are combined into one ore more routes.
So with a host of "myapp" and a domain of "apps.mycf.org", the full route
would be "myapp.apps.mycf.org". With the Java client, each route (host +
domain) is provided in absolute form in the "List<String> uris" parameter
of the "createApplication()" method. To match the CLI example, you would
specify one "uri" String with the value "myapp.apps.mycf.org". The domain
part of the uri must be a valid domain in your CF deployment (you can see
the list with "cf domains").

The best sample code for the Java client is the Maven and Gradle plugins
there are in the same GitHub repository.
The Maven plugin is here:
https://github.com/cloudfoundry/cf-java-client/tree/master/cloudfoundry-maven-plugin
.
The code in the Maven plugin that creates an application, uploads the bits,
and waits for the app to start is here:
https://github.com/cloudfoundry/cf-java-client/blob/master/cloudfoundry-maven-plugin/src/main/java/org/cloudfoundry/maven/AbstractPush.java

Scott


On Fri, Jun 19, 2015 at 12:05 PM, Bolour, Azad (GE Global Research,
consultant) <Azad.Bolour(a)ge.com> wrote:

Hi,

Correct me if I am wrong, but as far as I can tell, the cloud foundry Java
API does not directly support the creation of an application based on the
the manifest file as defined in:

http://docs.cloudfoundry.org/devguide/deploy-apps/manifest.html

My reading of the code is that the implementation of the create
application function in the Java client boils down to the createApplication
method of the class CloudControllerClientImpl:

public void createApplication(
String appName, Staging staging, Integer disk, Integer memory,
List<String> uris, List<String> serviceNames)

But the uris parameters does not appear in the manifest specification.

How should I define the uris parameter in terms of the fields in the
manifest? Is there sample code somewhere that would clue me into how to do
this?

Many thanks.

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

Hey Deepak,

We are talking only about the Cloud Controller API. Those APIs would be
available to all developers. We're not sure what you are looking for beyond
that.

Joseph & Zak
CF Runtime Team

On Wed, Jun 17, 2015 at 10:27 AM, Deepak Vij (A) <deepak.vij(a)huawei.com>
wrote:

Hi Zak and Joseph, thanks for your response. Would this capability be
available only for Cloud Controller API or for rest of the platform API set
as well? Also, would the same capability be available for end application
developers (PaaS developers) so that the same application interface
metadata is generated across the board within CF PaaS environment - that
was my key goal for this discussion (something like JSON Schema for Heroku).

As I mentioned earlier that having a standardized application interface
such as WADL/JSON/Swagger/RAML allows us to enforce Deployment Governance
at the time of deploying applications within Cloud Foundry. In order to be
able to expose business capabilities such as Telecom APIs, Deployment
Governance (i.e. API Versioning & Backward Compatibility, Dependency
Management, and other API Policy Validations etc.) is very important
requirement not just for telecom industry but for any industry planning to
monetize their APIs created within CF PaaS environment. Thanks.

Regards,
Deepak Vij

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

Message: 1
Date: Tue, 16 Jun 2015 15:04:53 -0700
From: CF Runtime <cfruntime(a)gmail.com>
To: "Discussions about Cloud Foundry projects and the system overall."
<cf-dev(a)lists.cloudfoundry.org>
Subject: Re: [cf-dev] Need for machine-readable ?Application
Interface?
Message-ID:
<CAOb01c9s=qAG66YJ+vdh8g8R4=
HU_BX3ee1_5msNPNt1QuNBQg(a)mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

It is something we are thinking about for the V3 cloud controller API, but
no formal decisions have been made at this point. So feedback and
suggestions are certainly welcome.

Zak and Joseph
CF Runtime Team

On Tue, Jun 16, 2015 at 2:51 PM, Deepak Vij (A) <deepak.vij(a)huawei.com>
wrote:

Hi folks, I would like to start a thread on the need for
machine-readable ?*Application Interface*? supported at the platform
level. Essentially, this interface describes details such as available
methods/operations, inputs/outputs data types (schema), application
dependencies etc. Any standard specifications language can be used for
this purpose, as long as it clearly describes the schema of the requests
and responses ? one can use Web Application Description Language (WADL),
Swagger, RESTful API Modeling Language (RAML), JSON Schema (something

like *JSON

Schema for Heroku Platform APIs*) or any other language that provides
similar functionality. These specifications are to be automatically

derived

from the code and are typically part of the application development

process

(e.g. generated by the build system).



Such functionality can have lots of usage scenarios:

1. First and foremost, Deployment Governance for API Management

(our

main vested interest) ? API Versioning & Backward Compatibility,
Dependency Management and many more as part of the comprehensive telecom
API Management capabilities which we are currently in the process of
building out.

2. Auto-creating client libraries for your favorite programming
language.

3. Automatic generation of up-to-date documentation.

4. Writing automatic acceptance and integration tests etc.



From historical perspective, in the early 2000s when SOA started out, the
mindset was to author the application contract-first (application

interface

using WSDL at that time) and subsequently generate and author code from

the

application interface. With the advent of RESTful services, REST

community

initially took a stand against such metadata for applications. Although,

a

number of metadata standards have none-the-less emerged over the last
couple of years, mainly fueled by the use case scenarios described

earlier.

Based on my knowledge, none of this currently exists within Cloud Foundry
at the platform level. It would be highly desirable to have a standard
common ?*application interface*? definition at the platform level,
agnostic of the underlying application development frameworks.



I hope this all makes sense. I think this is something could be very
relevant to the ?Utilities? PMC. I will also copy&paste this text under
?Utilities? PMC-notes on the github.



I would love to hear from the community on this. Thanks.



Regards,

Deepak Vij

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

Hi,

Correct me if I am wrong, but as far as I can tell, the cloud foundry Java API does not directly support the creation of an application based on the the manifest file as defined in:

http://docs.cloudfoundry.org/devguide/deploy-apps/manifest.html

My reading of the code is that the implementation of the create application function in the Java client boils down to the createApplication method of the class CloudControllerClientImpl:

public void createApplication(
String appName, Staging staging, Integer disk, Integer memory,
List<String> uris, List<String> serviceNames)

But the uris parameters does not appear in the manifest specification.

How should I define the uris parameter in terms of the fields in the manifest? Is there sample code somewhere that would clue me into how to do this?

Many thanks.

Azad