Hello Lucas,

CF takes care of authenticating (when needed) with the Docker registry. No
need to run anything more than `cf push`.

The output you included suggests that this was a network error on your side
or Dockerhub was temporarily unavailable. If the problem persists, I'd
suggest trying to use the same image from Dockerhub with Docker itself. If
Docker works and CF doesn't, there may be a network connectivity issue with
PCF Dev and/or Virtualbox.


On Fri, Aug 18, 2017 at 10:00 AM, lucas.reginato <lucas.reginato(a)gmail.com>
wrote:

I was taking a look into the error message and how to login to
registry-1.docker.io.
In order to properly login, we need to follow the details of this webpage:
https://docs.docker.com/registry/spec/auth/token/#requesting-a-token

In a high level:
- need to get a token at https://auth.docker.io/token with some query
parameters.
- then do the login again at registry-1.docker.io.
- and then proceed to the next operations.

Do we know if these steps are executed while pushing a docker image by PCF
Dev?

Thanks,

-Lucas



--
View this message in context: http://cf-dev.70369.x6.nabble.
com/Cf-fails-to-push-a-docker-image-tp7761p7767.html
Sent from the CF Dev mailing list archive at Nabble.com.

--
George Lestaris
GrootFS <https://www.github.com/cloudfoundry/grootfs> Product Manager, Cloud
Foundry <https://www.cloudfoundry.org/>, Pivotal <https://www.pivotal.io/>

I was taking a look into the error message and how to login to
registry-1.docker.io.
In order to properly login, we need to follow the details of this webpage:
https://docs.docker.com/registry/spec/auth/token/#requesting-a-token

In a high level:
- need to get a token at https://auth.docker.io/token with some query
parameters.
- then do the login again at registry-1.docker.io.
- and then proceed to the next operations.

Do we know if these steps are executed while pushing a docker image by PCF
Dev?

Thanks,

-Lucas



--
View this message in context: http://cf-dev.70369.x6.nabble.com/Cf-fails-to-push-a-docker-image-tp7761p7767.html
Sent from the CF Dev mailing list archive at Nabble.com.

The CF CLI team cut 6.29.1 today.
Deb, yum and Homebrew repos have been updated; binaries, installers and link to release notes are available at:

https://github.com/cloudfoundry/cli#downloads

Corrupted config.json

