Date   

Re: Pending Proposals for CF-Extensions for 2017

Michael Maximilien
 

Thanks. Updated. Best,

max

On Mon, Jan 23, 2017 at 8:28 PM, Takahito SEYAMA <t.seyama20(a)gmail.com>
wrote:

Hi Michael,

Thank you for adding "Private Stacks" to the list.

I'm sorry I haven't told you about my affiliation.
Please fix it to "owner company: NTT Communications" .

Regards,

NTT Communications
t.seyama


2017-01-21 7:54 GMT+09:00 Michael Maximilien <maxim(a)us.ibm.com>:

Hi, all,

I am trying to get a handle on all pending proposals to CF-Extensions as
well as anything proposed to CF that is now orphaned or would like to be
considered in the CF-Extensions PMC. I have a list [1], however, I am sure
it is not complete.

Please, if you have a proposal pending fitting above and it's not listed
please add it or respond here or to me directly so I add and start tracking.

Thanks,

[1] https://docs.google.com/document/d/1aKmxFdGC4GnXBIZMx0qd
IawHrEIRSjBOzB-spoPlbM8/edit?usp=sharing

------
dr.max
ibm cloud labs
silicon valley, ca
maximilien.org


--
max
http://maximilien.org
http://blog.maximilien.com


Re: Routing for Isolation Segments

Mike Youngstrom
 

Question, Just want to make sure I'm following you. In your Access Control
example you mention that without access control a developer would be able
to create a route to foo.example.com in a space associated with IS-2, but,
that "route will fail". Is this example assuming that the "Partitioning
the Routing Table" feature was implemented, a properly configured
firewalls, or would the route fail for some other reason?

I think for our use cases we only require Access Control. We are capable
of configuring our firewalls and such correctly. :) Partitioned routing
tables would be nice too but I think a lower priority.

Mike

On Mon, Jan 23, 2017 at 6:24 PM, Shannon Coen <scoen(a)pivotal.io> wrote:

Last week the CF Routing team incepted on enhancements for dedicated
deployments of the CF routers for isolation segments.

- Original proposal
<https://docs.google.com/document/d/1FFW8YwKeBK1DuSXFHH_wxGpSZpOpkPN5yOUB-03whsI/edit?usp=sharing>
- Summary
<https://docs.google.com/presentation/d/1D4aguVXHtTGdhFPAqAC1exZd0Nrh2o4VO3PR4kmHvq4/edit?usp=sharing>


For those of you who are looking forward to leveraging isolation segments
for your use cases, we'd like to know whether you would be inclined to use
dedicated routing tiers for isolation groups in production without the
proposed enhancements below, or whether you would require either/both of
the enhancements we have in mind.

*Current Support*

With compute-only isolation, an application can be deployed to an isolated
pool of Diego Cells. On its own, this design will rely on a shared routing
tier with access to all isolation segments. This requires an operator to
carefully configure their load balancer and firewall rules to prevent an
attacker using a spoofed Host header to reach an application that shouldn't
be publicly routable.

An operator can currently deploy dedicated deployments of routers for an
isolation segment but the routing table will be shared among them. Should a
misconfigured load balancer forward a request to routers for an app on
another isolation segment, the routers will attempt to route the request.
If the firewall is correctly configured, the router will return a 502. If
the firewall is misconfigured, a private app may be publicly accessible.

*Proposed Enhancement: Partitioning the Routing Table*

By partitioning the routing table, routers dedicated to a isolation
segment will only route requests for apps in an associated isolation
segment; if a load balancer were misconfigured, and a request for an app in
another isolation segment were forwarded to the routers, a 404 would be
returned.

*Proposed Enhancement: **Access Control*

An org may have multiple domains and multiple isolation segments. A space
is associated with only one isolation segment.

Example: if the operator has configured their LB to point *.
foo.example.com at routers for isolation segment IS-1 and *.
bar.example.com at routers for isolation segment IS-2, there's nothing
preventing an app developer from creating a route from domain
foo.example.com in a space associated with IS-2. Requests to the route
will fail and the developer would not know why. To prevent this, we'll
enable API clients to filter domains by targeted space, so that a developer
only sees domains from which they can create working routes.

