Date   

Sample .NET hello_world app

Chris Clark
 

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


Re: Service broker authors: have you ever changed your service or plan names?

Guillaume Berche
 

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*.


Re: Support for HTTP/2

Daniel Mikusa
 

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


Re: Support for HTTP/2

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

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


Re: CF CAB call for August 2017 is next Wednesday, August 16th @ 8a PDT [15:00 UTC]

Michael Maximilien
 

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

On Aug 15, 2017, at 8:14 AM, Michael Maximilien <maxim(a)us.ibm.com> wrote:

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 Aug 9, 2017, at 2:07 PM, Michael Maximilien <maxim(a)us.ibm.com> wrote:

Hi, all,

Quick reminder that the CAB call for August is next Wednesday, August 16th @ 8a PDT. All zoom info and agenda in link [1].

Remember, no more status update but rather discussions, so come ready with your questions. We will also have:

1. yours truly presenting about CF-Extensions PMC: projects, process, and tooling.

2. Open slot for anyone to present something OSS related to CF. Reply directly to me with proposals or suggestions or start discussion on the slack.cloudfoundry.org #CAB channel.

Zoom you all next week. I'll send one more reminder on this list next week.

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


Re: CF CAB call for August 2017 is next Wednesday, August 16th @ 8a PDT [15:00 UTC]

Michael Maximilien
 

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 Aug 9, 2017, at 2:07 PM, Michael Maximilien <maxim(a)us.ibm.com> wrote:

Hi, all,

Quick reminder that the CAB call for August is next Wednesday, August 16th @ 8a PDT. All zoom info and agenda in link [1].

Remember, no more status update but rather discussions, so come ready with your questions. We will also have:

1. yours truly presenting about CF-Extensions PMC: projects, process, and tooling.

2. Open slot for anyone to present something OSS related to CF. Reply directly to me with proposals or suggestions or start discussion on the slack.cloudfoundry.org #CAB channel.

Zoom you all next week. I'll send one more reminder on this list next week.

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


Re: Support for HTTP/2

Daniel Mikusa
 

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


Re: Support for HTTP/2

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

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-
domains.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


Re: Documents about multiple app ports

Noburou TANIGUCHI
 

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.


Re: Proposal for split deployments in cf-deployment

dzatus2 <dzatusputri2@...>
 


Re: CF deployment on BOSH-lite

dzatus2 <dzatusputri2@...>
 


Re: CF deployment on BOSH-lite

dzatus2 <dzatusputri2@...>
 


2017 CF Summit Europe Contributor Code

Chip Childers <cchilders@...>
 

We are offering free passes for contributors to the project again for the
CF Summit Europe coming up on October 11 and 12 in Basel Switzerland
<https://www.cloudfoundry.org/event/europe-2017/>. This code can be used by
anyone that is a contributor to a Cloud Foundry or BOSH project. We
consider contributions to be project leads, dedicated committers or even if
you have sent in a pull request to one of the projects. Use of the code is
on the honor system... ;-)
Register here:
https://www.regonline.com/registration/Checkin.aspx?EventID=1980409 Code:
CFEU17CONT Feel free to reach out to me or to events(a)cloudfoundry.org if
you have any questions. See you there!

-chip
--
Chip Childers
CTO, Cloud Foundry Foundation
1.267.250.0815


Re: Support for HTTP/2

Daniel Mikusa
 

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-domains.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


Re: Support for HTTP/2

Lucas Reginato
 

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


Re: CF deployment on BOSH-lite

Subhankar Chattopadhyay <subho.atg@...>
 

Hi David,

Sure, will do that. So far it works well for me on boshlite.

Regards,
Subhankar.

On Thu, 10 Aug 2017 at 11:24 PM, David Sabeti <dsabeti(a)pivotal.io> wrote:

Subhankar,

If you have any questions about cf-deployment, feel free to jump in the
#cf-deployment channel on the Cloud Foundry slack, or open a Github issue
on the repo. The RelInt team (which maintains cf-deployment) can help you
out there.

David