There have been reports of the local config.json file getting corrupted, or truncated to 0 bytes. When this happens, most commands fail with an "Error read/writing config: unexpected end of JSON input" message, and deleting the file was the only remedy.
This release includes various improvements to reduce the chance of this file becoming corrupted.
The cf CLI uses this file to persist settings (see e.g. cf config), the targeted API endpoint, org and space, etc. (#1071<https://github.com/cloudfoundry/cli/issues/1071>, #1199<https://github.com/cloudfoundry/cli/issues/1199>)

Fixed regressions

* Refactored api did not sanitize the API endpoint url, causing cf auth to fail since cf CLI 6.23.0 when the specified endpoint URL had a trailing slash. (#1186<https://github.com/cloudfoundry/cli/issues/1186>)
* Refactored auth used the UAA token endpoint instead of the login server authorization endpoint, causing authentication to fail since cf CLI v6.27.0 on CF targets with a login server not collocated with the UAA server. (#1192<https://github.com/cloudfoundry/cli/issues/1192>)

Refactored commands

We are in the process of creating a more consistent user experience; our goal is to standardize UI output.
For example, warnings and errors will consistently be outputted to stderr instead of stdout and English table and key-value headers displayed in lowercase.
As we iterate through the list of commands, we are also focusing on improving performance and stability.
Please review your scripts if they depend on the output of these commands.

List of improved commands in this release:

* oauth-token
* ssh-code

Updated commands

* set-space-role now displays a usage error message with the right argument names when insufficient arguments are provided.

New & updated community plugins

* java-plugin v1.1.0: https://github.com/SAP/cf-cli-java-plugin
* top v0.8.8: https://github.com/ECSTeam/cloudfoundry-top-plugin
* cf-aklogin v1.2.9: https://github.com/armakuni/cf-aklogin
* Diego-Enabler v1.2.4: https://github.com/cloudfoundry-incubator/Diego-Enabler
Enjoy!


Regards,
Dies Koper
Cloud Foundry Product Manager - CLI

Here you go: https://asciinema.org/a/133943

--

*Zach Brown* | Strategic Product Owner

650-954-0427 - mobile

zbrown(a)pivotal.io

<http://pivotal.io>

We are looking to use Cloud Foundry for an on-premises "fog" platform. We would like to keep a minimal footprint and run on 1-5 small servers in production. Is this practical with Cloud Foundry? I know OpenStack struggles to run on 1-2 machines.

Thanks,
Mike

I'll take a crack at one.

On Thu, Aug 17, 2017 at 12:58 PM, Chris Clark <cclark(a)cloudfoundry.org>
wrote:

Hello all,

A while back I'd asked for help with a few sample apps to go on the CF
website. Thank you to everyone who helped out with that! They are up,
here: https://www.cloudfoundry.org/platform/.

Would anyone be willing and able to make a quick video of a .NET app to
add to those we've already done? Basically, use asciinema
<https://asciinema.org/> to record a 3-5 minute (approx.) video of your
terminal window as you make a hello_world app, push it to a Cloud Foundry
instance of your choice, and than curl it to show that it is working.

Please reach out if you'd be willing to help out with this, or if you have
any questions. Thank you!

- Chris

--

*Zach Brown* | Strategic Product Owner

650-954-0427 - mobile

zbrown(a)pivotal.io

<http://pivotal.io>

I like the new demo videos of each language. Nice.

________________________________
From: Chris Clark <cclark(a)cloudfoundry.org>
Sent: Friday, August 18, 2017 5:58:09 AM
To: Discussions about Cloud Foundry projects and the system overall.
Cc: Melissa Logan
Subject: [cf-dev] Sample .NET hello_world app

Hello all,

A while back I'd asked for help with a few sample apps to go on the CF website. Thank you to everyone who helped out with that! They are up, here: https://www.cloudfoundry.org/platform/.

Would anyone be willing and able to make a quick video of a .NET app to add to those we've already done? Basically, use asciinema<https://asciinema.org/> to record a 3-5 minute (approx.) video of your terminal window as you make a hello_world app, push it to a Cloud Foundry instance of your choice, and than curl it to show that it is working.

Please reach out if you'd be willing to help out with this, or if you have any questions. Thank you!

- Chris

Hello,

My environment:
- Windows 10 Pro 64 bits
- VirtualBox 5.1.22
- PCF Dev pcfdev-v0.461.0.ova
- Home nework, using a wifi router.

I start my PCF Dev with the following command line:
cf dev start
I do not inform insecure docker registries as I assume that
registry-1.docker.io is a secure one.
I can submit any other application that uses a buildpack, but not docker
images to my PCF Dev.
And when I push the docker image cloudfoundry/test-app, it fails with the
error message:

C:\Temp\cf-docker-apps>cf push test-app --docker-image cloudfoundry/test-app
Creating app test-app in org pcfdev-org / space pcfdev-space as admin...
OK

Creating route test-app.local.pcfdev.io...
OK

Binding test-app.local.pcfdev.io to test-app...
OK


Starting app test-app in org pcfdev-org / space pcfdev-space as admin...
Creating container
Successfully created container
Staging...
Staging process started ...
Failed to talk to docker registry: Get https://registry-1.docker.io/v2/:
net/http: request canceled while waiting for connection (Client.Timeout
exceeded while awaiting headers)
Failed to talk to docker registry: Get http://registry-1.docker.io/v2/:
net/http: request canceled while waiting for connection (Client.Timeout
exceeded while awaiting headers)
Staging process failed: Exit trace for group:
builder exited with error: failed to fetch metadata from
[cloudfoundry/test-app] with tag [latest] and insecure registries [] due to
Get http://registry-1.docker.io/v2/: net/http: request canceled while
waiting for connection (Client.Timeout exceeded while awaiting headers)
Exit status 2
Staging Failed: Exited with status 2
Destroying container
Successfully destroyed container

FAILED
Error restarting application: StagingError

TIP: use 'cf logs test-app --recent' for more information

Any tips fopr me?

Thanks,

-Lucas Reginato



--
View this message in context: http://cf-dev.70369.x6.nabble.com/Cf-fails-to-push-a-docker-image-tp7761.html
Sent from the CF Dev mailing list archive at Nabble.com.

Hello all,

A while back I'd asked for help with a few sample apps to go on the CF
website. Thank you to everyone who helped out with that! They are up,
here: https://www.cloudfoundry.org/platform/.

Would anyone be willing and able to make a quick video of a .NET app to add
to those we've already done? Basically, use asciinema
<https://asciinema.org/> to record a 3-5 minute (approx.) video of your
terminal window as you make a hello_world app, push it to a Cloud Foundry
instance of your choice, and than curl it to show that it is working.

Please reach out if you'd be willing to help out with this, or if you have
any questions. Thank you!

- Chris

Hi Shannon,

We have occasionally renamed service plan names in the past. For example,
we introduced a new experimental service and named the plan "alpha" (in
addition to the plan description detailing the alpha semantics). When we
managed to improve quality of service for this experimental service without
requiring users involvement (such as rebinds or creating new service
instance), then we renamed the "alpha" plan into "default".

Most of our applications don't leverage the "plan" key in the VCAP_SERVICES
[1] so a stale value following a renaming had not much impact.

[1]
http://docs.cloudfoundry.org/devguide/deploy-apps/environment-variable.html#VCAP-SERVICES


Guillaume.

On Wed, Aug 9, 2017 at 9:40 PM, Sascha Matzke <sascha.matzke(a)didolo.org>
wrote:

We've refrained from renaming and extended the service catalog of affected
brokers with additional "new" entries with new names and UUIDs and actively
phased out the old ones (restricted access etc.).

There are so many delicate mechanisms bound to the names of marketplace
services (triggers in buildpacks, spring cloud magic) that renaming
existing services seemed to risky.

A clearer contract about how to handle service and service plan names
would definitely help (are the names just display names or is it ok to use
them otherwise).

Best,

Sascha


On Tue, Aug 8, 2017 at 11:58 PM, Shannon Coen <scoen(a)pivotal.io> wrote:

The Service Broker API currently supports modifying the service name and
plan name fields, as a uuid is used as the unique identifier. These names
are used in CLI workflows, and are used by applications to parse the
VCAP_SERVICES environment variable to identify credentials. In practice, if
these names are changed it may require updating an application to use the
new service name to identify credentials.

The metadata field is often used to expose display names for services and
plans.

The Open Service Broker API working group is interested to know how often
these names actually change, and whether they could be considered immutable
in the future.

Best,

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

--
Through the darkness of future past
the magician longs to see
One chants out between two worlds
*Fire walk with me*.

On Wed, Aug 16, 2017 at 11:21 AM, Lucas Reginato <lucas.reginato(a)gmail.com>
wrote:

Hi Dan,

Thanks for the clarification and for the good pointers.

About the TCP routing,
Yep, I configured the TCP routing in my PCF Dev.
And I was able to access the web application certificate that I created
using with keytool.
That is great, that is part of the result that I am looking for.
Thanks again for the great pointers.

About the Spring boot, WAR and Tomcat 8.5.X, yes, I also read all about
that.
I tried Spring boot and I make it work as well.

But it is interesting what I just found.

The CF stack (cflinuxfs2) is used to create Linux containers.
In my case, the java-buildpack will configure OpenJDK8 and Tomcat8, in
order to run the java webapps.
And cflinuxfs2 is derived from Ubuntu 14.04 (Trusty Tahr).
Now, Ubuntu 14.04 has the OpenSSL library 1.0.1f.
And the Tomcat 8.X APR native library (which is used to enabled HTTP2 on
Tomcat) requires OpenSSL 1.0.2 in order to run with success.

Can you see the problem?
The current stack (cflinuxfs2) does not have the correct OpenSSL libraries
that are need to run the Tomcat 8.X APR native library.
So, I understand that I cannot use the current stack cflinuxfs2.

Yes, that definitely seems to be an issue.

In this case, I still have 2 options:
Option A) create my own stack;
Option B) use docker and deploy a docker container (which will have
java+tomcat+libraries) to CF.

I don't think this is necessarily an easier option, but you could in theory
compile & bring your own OpenSSL library in addition to Tomcat Native.
That would at least allow you to continue using the build pack to obtain
Java & Tomcat.

For what it's worth, I believe there's a more up-to-date Ubuntu stack
coming. No idea on a time frame though.

Dan

Please let me know your thoughts on this.

And Thanks again for your comments.

-Lucas







On Mon, Aug 14, 2017 at 6:01 PM, Daniel Mikusa <dmikusa(a)pivotal.io> wrote:

On Mon, Aug 14, 2017 at 10:22 AM, Lucas Reginato <
lucas.reginato(a)gmail.com> wrote:

Hi Dan,

Thanks for the prompt reply.

And a few question to you again.
In this case, the front end will do HTTP2 requests, and this user
request will reach the PCF Load Balancer.
*I did not look into this yet, but does PCF Load Balancer supports HTTP2
requests?*
If the PCF Load Balancer does not support HTTP2 requests, than, this
will not work.

Not sure what you mean here exactly. With TCP routing, you get a routing
group (which I believe is a group of HAProxy nodes) that are forwarding
traffic from a specific external port (mapped via the cf cli) to your
application's internal port running on CF. This happens at layer 4 so it's
agnostic of the layer 7 protocol that you choose to run (i.e. it doesn't
care if you use HTTP, HTTPS, HTTP/2, MQTT or some other protocol).

You can see a graphic of the traffic flow here.

https://docs.cloudfoundry.org/adminguide/enabling-tcp-routing.html

In this graphic, "Load Balancer" is not provided by the platform. That
would be something you'd need to have external to the platform. If you
don't want or have an external load balancer, you can skip it but I believe
it's required for HA.

This is all necessary because GoRouter does not support HTTP/2 at the
moment and so you cannot use a standard HTTP route to direct traffic to
your application. You have to use the TCP routing support, which has a
different path to the application.

Then, the PCF Load Balancer will send the HTTP2 request to CF router.
And the CF router will route this HTTP2 request to a TCP route, to reach
an application.
*I don't know if the TCP request will be handled as a "normal" request
by a java Rest API. *
By normal I mean HTTP/HTTPS requests.

This will require a little additional configuration. A standard Java app
deployed to CF with the Java build pack isn't going to be configured with
TLS/HTTPS or HTTP/2. It's just going to listen for HTTP requests on the
assigned port. You would need to adjust the configuration to enable
TLS/HTTPS, including supplying TLS certs & enable the HTTP/2 connector in
Tomcat.

If you're using Spring Boot, I don't think this would be too tricky as it
allows you to adjust the configuration of the embedded Tomcat server. See
here -> https://docs.spring.io/spring-boot/docs/current/reference
/html/howto-embedded-servlet-containers.html#howto-configure-ssl

If you're deploying a stock WAR file it will be a little trickier as
you're going to need to tell the build pack to configure Tomcat in the way
that you want, which probably means using external config ->
https://github.com/cloudfoundry/java-buildpack/blob/
master/docs/container-tomcat.md#external-tomcat-configuration

For either case, you'll need Tomcat 8.5+ so you can get HTTP2 support in
Tomcat. I don't think this should be an issue if you're using a recent
Java build pack or Spring Boot version.

Hope that helps!

Dan

Just to make sure we are on the same page, my goal is to use HTTP2, so I
can go beyond the HTTP/1.1 limit (beyond 6 TCP connections between source
and target endpoint).
With that I can have more open connections to the endpoint and have more
data retrieved to the front end.

Thanks again for your inputs on this.

-Lucas





On Fri, Aug 11, 2017 at 5:53 PM, Daniel Mikusa <dmikusa(a)pivotal.io>
wrote:

You're correct. You cannot use HTTP routes with HTTP/2. At the
moment, if you want to use HTTP/2 you could do so by using a TCP route.
Apps that have TCP routes bound to them receive the TCP traffic directly
and so you can do things like HTTP/2.

https://docs.cloudfoundry.org/devguide/deploy-apps/routes-do
mains.html#http-vs-tcp-routes

Dan


On Fri, Aug 11, 2017 at 5:40 AM, Lucas Reginato <
lucas.reginato(a)gmail.com> wrote:

Hi,

I was reading some blogs and email threads about pivotal cloud foundry
and http2.

And my understanding is that currently pcf does not support http2.
Also the Gorouter, used as the router layer in pcf does not support
http2.

If possible, can you share the current status of this work in pcf or
anything aobut this with the community?

Thanks a lot.

-Lucas Reginato

--
Lucas Reginato

--
Lucas Reginato

Hi Dan,

Thanks for the clarification and for the good pointers.

About the TCP routing,
Yep, I configured the TCP routing in my PCF Dev.
And I was able to access the web application certificate that I created
using with keytool.
That is great, that is part of the result that I am looking for.
Thanks again for the great pointers.

About the Spring boot, WAR and Tomcat 8.5.X, yes, I also read all about
that.
I tried Spring boot and I make it work as well.

But it is interesting what I just found.

The CF stack (cflinuxfs2) is used to create Linux containers.
In my case, the java-buildpack will configure OpenJDK8 and Tomcat8, in
order to run the java webapps.
And cflinuxfs2 is derived from Ubuntu 14.04 (Trusty Tahr).
Now, Ubuntu 14.04 has the OpenSSL library 1.0.1f.
And the Tomcat 8.X APR native library (which is used to enabled HTTP2 on
Tomcat) requires OpenSSL 1.0.2 in order to run with success.

Can you see the problem?
The current stack (cflinuxfs2) does not have the correct OpenSSL libraries
that are need to run the Tomcat 8.X APR native library.
So, I understand that I cannot use the current stack cflinuxfs2.

In this case, I still have 2 options:
Option A) create my own stack;
Option B) use docker and deploy a docker container (which will have
java+tomcat+libraries) to CF.