*Your Feedback*

Please let us know if you would require either of these enhancements for
routing to isolation segments in your production environments.

Thank you,

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.




Re: Pending Proposals for CF-Extensions for 2017

Takahito SEYAMA
 

Hi Michael,

Thank you for adding "Private Stacks" to the list.

I'm sorry I haven't told you about my affiliation.
Please fix it to "owner company: NTT Communications" .

Regards,

NTT Communications
t.seyama


2017-01-21 7:54 GMT+09:00 Michael Maximilien <maxim(a)us.ibm.com>:

Hi, all,

I am trying to get a handle on all pending proposals to CF-Extensions as
well as anything proposed to CF that is now orphaned or would like to be
considered in the CF-Extensions PMC. I have a list [1], however, I am sure
it is not complete.

Please, if you have a proposal pending fitting above and it's not listed
please add it or respond here or to me directly so I add and start tracking.

Thanks,

[1] https://docs.google.com/document/d/1aKmxFdGC4GnXBIZMx0qdIawHrEIRS
jBOzB-spoPlbM8/edit?usp=sharing

------
dr.max
ibm cloud labs
silicon valley, ca
maximilien.org


Routing for Isolation Segments

Shannon Coen
 

Last week the CF Routing team incepted on enhancements for dedicated
deployments of the CF routers for isolation segments.

- Original proposal
<https://docs.google.com/document/d/1FFW8YwKeBK1DuSXFHH_wxGpSZpOpkPN5yOUB-03whsI/edit?usp=sharing>
- Summary
<https://docs.google.com/presentation/d/1D4aguVXHtTGdhFPAqAC1exZd0Nrh2o4VO3PR4kmHvq4/edit?usp=sharing>


For those of you who are looking forward to leveraging isolation segments
for your use cases, we'd like to know whether you would be inclined to use
dedicated routing tiers for isolation groups in production without the
proposed enhancements below, or whether you would require either/both of
the enhancements we have in mind.

*Current Support*

With compute-only isolation, an application can be deployed to an isolated
pool of Diego Cells. On its own, this design will rely on a shared routing
tier with access to all isolation segments. This requires an operator to
carefully configure their load balancer and firewall rules to prevent an
attacker using a spoofed Host header to reach an application that shouldn't
be publicly routable.

An operator can currently deploy dedicated deployments of routers for an
isolation segment but the routing table will be shared among them. Should a
misconfigured load balancer forward a request to routers for an app on
another isolation segment, the routers will attempt to route the request.
If the firewall is correctly configured, the router will return a 502. If
the firewall is misconfigured, a private app may be publicly accessible.

*Proposed Enhancement: Partitioning the Routing Table*

By partitioning the routing table, routers dedicated to a isolation segment
will only route requests for apps in an associated isolation segment; if a
load balancer were misconfigured, and a request for an app in another
isolation segment were forwarded to the routers, a 404 would be returned.

*Proposed Enhancement: **Access Control*

An org may have multiple domains and multiple isolation segments. A space
is associated with only one isolation segment.

Example: if the operator has configured their LB to point *.foo.example.com
at routers for isolation segment IS-1 and *.bar.example.com at routers for
isolation segment IS-2, there's nothing preventing an app developer from
creating a route from domain foo.example.com in a space associated with
IS-2. Requests to the route will fail and the developer would not know why.
To prevent this, we'll enable API clients to filter domains by targeted
space, so that a developer only sees domains from which they can create
working routes.

*Your Feedback*

Please let us know if you would require either of these enhancements for
routing to isolation segments in your production environments.

Thank you,

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.


CF-extensions monthly recurring (last Monday) meeting - next on Monday 30, January 2017

Michael Maximilien
 

fyi...
 