On Thu, Aug 10, 2017 at 10:40 AM Subhankar Chattopadhyay <
subho.atg(a)gmail.com> wrote:

Hi,

Thanks to all for your prompt reply. Surely, cf-deployment eases lot of
deployment complexity!

Regards,
Subhankar

On Thu, 10 Aug 2017 at 9:39 PM, Eric Malm <emalm(a)pivotal.io> wrote:

Hi, Subhankar,

That's likely the result of the consul certificates in the canned
BOSH-Lite CF manifest expiring after 2 years.
https://github.com/cloudfoundry/cf-release/pull/1229 fixes that, has
been merged, and should be in a new cf-release release-candidate and then
final CF release soon. In the meantime, you can also use
./scripts/generate-consul-certs in the cf-release to generate a new set of
certificates and then copy them into the appropriate BOSH properties in
templates/cf-infrastructure-bosh-lite.yml.

I second Natalie's advice to try using cf-deployment (
https://github.com/cloudfoundry/cf-deployment) to deploy CF to
BOSH-Lite instead of the older manifest-generation systems in cf-release
and diego-release.

Best,
Eric, CF Diego PM

On Thu, Aug 10, 2017 at 9:01 AM, Natalie Bennett <nbennett(a)pivotal.io>
wrote:

You should 100% be using cf-deployment for local development at this
point. Release Integration is now working with Pivotal CloudOps to
transition Pivotal's production CF instance to cf-deployment.

Once there's a running production instance of cf-deployment, RelInt
will begin the process of deprecating cf-release. If you can avoid
transitioning yourself, or learning cf-r's manifest generation, you should.

Exactly what's going on with consul depends on why Bosh lite crashed. I
personally wouldn't spend much time debugging it since consul is also in
the process of being removed.

A couple of possible steps for the consul problem:

1. That error output looks like a problem with certs, so those certs
might just be wrong. You won't have that problem with cf-d since it
generates its own certs.

2. When in doubt and not in production, scale consul down to 1, delete
its data directory (I think /var/vcap/store but I'd expect the consul
release repo to have instructions) and scale back up

3. Though what I'd do is tear the whole thing down and start over.

- Natalie

On Thu, Aug 10, 2017 at 7:53 AM Subhankar Chattopadhyay <
subho.atg(a)gmail.com> wrote:

Hi,

