Date   

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


Re: CF deployment on BOSH-lite

James Leavers
 

An issue was opened recently as the bosh-lite consul certs had expired:
https://github.com/cloudfoundry/cf-release/issues/1230

On 10 August 2017 at 15:53:52, 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


Re: CF deployment on BOSH-lite

Natalie Bennett
 

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


CF deployment on BOSH-lite

Subhankar Chattopadhyay <subho.atg@...>
 

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


Re: Gorouter now supports SNI and multiple certs

Dieu Cao <dcao@...>
 

Woohoo!

On Aug 9, 2017 6:47 PM, "Shannon Coen" <scoen(a)pivotal.io> wrote:

On behalf of the CF Routing team, I'm pleased to announce routing-release
0.160.0:
https://github.com/cloudfoundry-incubator/routing-release/
releases/tag/0.160.0

This release includes a bunch of exciting features, including our most
requested one:
- SNI / Multiple Certificates

...as well as:
- Mutual TLS / Validation of Client Certificates
- Forwarding of Client Certificates to backends via the
X-Forwarded-Client-Cert HTTP header, enabling mutual TLS between client and
apps without forfeiting HTTP load balancing. The Java buildpack was
recently updated to support this header, transparently exposing certificate
metadata to apps.
- Max concurrent connections per backend, preventing slow apps from
impacting the availability of the rest of the platform
- 5 second frontend timeout on idle client connections, forcing load
balancers that time out silently to send their clients a TCP Reset.

These features will be included in an upcoming version of cf-release.

Note: this release removes support for properties router.ssl_cert and
router.ssl_key in favor of router.tls_pem, which is required if router.enable_ssl:
true.

Best,

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.


Gorouter now supports SNI and multiple certs

Shannon Coen
 

On behalf of the CF Routing team, I'm pleased to announce routing-release
0.160.0:
https://github.com/cloudfoundry-incubator/routing-release/releases/tag/
0.160.0

This release includes a bunch of exciting features, including our most
requested one:
- SNI / Multiple Certificates

...as well as:
- Mutual TLS / Validation of Client Certificates
- Forwarding of Client Certificates to backends via the
X-Forwarded-Client-Cert HTTP header, enabling mutual TLS between client and
apps without forfeiting HTTP load balancing. The Java buildpack was
recently updated to support this header, transparently exposing certificate
metadata to apps.
- Max concurrent connections per backend, preventing slow apps from
impacting the availability of the rest of the platform
- 5 second frontend timeout on idle client connections, forcing load
balancers that time out silently to send their clients a TCP Reset.

These features will be included in an upcoming version of cf-release.

Note: this release removes support for properties router.ssl_cert and
router.ssl_key in favor of router.tls_pem, which is required if
router.enable_ssl:
true.

Best,

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.


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

Michael Maximilien
 

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: Service broker authors: have you ever changed your service or plan names?

Sascha Matzke
 

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: Service broker authors: have you ever changed your service or plan names?

Subhankar Chattopadhyay <subho.atg@...>
 

It would be good to have plan renaming feature, also would be good to
have it only as display name so that it can be changed without much of
dependency. We have also faced similar situations previously.

On Wed, Aug 9, 2017 at 3:40 AM, Mike Youngstrom <youngm(a)gmail.com> wrote:
We have renamed plans and services in the past. I would like to be able to
continue to update them in the future. But I wouldn't consider it a must
have feature but it does has come in handy in the past.

Mike

On Tue, Aug 8, 2017 at 3: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.
--




Subhankar Chattopadhyay
Bangalore, India


Re: Cloud foundry buildpack to support openJFX

Peter Dotchev <dotchev@...>
 

Hi,

Try the binary buildpack or a Docker image.
There you have most flexibility.

Best regards,
Petar


On Wed, Jul 26, 2017 at 5:48 PM, Raghuvamsi Uthpala <
Raghuvamsi.Uthpala(a)indegene.com> wrote:

Hi Team,



I’m new to cloud foundry and we are setting up CF for our organization.



We have a requirement for one of our apps that it needs openJFX with java
8 . I’ve tried creating some custom build packs but not successful.

Can some one help me out if there are some build packs which I can use
that support openJFX or some steps to add this to default java-buildpack.



Appreciate your help.



*Raghuvamsi Uthpala*

Office: +91-80-39204567 <+91%2080%203920%204567>