Join me on 30 January 2017 @ 11a PDT for our monthly recurring meeting.
 
 
Use the following link to add it to your calendar:
 
 
I plan to hold the meeting at Pivotal when I am there, so ping me on the #cf-extensions slack channel if you want to participate live. All other details are on the Google Calendar invite link. Talk soon.
 
Best,

------
dr.max
ibm cloud labs
silicon valley, ca
maximilien.org


Re: Considering deprecation of the HAProxy in cf-release

Shannon Coen
 


I understand the gorouter still only supports serving a single TLS
certificate [1], which makes it hard to support distinct api and app https
domains, which is often useful in lab environments.
HAProxy in cf-release has the same limitation, so removal of it would be no
worse.


I believe a battery-included load balancer still provides benefits to
small production environments which can't leverage out of the box load
balancer solution. Orange started contributing redundancy/HA support to the
cf-community haproxy bosh release, in the form of an active/passive fail
over leveraging keep-alived through VRRP protocol [2]. While this needs
further work to work in constrained cloud environments (without multicast
and gratuitous ARP support, such as AWS), it is likely these environments
provide out of the box their own production-grade load balancer construct,
or support for them can be added on top of keep-alived using unicast as
Iaas-specific features such as floating IPs.
Historically, we've taken the approach that BOSH releases can be deployed
to any infrastructure that BOSH supports, and that all features in a BOSH
release are infrastructure agnostic. As AWS doesn't support the feature
you've mentioned, this would be an infrastructure-specific feature.


I wonder whether it could make sense to incubate the
cloudfoundry-community/haproxy-boshrelease as to preserve such portable
battery-included load balancer and keep hard cloud prerequisites low for
newcomers/evaluations.
That sounds interesting.



Regards,

Guillaume.

[1] http://bosh.io/jobs/gorouter?source=github.com/
cloudfoundry/cf-release&version=251#p=router.ssl_cert
[2] https://github.com/cloudfoundry-community/haproxy-boshrelease/pull/39


On Fri, Jan 13, 2017 at 9:25 PM, Shannon Coen <scoen(a)pivotal.io> wrote:

Over that past year or two, CF teams have been extracting components from
cf-release into their own BOSH releases. This allows teams to innovate more
quickly. These releases are currently submoduled into cf-release, so that
cf-release can be used to deploy the full suite of core CF services. The
current plan is that cf-release will eventually be deprecated in favor of
cf-deployment <https://github.com/cloudfoundry/cf-deployment>, a
toolchain that generates a manifest for CF from these composable releases.

One of the last components in cf-release
<https://github.com/cloudfoundry/cf-release/tree/master/jobs> that has
not been extracted into its own release is HAProxy.

Historically, HAProxy has fulfilled two use cases: load balancing and TLS
termination. Since support for TLS termination was added to Gorouter, load
balancing may be the remaining use case.

In production environments, operators are expected to provide their own
redundant load balancers and configure them to forward requests to the CF
routers. HAProxy may provide a convenience where another load balancer is
not available, but as HAProxy is not inherently highly available in a
production environment it would require another load balancer in front of
it for HA, at which point HAProxy itself would be superfluous. For this
reason we have not recommended use of the HAProxy in cf-release for
production environments.

This leaves the use case of development, or lab environments. Over the
past year, we have begun thinking that the HAProxy provides no additional
value here either. Since HA is not required in these environments, we
have begun recommending
<http://docs.cloudfoundry.org/adminguide/configure-lb-healthcheck.html>
that operators point DNS directly at single instances of the CF Router and
SSH Proxy.

Therefore, we're proposing deprecation of the HAProxy in cf-release. Of
course, we want to hear your feedback. If you are currently leveraging the
HAProxy in cf-release, please share your use cases.

Thank you,

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.


Re: Proposed changes to Gorouter log message format

Shannon Coen
 

Hello Carlo,

There are no plans to use Zap in other components.

Best,

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

On Sun, Jan 22, 2017 at 5:12 PM, Carlo Alberto Ferraris <
carlo.ferraris(a)rakuten.com> wrote:

Shannon,
Are there plans to extend the use of zap to all CF components?

Thanks,
Carlo