Please let me know your thoughts on this.

And Thanks again for your comments.

-Lucas

--
Lucas Reginato

Damn iPhone...

FINAL REMINDER

Join us tomorrow @ 8a PDT for community updates and two brief talks:

1. Stephen Levine of Pivotal on CF-Local [2]
2. Yours truly of IBM Cloud on CF-Extensions [3]

Zoom detail in agenda [1].

Best,

dr.max

ibm cloud labs
sillicon valley, ca
usa
maximilien.org

Sent from my iPhone

[1]
https://docs.google.com/document/d/1SCOlAquyUmNM-AQnekCOXiwhLs6gveTxAcduvDcW_xI/edit#heading=h.o44xhgvum2we

[2] https://github.com/sclevine/cflocal

[3] https://github.com/cloudfoundry-incubator/cf-extensions

FINAL REMINDER

Join us tomorrow @ 8a PDT for community updates and two brief talks:

1. Stephen Levine of Pivotal on CF-Local [2]
2. Yours truly if

dr.max

ibm cloud labs
sillicon valley, ca
usa
maximilien.org

Sent from my iPhone

On Mon, Aug 14, 2017 at 10:22 AM, Lucas Reginato <lucas.reginato(a)gmail.com>
wrote:

Hi Dan,

Thanks for the prompt reply.