DevOps – Lead.

Software Engineering Services

Mobile: +91- 9492901250 <+91%2094929%2001250>

Email: raghuvamsi.uthpala(a)indegene.com

Web: www.indegene.com

[image: cid:image001.png(a)01D1006F.0E0455B0] <http://www.indegene.com/>

Follow us:

*[image: cid:image002.png(a)01D1006F.0E0455B0]*
<https://www.linkedin.com/company/68889?trk=tyah&trkInfo=clickedVertical:company,clickedEntityId:68889,idx:2-1-2,tarId:1438602556067,tas:indege>

*[image: cid:image003.png(a)01D1006F.0E0455B0]*
<https://www.facebook.com/Indegene>



[image: cid:image004.png(a)01D1006F.0E0455B0] <http://www.indegene.com/atom>



Disclaimer: This email (including any attachments) contains information,
which is confidential and may be subject to legal privilege. If you are not
the intended recipient, you must not use, distribute, or copy this email.
If you have received this email in error, please notify the sender
immediately and delete this. Any views expressed in this mail are not
necessarily the views of INDEGENE. Thank you.






Disclaimer : This message and any attachments are solely for the intended
recipient and may contain confidential or privileged information. If you
are not the intended recipient, any disclosure, copying, use, or
distribution of the information included in this message and any
attachments is prohibited. If you have received this communication in
error, please notify us by reply e-mail to IT(a)Indegene.com and
immediately and permanently delete this message and any attachments. Any
views expressed in this mail are not necessarily the views of INDEGENE.
Thank you.


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

Mike Youngstrom
 

We have renamed plans and services in the past. I would like to be able to
continue to update them in the future. But I wouldn't consider it a must
have feature but it does has come in handy in the past.

Mike

On Tue, Aug 8, 2017 at 3: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.


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

Shannon Coen
 

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.


Re: Cloud foundry buildpack to support openJFX

Stephen Levine
 

Hi Raghuvamsi,

It may be worth opening an issue about this on the Java buildpack Github
issue tracker[1].

[1] https://github.com/cloudfoundry/java-buildpack/issues

Thanks,
Stephen

On Wed, Jul 26, 2017 at 10:48 AM, Raghuvamsi Uthpala <
Raghuvamsi.Uthpala(a)indegene.com> wrote:

Hi Team,



I’m new to cloud foundry and we are setting up CF for our organization.



We have a requirement for one of our apps that it needs openJFX with java
8 . I’ve tried creating some custom build packs but not successful.

Can some one help me out if there are some build packs which I can use
that support openJFX or some steps to add this to default java-buildpack.



Appreciate your help.



*Raghuvamsi Uthpala*

Office: +91-80-39204567 <+91%2080%203920%204567>

DevOps – Lead.

Software Engineering Services

Mobile: +91- 9492901250 <+91%2094929%2001250>

Email: raghuvamsi.uthpala(a)indegene.com

Web: www.indegene.com

[image: cid:image001.png(a)01D1006F.0E0455B0] <http://www.indegene.com/>

Follow us:

*[image: cid:image002.png(a)01D1006F.0E0455B0]*
<https://www.linkedin.com/company/68889?trk=tyah&trkInfo=clickedVertical:company,clickedEntityId:68889,idx:2-1-2,tarId:1438602556067,tas:indege>

*[image: cid:image003.png(a)01D1006F.0E0455B0]*
<https://www.facebook.com/Indegene>



[image: cid:image004.png(a)01D1006F.0E0455B0] <http://www.indegene.com/atom>



Disclaimer: This email (including any attachments) contains information,
which is confidential and may be subject to legal privilege. If you are not
the intended recipient, you must not use, distribute, or copy this email.
If you have received this email in error, please notify the sender
immediately and delete this. Any views expressed in this mail are not
necessarily the views of INDEGENE. Thank you.






Disclaimer : This message and any attachments are solely for the intended
recipient and may contain confidential or privileged information. If you
are not the intended recipient, any disclosure, copying, use, or
distribution of the information included in this message and any
attachments is prohibited. If you have received this communication in
error, please notify us by reply e-mail to IT(a)Indegene.com and
immediately and permanently delete this message and any attachments. Any
views expressed in this mail are not necessarily the views of INDEGENE.
Thank you.

2261 - 2280 of 9389