Re: Considering deprecation of the HAProxy in cf-release

Guillaume Berche
 

Hi Shannon,

Sorry for late delay on this.

Historically, HAProxy has fulfilled two use cases: load balancing and TLS
termination. Since support for TLS termination was added to Gorouter, load
balancing may be the remaining use case.

I understand the gorouter still only supports serving a single TLS
certificate [1], which makes it hard to support distinct api and app https
domains, which is often useful in lab environments.

I believe a battery-included load balancer still provides benefits to small
production environments which can't leverage out of the box load balancer
solution. Orange started contributing redundancy/HA support to the
cf-community haproxy bosh release, in the form of an active/passive fail
over leveraging keep-alived through VRRP protocol [2]. While this needs
further work to work in constrained cloud environments (without multicast
and gratuitous ARP support, such as AWS), it is likely these environments
provide out of the box their own production-grade load balancer construct,
or support for them can be added on top of keep-alived using unicast as
Iaas-specific features such as floating IPs.

I wonder whether it could make sense to incubate the
cloudfoundry-community/haproxy-boshrelease as to preserve such portable
battery-included load balancer and keep hard cloud prerequisites low for
newcomers/evaluations.

Regards,

Guillaume.

[1]
http://bosh.io/jobs/gorouter?source=github.com/cloudfoundry/cf-release&version=251#p=router.ssl_cert
[2] https://github.com/cloudfoundry-community/haproxy-boshrelease/pull/39

On Fri, Jan 13, 2017 at 9:25 PM, Shannon Coen <scoen(a)pivotal.io> wrote:

Over that past year or two, CF teams have been extracting components from
cf-release into their own BOSH releases. This allows teams to innovate more
quickly. These releases are currently submoduled into cf-release, so that
cf-release can be used to deploy the full suite of core CF services. The
current plan is that cf-release will eventually be deprecated in favor of
cf-deployment <https://github.com/cloudfoundry/cf-deployment>, a
toolchain that generates a manifest for CF from these composable releases.

One of the last components in cf-release
<https://github.com/cloudfoundry/cf-release/tree/master/jobs> that has
not been extracted into its own release is HAProxy.

Historically, HAProxy has fulfilled two use cases: load balancing and TLS
termination. Since support for TLS termination was added to Gorouter, load
balancing may be the remaining use case.

In production environments, operators are expected to provide their own
redundant load balancers and configure them to forward requests to the CF
routers. HAProxy may provide a convenience where another load balancer is
not available, but as HAProxy is not inherently highly available in a
production environment it would require another load balancer in front of
it for HA, at which point HAProxy itself would be superfluous. For this
reason we have not recommended use of the HAProxy in cf-release for
production environments.

This leaves the use case of development, or lab environments. Over the
past year, we have begun thinking that the HAProxy provides no additional
value here either. Since HA is not required in these environments, we
have begun recommending
<http://docs.cloudfoundry.org/adminguide/configure-lb-healthcheck.html>
that operators point DNS directly at single instances of the CF Router and
SSH Proxy.

Therefore, we're proposing deprecation of the HAProxy in cf-release. Of
course, we want to hear your feedback. If you are currently leveraging the
HAProxy in cf-release, please share your use cases.

Thank you,

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.


Re: Proposed changes to Gorouter log message format

Carlo Alberto Ferraris
 

Shannon,
Are there plans to extend the use of zap to all CF components?

Thanks,
Carlo


Pending Proposals for CF-Extensions for 2017

Michael Maximilien
 

Hi, all,
 
I am trying to get a handle on all pending proposals to CF-Extensions as well as anything proposed to CF that is now orphaned or would like to be considered in the CF-Extensions PMC. I have a list [1], however, I am sure it is not complete. 
 
Please, if you have a proposal pending fitting above and it's not listed please add it or respond here or to me directly so I add and start tracking.
 
Thanks,
 

------
dr.max
ibm cloud labs
silicon valley, ca
maximilien.org


Re: Incubation proposal: Abacus Service Broker

Michael Maximilien
 