And a few question to you again.
In this case, the front end will do HTTP2 requests, and this user request
will reach the PCF Load Balancer.
*I did not look into this yet, but does PCF Load Balancer supports HTTP2
requests?*
If the PCF Load Balancer does not support HTTP2 requests, than, this will
not work.

Not sure what you mean here exactly. With TCP routing, you get a routing
group (which I believe is a group of HAProxy nodes) that are forwarding
traffic from a specific external port (mapped via the cf cli) to your
application's internal port running on CF. This happens at layer 4 so it's
agnostic of the layer 7 protocol that you choose to run (i.e. it doesn't
care if you use HTTP, HTTPS, HTTP/2, MQTT or some other protocol).

You can see a graphic of the traffic flow here.

https://docs.cloudfoundry.org/adminguide/enabling-tcp-routing.html

In this graphic, "Load Balancer" is not provided by the platform. That
would be something you'd need to have external to the platform. If you
don't want or have an external load balancer, you can skip it but I believe
it's required for HA.

This is all necessary because GoRouter does not support HTTP/2 at the
moment and so you cannot use a standard HTTP route to direct traffic to
your application. You have to use the TCP routing support, which has a
different path to the application.

Then, the PCF Load Balancer will send the HTTP2 request to CF router.
And the CF router will route this HTTP2 request to a TCP route, to reach
an application.
*I don't know if the TCP request will be handled as a "normal" request by
a java Rest API. *
By normal I mean HTTP/HTTPS requests.

