Date   

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


Re: Proposed changes to Gorouter log message format

Mike Youngstrom
 

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":
1484345158.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


[ PHP ] Best config practices

Leandro David Cacciagioni
 

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

Shannon Coen
 

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":1484345158.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


Re: smallest number of VMs for CF deployment

Daniel Jones
 

Hi,

You may find this great talk from Altoros helpful:
https://www.youtube.com/watch?v=RJx9tLoa2ug

Regards,
Daniel Jones - CTO
+44 (0)79 8000 9153
@DanielJonesEB <https://twitter.com/DanielJonesEB>
*EngineerBetter* Ltd <http://www.engineerbetter.com> - UK Cloud Foundry
Specialists

On 19 January 2017 at 15:41, srinivas A <shreeadada(a)gmail.com> wrote:

Hi Nic,

I am trying to deploy CF with less Vms , can you please help me provide
any link which can guide me or any sample yaml file . I have checked the
above link but looks like thats been removed as it was old.
THanks

3101 - 3120 of 9421