Hi,

As discussed today, I will be happy to help you run the inception.

If anyone else (with more experience) was interested in helping, please
ping me and Hristo.

See you all (virtually) online on the 31st.

Best,

Max

On Mon, Nov 28, 2016 at 1:29 PM, Michael Maximilien <mmaximilien(a)gmail.com>
wrote:

Hi, all,

Thanks to SAP and Hristo for moving this forward.

Since I don't see any questions nor comments on this proposal, other than
mine. As such, I propose to include this into the CF-Extensions PMC.

Next step is to do an inception and start the project.

Hristo, happy to help you. Please let's connect offline or during
CF-Abacus weekly meetings von Friday. You can then announce details here
afterwards.

Welcome. Best,

Max

On Wed, Nov 16, 2016 at 3:51 PM, Michael Maximilien <mmaximilien(a)gmail.com
wrote:
Thank you Hirsto and SAP for submitting this proposal. A nice extension
for CF.

Made some minor editorial changes but overall proposal looks great.
Looking forward to see feedback (if any) from community.

Best,

Max

On Tue, Nov 15, 2016 at 8:03 AM, Iliev, Hristo <hristo.iliev(a)sap.com>
wrote:

Hello,

I would like to propose to the Extensions PMC a new incubation project
around Abacus.

Project name: Abacus Service Broker
Project proposal: https://docs.google.com/docume
nt/d/1zGYi0jGRX9kodn8WR8OHn6CSjo3BTorfuza121aIeuU/edit?usp=sharing
Proposed Project Lead: Hristo Iliev (SAP)
Proposed Scope: See the "Goals" and "Non-goals" sections in the proposal
Development Operating Model: Distributed Committer Model
Technical Approach: Refer to "Programming language" and "Deliverables"
in the proposal
Initial team committed: 3 engineers from SAP

I look forward to any questions or comments.

Regards,
Hristo Iliev, SAP




--
max
http://maximilien.org
http://blog.maximilien.com


--
max
http://maximilien.org
http://blog.maximilien.com


--
max
http://maximilien.org
http://blog.maximilien.com


Re: [ PHP ] Best config practices

Nicholas Calugar
 

Dan,

I’m concerned that .user.ini and .htaccess files are processed for every
request. This is a no-no for production apps.

As for overriding the entire php.ini, I’m in favor of extensibility. This
way when a new version of PHP ships with a new default php.ini, I don’t
have to update my application. Do you have an example of how to override
PHP configuration in an extensible manner?


-Nick

--
Nicholas Calugar

On January 20, 2017 at 10:49:59 AM, Daniel Mikusa (dmikusa(a)pivotal.io)
wrote:

On Fri, Jan 20, 2017 at 1:27 PM, Nicholas Calugar <ncalugar(a)pivotal.io>
wrote:

You may also want to look into [1] .user.ini files.

+Steven

Would you consider compiling PHP with this option:

--with-config-file-scan-dir /home/vcap/app/php/etc/php.d

And then providing some mechanism for the buildpack to copy .ini files
from a known location into that directory?
This is probably not necessary as there's a bunch of ways to override PHP
config currently. You mentioned `.user.ini` files which is a great option,
you can also use `.htaccess` files assuming you're using HTTPD which is the
default web server configured by the build pack, you can override the
entire default build pack php.ini with the method mentioned here [2] and
you can do dynamic generation as I mentioned in `.profile` / `.profile.d`.

Dan

[2] -
https://docs.cloudfoundry.org/buildpacks/php/gsg-php-config.html#engine-configurations





[1] http://php.net/manual/en/configuration.file.per-user.php
--
Nicholas Calugar

On January 20, 2017 at 5:36:45 AM, Daniel Mikusa (dmikusa(a)pivotal.io)
wrote:

You can include a `.profile.d/` script or a `.profile` script. It depends
on exactly what you're trying to do as to which one would be better to use,
but I believe most of the time you'd want the `.profile` script. You can
see more about it in the docs here.