This will require a little additional configuration. A standard Java app
deployed to CF with the Java build pack isn't going to be configured with
TLS/HTTPS or HTTP/2. It's just going to listen for HTTP requests on the
assigned port. You would need to adjust the configuration to enable
TLS/HTTPS, including supplying TLS certs & enable the HTTP/2 connector in
Tomcat.

If you're using Spring Boot, I don't think this would be too tricky as it
allows you to adjust the configuration of the embedded Tomcat server. See
here ->
https://docs.spring.io/spring-boot/docs/current/reference/html/howto-embedded-servlet-containers.html#howto-configure-ssl

If you're deploying a stock WAR file it will be a little trickier as you're
going to need to tell the build pack to configure Tomcat in the way that
you want, which probably means using external config ->
https://github.com/cloudfoundry/java-buildpack/blob/master/docs/container-tomcat.md#external-tomcat-configuration

For either case, you'll need Tomcat 8.5+ so you can get HTTP2 support in
Tomcat. I don't think this should be an issue if you're using a recent
Java build pack or Spring Boot version.

Hope that helps!

Dan

Just to make sure we are on the same page, my goal is to use HTTP2, so I
can go beyond the HTTP/1.1 limit (beyond 6 TCP connections between source
and target endpoint).
With that I can have more open connections to the endpoint and have more
data retrieved to the front end.