I used to deploy CF using the
cf-release(https://github.com/cloudfoundry/cf-release) and following
the steps mentioned in
http://docs.cloudfoundry.org/deploying/boshlite/create_a_manifest.html
.
It was working fine till my bosh-lite crashed and when I tried to re
install, consul_z1 was not running and I got the following error
inside the log

error during stop: dial tcp [::1]:8400: getsockopt: connection refused
error during start: timeout exceeded: "rpc error: failed to get conn:
x509: certificate has expired or is not yet valid"
2017/08/09 04:23:24 [ERR] agent.client: Failed to decode response
header: EOF
2017/08/09 04:23:24 [ERR] agent.client: Failed to decode response
header: EOF
error during start: timeout exceeded: "rpc error: failed to get conn:
x509: certificate has expired or is not yet valid"
2017/08/09 04:24:26 [ERR] agent.client: Failed to decode response
header: EOF
2017/08/09 04:24:26 [ERR] agent.client: Failed to decode response
header: EOF
error during start: timeout exceeded: "rpc error: failed to get conn:
x509: certificate has expired or is not yet valid"


Am I missing some steps here? Should I deploy with new certificates ?

I then deployed bosh and cf using
bosh-deployment(https://github.com/cloudfoundry/bosh-deployment) and
cf-deployment(https://github.com/cloudfoundry/cf-deployment). It
worked perfectly.

I am wondering if cf-deployment is the way to go for local bosh-lite
development or I should try with cf-release? Can someone help me with
this?



Regards,
Subhankar Chattopadhyay
Bangalore, India
--



Subhankar Chattopadhyay
Bangalore, India
--



Subhankar Chattopadhyay
Bangalore, India


Proposal for split deployments in cf-deployment

David Sabeti
 

Hi cf-dev,

One thing we're considering in the future for cf-deployment is providing a
way to break down the unified deployment manifest into smaller deployments.
Particularly, we want to split up deployments in a way that helps operators
manage the way updates are rolled out.

Take a look here for the proposal:
https://docs.google.com/document/d/1l4v7ocYph_Al20j6TVF6ylRrUKyFH9hSwxxSbIcZ0wM/edit?usp=sharing

Please comment on the document with any feedback you have. We'd love to
hear from you.

Thanks!
David Sabeti
CF Release Integration Project Lead


Re: CF deployment on BOSH-lite

David Sabeti
 

Subhankar,

If you have any questions about cf-deployment, feel free to jump in the
#cf-deployment channel on the Cloud Foundry slack, or open a Github issue
on the repo. The RelInt team (which maintains cf-deployment) can help you
out there.

David

On Thu, Aug 10, 2017 at 10:40 AM Subhankar Chattopadhyay <
subho.atg(a)gmail.com> wrote:

Hi,

Thanks to all for your prompt reply. Surely, cf-deployment eases lot of
deployment complexity!

Regards,
Subhankar

On Thu, 10 Aug 2017 at 9:39 PM, Eric Malm <emalm(a)pivotal.io> wrote:

Hi, Subhankar,

That's likely the result of the consul certificates in the canned
BOSH-Lite CF manifest expiring after 2 years.
https://github.com/cloudfoundry/cf-release/pull/1229 fixes that, has
been merged, and should be in a new cf-release release-candidate and then
final CF release soon. In the meantime, you can also use
./scripts/generate-consul-certs in the cf-release to generate a new set of
certificates and then copy them into the appropriate BOSH properties in
templates/cf-infrastructure-bosh-lite.yml.

I second Natalie's advice to try using cf-deployment (
https://github.com/cloudfoundry/cf-deployment) to deploy CF to BOSH-Lite
instead of the older manifest-generation systems in cf-release and
diego-release.

Best,
Eric, CF Diego PM

On Thu, Aug 10, 2017 at 9:01 AM, Natalie Bennett <nbennett(a)pivotal.io>
wrote:

You should 100% be using cf-deployment for local development at this
point. Release Integration is now working with Pivotal CloudOps to
transition Pivotal's production CF instance to cf-deployment.

Once there's a running production instance of cf-deployment, RelInt will
begin the process of deprecating cf-release. If you can avoid transitioning
yourself, or learning cf-r's manifest generation, you should.

Exactly what's going on with consul depends on why Bosh lite crashed. I
personally wouldn't spend much time debugging it since consul is also in
the process of being removed.

A couple of possible steps for the consul problem:

1. That error output looks like a problem with certs, so those certs
might just be wrong. You won't have that problem with cf-d since it
generates its own certs.

2. When in doubt and not in production, scale consul down to 1, delete
its data directory (I think /var/vcap/store but I'd expect the consul
release repo to have instructions) and scale back up

3. Though what I'd do is tear the whole thing down and start over.

- Natalie

On Thu, Aug 10, 2017 at 7:53 AM Subhankar Chattopadhyay <
subho.atg(a)gmail.com> wrote:

Hi,

I used to deploy CF using the
cf-release(https://github.com/cloudfoundry/cf-release) and following
the steps mentioned in
http://docs.cloudfoundry.org/deploying/boshlite/create_a_manifest.html.
It was working fine till my bosh-lite crashed and when I tried to re
install, consul_z1 was not running and I got the following error
inside the log

error during stop: dial tcp [::1]:8400: getsockopt: connection refused
error during start: timeout exceeded: "rpc error: failed to get conn:
x509: certificate has expired or is not yet valid"
2017/08/09 04:23:24 [ERR] agent.client: Failed to decode response
header: EOF
2017/08/09 04:23:24 [ERR] agent.client: Failed to decode response
header: EOF
error during start: timeout exceeded: "rpc error: failed to get conn:
x509: certificate has expired or is not yet valid"
2017/08/09 04:24:26 [ERR] agent.client: Failed to decode response
header: EOF
2017/08/09 04:24:26 [ERR] agent.client: Failed to decode response
header: EOF
error during start: timeout exceeded: "rpc error: failed to get conn:
x509: certificate has expired or is not yet valid"


Am I missing some steps here? Should I deploy with new certificates ?

I then deployed bosh and cf using
bosh-deployment(https://github.com/cloudfoundry/bosh-deployment) and
cf-deployment(https://github.com/cloudfoundry/cf-deployment). It
worked perfectly.

I am wondering if cf-deployment is the way to go for local bosh-lite
development or I should try with cf-release? Can someone help me with
this?



Regards,
Subhankar Chattopadhyay
Bangalore, India
--



Subhankar Chattopadhyay
Bangalore, India


Re: CF deployment on BOSH-lite

Subhankar Chattopadhyay <subho.atg@...>
 

Hi,

Thanks to all for your prompt reply. Surely, cf-deployment eases lot of
deployment complexity!

Regards,
Subhankar

On Thu, 10 Aug 2017 at 9:39 PM, Eric Malm <emalm(a)pivotal.io> wrote:

Hi, Subhankar,

That's likely the result of the consul certificates in the canned
BOSH-Lite CF manifest expiring after 2 years.
https://github.com/cloudfoundry/cf-release/pull/1229 fixes that, has been
merged, and should be in a new cf-release release-candidate and then final
CF release soon. In the meantime, you can also use
./scripts/generate-consul-certs in the cf-release to generate a new set of
certificates and then copy them into the appropriate BOSH properties in
templates/cf-infrastructure-bosh-lite.yml.

I second Natalie's advice to try using cf-deployment (
https://github.com/cloudfoundry/cf-deployment) to deploy CF to BOSH-Lite
instead of the older manifest-generation systems in cf-release and
diego-release.

Best,
Eric, CF Diego PM

On Thu, Aug 10, 2017 at 9:01 AM, Natalie Bennett <nbennett(a)pivotal.io>
wrote:

You should 100% be using cf-deployment for local development at this
point. Release Integration is now working with Pivotal CloudOps to
transition Pivotal's production CF instance to cf-deployment.

Once there's a running production instance of cf-deployment, RelInt will
begin the process of deprecating cf-release. If you can avoid transitioning
yourself, or learning cf-r's manifest generation, you should.

Exactly what's going on with consul depends on why Bosh lite crashed. I
personally wouldn't spend much time debugging it since consul is also in
the process of being removed.

A couple of possible steps for the consul problem:

1. That error output looks like a problem with certs, so those certs
might just be wrong. You won't have that problem with cf-d since it
generates its own certs.

2. When in doubt and not in production, scale consul down to 1, delete
its data directory (I think /var/vcap/store but I'd expect the consul
release repo to have instructions) and scale back up

3. Though what I'd do is tear the whole thing down and start over.

- Natalie

On Thu, Aug 10, 2017 at 7:53 AM Subhankar Chattopadhyay <
subho.atg(a)gmail.com> wrote:

Hi,

I used to deploy CF using the
cf-release(https://github.com/cloudfoundry/cf-release) and following
the steps mentioned in
http://docs.cloudfoundry.org/deploying/boshlite/create_a_manifest.html.
It was working fine till my bosh-lite crashed and when I tried to re
install, consul_z1 was not running and I got the following error
inside the log

error during stop: dial tcp [::1]:8400: getsockopt: connection refused
error during start: timeout exceeded: "rpc error: failed to get conn:
x509: certificate has expired or is not yet valid"
2017/08/09 04:23:24 [ERR] agent.client: Failed to decode response
header: EOF
2017/08/09 04:23:24 [ERR] agent.client: Failed to decode response
header: EOF
error during start: timeout exceeded: "rpc error: failed to get conn:
x509: certificate has expired or is not yet valid"
2017/08/09 04:24:26 [ERR] agent.client: Failed to decode response
header: EOF
2017/08/09 04:24:26 [ERR] agent.client: Failed to decode response
header: EOF
error during start: timeout exceeded: "rpc error: failed to get conn:
x509: certificate has expired or is not yet valid"


Am I missing some steps here? Should I deploy with new certificates ?

I then deployed bosh and cf using
bosh-deployment(https://github.com/cloudfoundry/bosh-deployment) and
cf-deployment(https://github.com/cloudfoundry/cf-deployment). It
worked perfectly.

I am wondering if cf-deployment is the way to go for local bosh-lite
development or I should try with cf-release? Can someone help me with
this?



Regards,
Subhankar Chattopadhyay
Bangalore, India
--



Subhankar Chattopadhyay
Bangalore, India


Re: CF deployment on BOSH-lite

Eric Malm <emalm@...>
 

Hi, Subhankar,

That's likely the result of the consul certificates in the canned BOSH-Lite
CF manifest expiring after 2 years. https://github.com/
cloudfoundry/cf-release/pull/1229 fixes that, has been merged, and should
be in a new cf-release release-candidate and then final CF release soon. In
the meantime, you can also use ./scripts/generate-consul-certs in the
cf-release to generate a new set of certificates and then copy them into
the appropriate BOSH properties in templates/cf-infrastructure-
bosh-lite.yml.

I second Natalie's advice to try using cf-deployment (https://github.com/
cloudfoundry/cf-deployment) to deploy CF to BOSH-Lite instead of the older
manifest-generation systems in cf-release and diego-release.

Best,
Eric, CF Diego PM

On Thu, Aug 10, 2017 at 9:01 AM, Natalie Bennett <nbennett(a)pivotal.io>
wrote:

You should 100% be using cf-deployment for local development at this
point. Release Integration is now working with Pivotal CloudOps to
transition Pivotal's production CF instance to cf-deployment.

Once there's a running production instance of cf-deployment, RelInt will
begin the process of deprecating cf-release. If you can avoid transitioning
yourself, or learning cf-r's manifest generation, you should.

Exactly what's going on with consul depends on why Bosh lite crashed. I
personally wouldn't spend much time debugging it since consul is also in
the process of being removed.

A couple of possible steps for the consul problem:

1. That error output looks like a problem with certs, so those certs might
just be wrong. You won't have that problem with cf-d since it generates its
own certs.

2. When in doubt and not in production, scale consul down to 1, delete its
data directory (I think /var/vcap/store but I'd expect the consul release
repo to have instructions) and scale back up

3. Though what I'd do is tear the whole thing down and start over.

- Natalie

On Thu, Aug 10, 2017 at 7:53 AM Subhankar Chattopadhyay <
subho.atg(a)gmail.com> wrote:

Hi,

I used to deploy CF using the
cf-release(https://github.com/cloudfoundry/cf-release) and following
the steps mentioned in
http://docs.cloudfoundry.org/deploying/boshlite/create_a_manifest.html.
It was working fine till my bosh-lite crashed and when I tried to re
install, consul_z1 was not running and I got the following error
inside the log

error during stop: dial tcp [::1]:8400: getsockopt: connection refused
error during start: timeout exceeded: "rpc error: failed to get conn:
x509: certificate has expired or is not yet valid"
2017/08/09 04:23:24 [ERR] agent.client: Failed to decode response header:
EOF
2017/08/09 04:23:24 [ERR] agent.client: Failed to decode response header:
EOF
error during start: timeout exceeded: "rpc error: failed to get conn:
x509: certificate has expired or is not yet valid"
2017/08/09 04:24:26 [ERR] agent.client: Failed to decode response header:
EOF
2017/08/09 04:24:26 [ERR] agent.client: Failed to decode response header:
EOF
error during start: timeout exceeded: "rpc error: failed to get conn:
x509: certificate has expired or is not yet valid"


Am I missing some steps here? Should I deploy with new certificates ?

I then deployed bosh and cf using
bosh-deployment(https://github.com/cloudfoundry/bosh-deployment) and
cf-deployment(https://github.com/cloudfoundry/cf-deployment). It
worked perfectly.

I am wondering if cf-deployment is the way to go for local bosh-lite
development or I should try with cf-release? Can someone help me with
this?



Regards,
Subhankar Chattopadhyay
Bangalore, India

2281 - 2300 of 9421