https://docs.cloudfoundry.org/devguide/deploy-apps/deploy-app.html#profile

You can essentially do whatever you want in this script. Plus you'll have
access to everything that the PHP build pack has configured for you and
you'll have access to all the environment variables. This means you can
run PHP scripts or examine VCAP_SERVICES. The only catch is that these
scripts runs prior to your application starting so they must run and your
application must start within the defined timeout (default 60s, max 180s on
most platforms).

If you want to integrate with the build pack and do something during
staging or if you need more time (cause staging typically runs for up to
900s), you can add a build pack extension. These are written in Python and
run as a part of the build pack. Instructions on doing that can be found
here.

https://github.com/cloudfoundry/php-buildpack#extensions

Hope that helps!

Dan

On Thu, Jan 19, 2017 at 4:01 PM, Leandro David Cacciagioni <
leandro.21.2008(a)gmail.com> wrote:

I have a php monolith app that requires tons of .ini files config
previous to the deployment I want to know if any of you have a "best
practice" to generate all this ini files depending from the environmental
variables.


Re: CF Java Client

Chenulu P
 

Thanks Ben. I will try with the new Java Client.


Re: [ PHP ] Best config practices

Daniel Mikusa
 

On Fri, Jan 20, 2017 at 1:27 PM, Nicholas Calugar <ncalugar(a)pivotal.io>
wrote:

You may also want to look into [1] .user.ini files.

+Steven

Would you consider compiling PHP with this option:

--with-config-file-scan-dir /home/vcap/app/php/etc/php.d

And then providing some mechanism for the buildpack to copy .ini files
from a known location into that directory?
This is probably not necessary as there's a bunch of ways to override PHP
config currently. You mentioned `.user.ini` files which is a great option,
you can also use `.htaccess` files assuming you're using HTTPD which is the
default web server configured by the build pack, you can override the
entire default build pack php.ini with the method mentioned here [2] and
you can do dynamic generation as I mentioned in `.profile` / `.profile.d`.

Dan

[2] -
https://docs.cloudfoundry.org/buildpacks/php/gsg-php-config.html#engine-configurations





[1] http://php.net/manual/en/configuration.file.per-user.php
--
Nicholas Calugar

On January 20, 2017 at 5:36:45 AM, Daniel Mikusa (dmikusa(a)pivotal.io)
wrote:

You can include a `.profile.d/` script or a `.profile` script. It depends
on exactly what you're trying to do as to which one would be better to use,
but I believe most of the time you'd want the `.profile` script. You can
see more about it in the docs here.

https://docs.cloudfoundry.org/devguide/deploy-apps/deploy-app.html#profile

You can essentially do whatever you want in this script. Plus you'll have
access to everything that the PHP build pack has configured for you and
you'll have access to all the environment variables. This means you can
run PHP scripts or examine VCAP_SERVICES. The only catch is that these
scripts runs prior to your application starting so they must run and your
application must start within the defined timeout (default 60s, max 180s on
most platforms).

If you want to integrate with the build pack and do something during
staging or if you need more time (cause staging typically runs for up to
900s), you can add a build pack extension. These are written in Python and
run as a part of the build pack. Instructions on doing that can be found
here.

https://github.com/cloudfoundry/php-buildpack#extensions

Hope that helps!

Dan

On Thu, Jan 19, 2017 at 4:01 PM, Leandro David Cacciagioni <
leandro.21.2008(a)gmail.com> wrote:

I have a php monolith app that requires tons of .ini files config
previous to the deployment I want to know if any of you have a "best
practice" to generate all this ini files depending from the environmental
variables.


Re: CF Java Client

Ben Hale <bhale@...>
 

The documentation you are referring to relates to Java Client 1.x. The `master` branch contains Java Client 2.x, and its best documentation currently exists in the README[1]. If you wish to continue using Java Client 1.x (it is currently unsupported), it is available in Maven Central[2].


-Ben Hale
Cloud Foundry Java Experience


[1]: https://github.com/cloudfoundry/cf-java-client#usage
[2]: http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.cloudfoundry%22%20AND%20a%3A%22cloudfoundry-client-lib%22