Thanks again for your inputs on this.

-Lucas





On Fri, Aug 11, 2017 at 5:53 PM, Daniel Mikusa <dmikusa(a)pivotal.io> wrote:

You're correct. You cannot use HTTP routes with HTTP/2. At the moment,
if you want to use HTTP/2 you could do so by using a TCP route. Apps that
have TCP routes bound to them receive the TCP traffic directly and so you
can do things like HTTP/2.

https://docs.cloudfoundry.org/devguide/deploy-apps/routes-do
mains.html#http-vs-tcp-routes

Dan


On Fri, Aug 11, 2017 at 5:40 AM, Lucas Reginato <lucas.reginato(a)gmail.com

wrote:

Hi,

I was reading some blogs and email threads about pivotal cloud foundry
and http2.

And my understanding is that currently pcf does not support http2.
Also the Gorouter, used as the router layer in pcf does not support
http2.

If possible, can you share the current status of this work in pcf or
anything aobut this with the community?

Thanks a lot.

-Lucas Reginato

--
Lucas Reginato

Hi Dan,

Thanks for the prompt reply.

And a few question to you again.
In this case, the front end will do HTTP2 requests, and this user request
will reach the PCF Load Balancer.
*I did not look into this yet, but does PCF Load Balancer supports HTTP2
requests?*
If the PCF Load Balancer does not support HTTP2 requests, than, this will
not work.

Then, the PCF Load Balancer will send the HTTP2 request to CF router.
And the CF router will route this HTTP2 request to a TCP route, to reach an
application.
*I don't know if the TCP request will be handled as a "normal" request by a
java Rest API. *
By normal I mean HTTP/HTTPS requests.

Just to make sure we are on the same page, my goal is to use HTTP2, so I
can go beyond the HTTP/1.1 limit (beyond 6 TCP connections between source
and target endpoint).
With that I can have more open connections to the endpoint and have more
data retrieved to the front end.

Thanks again for your inputs on this.

-Lucas

--
Lucas Reginato

Shannon,

Sorry for my late response.
I haven't been noticed your reponse until a person let me know.

Thank you for telling me about the proposal document
Now I have a question about it.

What is the status of this document?

The last update of the document was 2016-09-24.
However, at 2017-03-22, I was told that multiple app ports feature will be
abondoned.
Now (exactly at 2017-06-22), you've let me know about the document.

So, whether the proposal (and the plan to implement multiple app ports) is
still alive, or not?

I've skim-read the document, and it seems that the current CF already
supports the basic functionality and APIs of the proposed workflow except
for CLI feature.

So there seems some options such as:

1) the current implementation will:
1a) be abondoned
1b) be kept as the current status
1c) be developed to be fulfill the proposal

2) the new implementation (maybe combined with container-networking feature)
to fulfill the proposal will:
2a) not be planned
2b) be planned

Totally there might be 6 (= combination of (3, 2)) options.

Would you let me know what is planned about the multiple app ports feature,
Shannon?

Thanks,


Shannon Coen wrote

Hi there,

Here's our proposal for completing support for multiple app ports:
https://docs.google.com/document/d/174Pv_P6YA6di1y_tbuuxyRHgyb6w4wMFJX874ZZxOXY/edit

We welcome your comments.
Best,
Shannon

-----
I'm not a ...
Noburou TANIGUCHI
--
View this message in context: http://cf-dev.70369.x6.nabble.com/Documents-about-multiple-app-ports-tp6610p7752.html
Sent from the CF Dev mailing list archive at Nabble.com.

http://obataborsiwanita.com/obat-aborsi-di-kediri/



--
View this message in context: http://cf-dev.70369.x6.nabble.com/cf-dev-Proposal-for-split-deployments-in-cf-deployment-tp7524p7750.html
Sent from the CF Dev mailing list archive at Nabble.com.

http://obataborsiwanita.com/obat-aborsi-di-kediri/



--
View this message in context: http://cf-dev.70369.x6.nabble.com/cf-dev-CF-deployment-on-BOSH-lite-tp7503p7749.html
Sent from the CF Dev mailing list archive at Nabble.com.

http://obataborsiwanita.com/obat-aborsi-di-madiun/



--
View this message in context: http://cf-dev.70369.x6.nabble.com/cf-dev-CF-deployment-on-BOSH-lite-tp7503p7748.html
Sent from the CF Dev mailing list archive at Nabble.com.