On Jan 20, 2017, at 09:41, Chenulu Peri <chenulu(a)gmail.com> wrote:

I am trying build the Java Client from https://github.com/cloudfoundry/cf-java-client.git. However none of the jar files generated contains the classes referred to in the sample code https://docs.cloudfoundry.org/buildpacks/java/java-client.html#sample-code

I would really appreciate if anyone can provide me how to build the client jar so that I can reference the client lib methods.

TIA.


Re: [ PHP ] Best config practices

Leandro David Cacciagioni
 

Thanks a lot guys it is a great help!!!!

2017-01-20 19:27 GMT+01:00 Nicholas Calugar <ncalugar(a)pivotal.io>:

You may also want to look into [1] .user.ini files.

+Steven

Would you consider compiling PHP with this option:

--with-config-file-scan-dir /home/vcap/app/php/etc/php.d

And then providing some mechanism for the buildpack to copy .ini files
from a known location into that directory?



[1] http://php.net/manual/en/configuration.file.per-user.php
--
Nicholas Calugar

On January 20, 2017 at 5:36:45 AM, Daniel Mikusa (dmikusa(a)pivotal.io)
wrote:

You can include a `.profile.d/` script or a `.profile` script. It depends
on exactly what you're trying to do as to which one would be better to use,
but I believe most of the time you'd want the `.profile` script. You can
see more about it in the docs here.

https://docs.cloudfoundry.org/devguide/deploy-apps/deploy-app.html#profile

You can essentially do whatever you want in this script. Plus you'll have
access to everything that the PHP build pack has configured for you and
you'll have access to all the environment variables. This means you can
run PHP scripts or examine VCAP_SERVICES. The only catch is that these
scripts runs prior to your application starting so they must run and your
application must start within the defined timeout (default 60s, max 180s on
most platforms).

If you want to integrate with the build pack and do something during
staging or if you need more time (cause staging typically runs for up to
900s), you can add a build pack extension. These are written in Python and
run as a part of the build pack. Instructions on doing that can be found
here.

https://github.com/cloudfoundry/php-buildpack#extensions

Hope that helps!

Dan

On Thu, Jan 19, 2017 at 4:01 PM, Leandro David Cacciagioni <
leandro.21.2008(a)gmail.com> wrote:

I have a php monolith app that requires tons of .ini files config
previous to the deployment I want to know if any of you have a "best
practice" to generate all this ini files depending from the environmental
variables.


Re: [ PHP ] Best config practices

Nicholas Calugar
 

You may also want to look into [1] .user.ini files.

+Steven

Would you consider compiling PHP with this option:

--with-config-file-scan-dir /home/vcap/app/php/etc/php.d

And then providing some mechanism for the buildpack to copy .ini files from
a known location into that directory?



[1] http://php.net/manual/en/configuration.file.per-user.php
--
Nicholas Calugar

On January 20, 2017 at 5:36:45 AM, Daniel Mikusa (dmikusa(a)pivotal.io) wrote:

You can include a `.profile.d/` script or a `.profile` script. It depends
on exactly what you're trying to do as to which one would be better to use,
but I believe most of the time you'd want the `.profile` script. You can
see more about it in the docs here.

https://docs.cloudfoundry.org/devguide/deploy-apps/deploy-app.html#profile

You can essentially do whatever you want in this script. Plus you'll have
access to everything that the PHP build pack has configured for you and
you'll have access to all the environment variables. This means you can
run PHP scripts or examine VCAP_SERVICES. The only catch is that these
scripts runs prior to your application starting so they must run and your
application must start within the defined timeout (default 60s, max 180s on
most platforms).

If you want to integrate with the build pack and do something during
staging or if you need more time (cause staging typically runs for up to
900s), you can add a build pack extension. These are written in Python and
run as a part of the build pack. Instructions on doing that can be found
here.

https://github.com/cloudfoundry/php-buildpack#extensions

Hope that helps!

Dan

On Thu, Jan 19, 2017 at 4:01 PM, Leandro David Cacciagioni <
leandro.21.2008(a)gmail.com> wrote:

I have a php monolith app that requires tons of .ini files config previous
to the deployment I want to know if any of you have a "best practice" to
generate all this ini files depending from the environmental variables.


CF Java Client

Chenulu P
 

I am trying build the Java Client from https://github.com/cloudfoundry/cf-java-client.git. However none of the jar files generated contains the classes referred to in the sample code https://docs.cloudfoundry.org/buildpacks/java/java-client.html#sample-code

I would really appreciate if anyone can provide me how to build the client jar so that I can reference the client lib methods.

TIA.


Re: [ PHP ] Best config practices

Daniel Mikusa
 

You can include a `.profile.d/` script or a `.profile` script. It depends
on exactly what you're trying to do as to which one would be better to use,
but I believe most of the time you'd want the `.profile` script. You can
see more about it in the docs here.

https://docs.cloudfoundry.org/devguide/deploy-apps/deploy-app.html#profile

You can essentially do whatever you want in this script. Plus you'll have
access to everything that the PHP build pack has configured for you and
you'll have access to all the environment variables. This means you can
run PHP scripts or examine VCAP_SERVICES. The only catch is that these
scripts runs prior to your application starting so they must run and your
application must start within the defined timeout (default 60s, max 180s on
most platforms).

If you want to integrate with the build pack and do something during
staging or if you need more time (cause staging typically runs for up to
900s), you can add a build pack extension. These are written in Python and
run as a part of the build pack. Instructions on doing that can be found
here.

https://github.com/cloudfoundry/php-buildpack#extensions

Hope that helps!

Dan

On Thu, Jan 19, 2017 at 4:01 PM, Leandro David Cacciagioni <
leandro.21.2008(a)gmail.com> wrote:

I have a php monolith app that requires tons of .ini files config previous
to the deployment I want to know if any of you have a "best practice" to
generate all this ini files depending from the environmental variables.


Re: Proposed changes to Gorouter log message format

Gwenn Etourneau
 

Thanks Shannon ! that's a pretty good news hope we can increase perf more.
:)

On Fri, Jan 20, 2017 at 6:20 AM, Mike Youngstrom <youngm(a)gmail.com> wrote:

Thanks Shannon.

FWIW we strip the first timestamp from log messages sent to Splunk because
Splunk doesn't detect the message as JSON unless the entire event is
properly formatted json. Either way, I think always second position should
be fine.

Mike

On Thu, Jan 19, 2017 at 12:44 PM, Shannon Coen <scoen(a)pivotal.io> wrote:

Mike, thank you for your response. The Routing team tells me we can count
on the library-provided timestamp appearing in the second position. To be
clear, a full log message has two timestamps, one provided by the logging
library (epoch), and one that our Gorouter code prepends every message with
(human readable).

[2017-01-13 22:05:58+0000] {"log_level":1,"timestamp":148
4345158.9532504,"message":"starting","source":"vcap.gorouter","data":{}}

If you're referring to the human readable one, that will continue to
prepend the JSON object.

Etourneau, we've seen 10-20% improvement in throughput by swapping lager
for zap in this use case. There are still valid reasons for other CF
components to continue using lager, including features it supports that zap
does not. However, we don't have requirements for those features in
Gorouter, and performance is particularly important in this component. We
will be publishing a blog post as a sequel to one we published recently, in
which we'll share the tooling we've developed for exploring performance
improvements, what we've tried that worked and didn't, and our results.


Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

On Wed, Jan 18, 2017 at 9:50 PM, Mike Youngstrom <youngm(a)gmail.com>
wrote:

4. Key reordering. My expectation is that no one should be using key
order for log analysis.

lager
{"timestamp","source","message","log_level","data"}

zap
{"log_level","timestamp","message","source","data"}


Our Splunk configuration requires the timestamp to be early in the log
message. Should be fine as the second item. But, might cause issues any
further into the message than that.

Mike

3101 - 3120 of 9425