george,

can you explain the scenario that is impacting you currently? e.g. reading
a java stack trace? the app index is shown in the log line. when using the
loggregator websocket client to retrieve logs you should also get the
application id. perhaps that is enough to correlate whatever UI you have on
top of logstash?


On Tue, May 12, 2015 at 7:40 AM, Li, George <guangxing.li(a)pearson.com>
wrote:

Hi,

this is a follow up on the archived posting
https://groups.google.com/a/cloudfoundry.org/forum/?utm_medium=email&utm_source=footer#!msg/vcap-dev/B1W6_vO0oyo/84X1eAtFsKoJ.
I cannot find any new postings on that thread.
I am using Cloud Foundry version
"6.11.2-2a26d55-2015-04-27T21:11:44+00:00" and want to know what options I
have to handle multiple line logs in a multi-tenant environment. Since
multiple instances of multiple applications are all sending logs to a
single Logstash server, is it best to avoid having multiple lines in my
log? I can live with sticking to single line logs except for outputting
exception stack trace, not to mention that I only have control over my
code.

Thanks.

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

--
Thank you,

James Bayer

thanks steve! that's a nice addition to the java buildpack. i think all
java developers have experienced the pain of managing memory explicitly
with -X and -XX args at one point or another. having built-in sane defaults
that auto-adjust is hopefully one less thing java developers have to worry
about when using the java buildpack.

On Tue, May 12, 2015 at 8:12 AM, Christopher Frost <cfrost(a)pivotal.io>
wrote:

When deploying a Java application to Cloud Foundry the Java memory
settings for the application are decided based on the configured memory
weighting during staging. This means that, unlike other apps, if the
application is scaled to give it more memory it needs to be *restage*d it
to get updated Java memory settings. This has now been improved with an
improved memory calculator written by Steve Powell[2]. The Memory
Calculator[1] will be run during every application start to ensure the
application gets up-to-date memory settings, its output is shown during
staging.

-----> Downloading Open JDK Like Memory Calculator 1.1.1_RELEASE from
https://download.run.pivotal.io/memory-calculator/trusty/x86_64/memory-calculator-1.1.1_RELEASE
(found in cache)
Memory Settings: -XX:MaxMetaspaceSize=64M -XX:MetaspaceSize=64M
-Xss995K -Xmx382293K -Xms382293K

Then scaling the application to double the memory will result in new
memory settings without having to restage the application.

cf scale my-application -m 1G

-Xmx768M -Xms768M -XX:MaxMetaspaceSize=104857K -XX:MetaspaceSize=104857K
-Xss1M


This new feature is currently available on the master branch of the
buildpack [3] and will be released in due course.


Chris.

[1] https://github.com/cloudfoundry/java-buildpack-memory-calculator
[2] https://github.com/Zteve
[3] https://github.com/cloudfoundry/java-buildpack

--
Christopher Frost - Pivotal UK

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

--
Thank you,

James Bayer

Great to see this!!!

Hi All,
We are pleased to announce the release of UAA 2.3.0. Please find the
release details below:

*Features*

- Updated Spring Versions
<https://www.pivotaltracker.com/story/show/93706906>: Spring 4.1.x,
Spring Security 3.2 latest, Spring Security OAuth 2.0.x latest, Tomcat
Version 7.0.x latest
- Both LDAP and internal user store authentication should be allowed to
be set in an enabled state in an Identity Zone
<https://www.pivotaltracker.com/story/show/92369926>
- Hide Create Account and Reset Password link if client is not
associated with internal user store authentication
<https://www.pivotaltracker.com/story/show/92083260>

—
View it on GitHub <https://github.com/cloudfoundry/uaa/releases/tag/2.3.0>.
In addition to this we have also added support for New Relic Monitoring &
Updated the JRE version to 1.7 which will be available in the next version
of cf-release

Thanks,
Sree Tummidi
Sr. Product Manager
Identity - Pivotal Cloud Foundry

Thank you Jon, I'll test against a similar deployment and I'll let you know what I find.

Cheers,
Vlad

From: Price, Jon [mailto:jon.price(a)intel.com]
Sent: Friday, May 15, 2015 11:49 AM
To: Iovanov, Vlad Mircea; cf-dev(a)lists.cloudfoundry.org
Subject: RE: [cf-dev] visual studio extension - login error

Hi Vlad,

We are running CF release 207.

Here is the /v2/info output with some of the data sanitized:

{"name":"vcap","build":"2222","support":"http://url.removed",
"authorization_endpoint":"https://login.paaslab3.xxx.com",
"token_endpoint":"https://uaa.paaslab3.xxx.com","min_cli_version":null,
"min_recommended_cli_version":null,"api_version":"2.25.0",
"logging_endpoint":"wss://loggregator.paaslab3.xxx.com:443"}

We normally have ldap authentication enabled and require ssl between the login server and uaa but even after disabling all of that and running with what I think is a pretty simple and standard configuration we get the error.

Thank you for taking the time to look into this.

-- Jon

From: cf-dev-bounces(a)lists.cloudfoundry.org<mailto:cf-dev-bounces(a)lists.cloudfoundry.org> [mailto:cf-dev-bounces(a)lists.cloudfoundry.org] On Behalf Of Iovanov, Vlad Mircea
Sent: Friday, May 15, 2015 10:52 AM
To: cf-dev(a)lists.cloudfoundry.org<mailto:cf-dev(a)lists.cloudfoundry.org>
Subject: Re: [cf-dev] visual studio extension - login error

Hello Jon,

Can you please let me know what version of Cloud Foundry you are running? If you could include the output of your "info" endpoint it would be great (http://apidocs.cloudfoundry.org/208/info/get_info.html)

Cheers,
Vlad

Great job! Can't wait to play with this.

Chris Sterling
chris.sterling(a)gmail.com
twitter: @csterwa
linkedin: http://www.linkedin.com/in/chrissterling

On Fri, May 15, 2015 at 12:25 PM, Christopher B Ferris <chrisfer(a)us.ibm.com>
wrote:

Awesome! Great work, team!

Cheers,

Christopher Ferris
IBM Distinguished Engineer, CTO Open Cloud
IBM Software Group, Open Technologies
email: chrisfer(a)us.ibm.com
twitter: @christo4ferris
blog: http://thoughtsoncloud.com/index.php/author/cferris/
phone: +1 508 667 0402

[image: Inactive hide details for Jack Cai ---05/15/2015 03:19:53 PM---We
just open sourced a buildpack that can run the latest ASP.NET]Jack Cai
---05/15/2015 03:19:53 PM---We just open sourced a buildpack that can run
the latest ASP.NET 5 applications [1]. ASP.NET 5 is a

From: Jack Cai <greensight(a)gmail.com>
To: cf-dev(a)lists.cloudfoundry.org
Date: 05/15/2015 03:19 PM
Subject: [cf-dev] ASP.NET 5 buildpack now in cloudfoundry-community
Sent by: cf-dev-bounces(a)lists.cloudfoundry.org
------------------------------



We just open sourced a buildpack that can run the latest *ASP.NET*
<http://asp.net/> 5 applications [1]. *ASP.NET* <http://asp.net/> 5 is a
major redesign of *ASP.NET* <http://asp.net/> [2]. This is also a key
difference from the existing .net buildpack [3].

Right now this buildpack still uses Mono[4] emulation layer, but we expect
it to switch to the .Net core CLR for Linux [5] once it becomes more
viable.

We hope you have a chance to try it and give us feedback. *ASP.NET*
<http://asp.net/> 5 is rapidly evolving and you can help influence how
the buildpack grows with it.

Thanks!

Jack

[1] *https://github.com/cloudfoundry-community/asp.net5-buildpack*
<https://github.com/cloudfoundry-community/asp.net5-buildpack>
[2] *http://docs.asp.net/en/latest/conceptual-overview/aspnet.html*
<http://docs.asp.net/en/latest/conceptual-overview/aspnet.html>
[3] *https://github.com/cloudfoundry-community/.net-buildpack*
<https://github.com/cloudfoundry-community/.net-buildpack>
[4] *http://www.mono-project.com/* <http://www.mono-project.com/>
[5] *https://github.com/dotnet/coreclr*
<https://github.com/dotnet/coreclr>
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev



_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

Awesome! Great work, team!

Cheers,

Christopher Ferris
IBM Distinguished Engineer, CTO Open Cloud
IBM Software Group, Open Technologies
email: chrisfer(a)us.ibm.com
twitter: @christo4ferris
blog: http://thoughtsoncloud.com/index.php/author/cferris/
phone: +1 508 667 0402



From: Jack Cai <greensight(a)gmail.com>
To: cf-dev(a)lists.cloudfoundry.org
Date: 05/15/2015 03:19 PM
Subject: [cf-dev] ASP.NET 5 buildpack now in cloudfoundry-community
Sent by: cf-dev-bounces(a)lists.cloudfoundry.org



We just open sourced a buildpack that can run the latest ASP.NET 5
applications [1]. ASP.NET 5 is a major redesign of ASP.NET [2]. This is
also a key difference from the existing .net buildpack [3].

Right now this buildpack still uses Mono[4] emulation layer, but we expect
it to switch to the .Net core CLR for Linux [5] once it becomes more
viable.

We hope you have a chance to try it and give us feedback. ASP.NET 5 is
rapidly evolving and you can help influence how the buildpack grows with
it.

Thanks!

Jack

[1] https://github.com/cloudfoundry-community/asp.net5-buildpack
[2] http://docs.asp.net/en/latest/conceptual-overview/aspnet.html
[3] https://github.com/cloudfoundry-community/.net-buildpack
[4] http://www.mono-project.com/
[5] https://github.com/dotnet/coreclr
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

We just open sourced a buildpack that can run the latest ASP.NET 5
applications [1]. ASP.NET 5 is a major redesign of ASP.NET [2]. This is
also a key difference from the existing .net buildpack [3].

Right now this buildpack still uses Mono[4] emulation layer, but we expect
it to switch to the .Net core CLR for Linux [5] once it becomes more
viable.

We hope you have a chance to try it and give us feedback. ASP.NET 5 is
rapidly evolving and you can help influence how the buildpack grows with it.

Thanks!

Jack

[1] https://github.com/cloudfoundry-community/asp.net5-buildpack
[2] http://docs.asp.net/en/latest/conceptual-overview/aspnet.html
[3] https://github.com/cloudfoundry-community/.net-buildpack
[4] http://www.mono-project.com/
[5] https://github.com/dotnet/coreclr

Hi Vlad,

We are running CF release 207.

Here is the /v2/info output with some of the data sanitized:

{"name":"vcap","build":"2222","support":"http://url.removed",
"authorization_endpoint":"https://login.paaslab3.xxx.com",
"token_endpoint":"https://uaa.paaslab3.xxx.com","min_cli_version":null,
"min_recommended_cli_version":null,"api_version":"2.25.0",
"logging_endpoint":"wss://loggregator.paaslab3.xxx.com:443"}

We normally have ldap authentication enabled and require ssl between the login server and uaa but even after disabling all of that and running with what I think is a pretty simple and standard configuration we get the error.

Thank you for taking the time to look into this.

-- Jon

From: cf-dev-bounces(a)lists.cloudfoundry.org [mailto:cf-dev-bounces(a)lists.cloudfoundry.org] On Behalf Of Iovanov, Vlad Mircea
Sent: Friday, May 15, 2015 10:52 AM
To: cf-dev(a)lists.cloudfoundry.org
Subject: Re: [cf-dev] visual studio extension - login error

Hello Jon,

Can you please let me know what version of Cloud Foundry you are running? If you could include the output of your "info" endpoint it would be great (http://apidocs.cloudfoundry.org/208/info/get_info.html)

Cheers,
Vlad

Hello Jon,

Can you please let me know what version of Cloud Foundry you are running? If you could include the output of your "info" endpoint it would be great (http://apidocs.cloudfoundry.org/208/info/get_info.html)

Cheers,
Vlad

Hi Piotr,

The cloudfoundry-community github org is open to anyone in the community
who'd like to publicize their code. I don't believe there are any strict
guidelines around the license that should be applied; and in fact this code
is explicitly **not** owned by the CF Foundation.

Instead, this code is owned by its authors and contributors. I'd suggest
that you open a Github Issue on the repo asking for a license to be
explicilty declared, either in the README or in a separate LICENSE file.
Usually authors are very willing to do so once asked.

Cheers,
-mike

Hi Jon,

Just for context, the VS extension was only this week open-sourced by HP
and put into the CF incubator.

I expect this issue is arising because the VS extension was developed to
run with HP Helion, which has followed its own evolutionary path from a
previous version of CF, and so it has not been tested against CF edge.

As the Foundation and HP work together to incubate this project in earnest,
we'll work through these support issues and get it working with current
versions of CF.

I expect these speed bumps will get addressed quickly, and so thanks in
advance for your patience.

-m

Hi Stephen,

DRYRUN mode does everything the same as normal operation *except* for the
actual deletion, so if Chaos Lemur is reporting unexpected names it's a
problem with some other part of your config, not DRYRUN. From your
environment variables it seems you haven't configured it to access your
underlying infrastructure, either AWS or VSphere. You need to provide
credentials[1] for one of those:

AWS_ACCESSKEYID & AWS_SECRETACCESSKEY, or

VSPHERE_HOST & VSPHERE_PASSWORD & VSPHERE_USERNAME

Give that a go and it should work, but be aware that if DRYRUN is not true
then you will lose VMs!

Cheers, Paul

[1]: https://github.com/pivotal-cf/chaos-lemur#environment-variables



--
View this message in context: http://cf-dev.70369.x6.nabble.com/cf-dev-Problem-for-Chaos-Lemur-tp90p96.html
Sent from the CF Dev mailing list archive at Nabble.com.

The "norouter", while interesting, isn't the official CF project approach
to HTTP traffic routing. The TCP router is being built to support TCP
routing as a general solution, with the goal of it becoming an official
part of the CF release when ready.

-chip

Chip Childers | Technology Chief of Staff | Cloud Foundry Foundation

On Fri, May 15, 2015 at 8:58 AM, Mohamed, Owais <Owais.Mohamed(a)covisint.com>
wrote:

Hi,

I attended sessions on both TCP Router (Cloud Foundry and IOT protocol
support by Atul Kshirsagar) and NoRouter (Norouter: Running Cloud Foundry
without the Gorouter by Mike Heath).

I just wanted to start a discussion on the pros and cons of each
approach.

As personal opinion I think NoRouter is a simpler approach and can
definitely be made to support IOT protocols. The main drawback I see with
the NoRouter is the danger of the LTM becoming a Monolith.

Any suggestions\ideas?

Regards,
Owais


_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

You can use the allow_host_access property in your manifest to enable the
access. It simply suppresses the iptables rule you mention that rejects the
traffic.

https://github.com/cloudfoundry/cf-release/blob/master/jobs/dea_next/spec#L37

Aaron Huber
Intel Corporation



--
View this message in context: http://cf-dev.70369.x6.nabble.com/cf-dev-Capturing-data-from-DEA-varz-endpoints-tp92p95.html
Sent from the CF Dev mailing list archive at Nabble.com.

As part of our CF monitoring we want to collect data from the DEA varz
endpoints to help us calculate our headroom. In the spirit of eating our
own dogfood we want to deploy this a micro service on CF itself.

The challenge we face is the DEA explicitly denies the containers to talk
to the varz endpoint for the DEA the app runs on. It can happily hit varz
for all other DEAs. The deny is handled by an iptable reject on the dea's
interface.

Looking at my options, I could run the app outside of CF or add an iptable
rule to the dea's. Neither option fills me with joy.

How have others approached the problem of collecting varz data for
analysis? Admin-ui does this but runs on a VM, possibly for this very
reason.

Thanks
John.

Hi,

I attended sessions on both TCP Router (Cloud Foundry and IOT protocol support by Atul Kshirsagar) and NoRouter (Norouter: Running Cloud Foundry without the Gorouter by Mike Heath).

I just wanted to start a discussion on the pros and cons of each approach.

As personal opinion I think NoRouter is a simpler approach and can definitely be made to support IOT protocols. The main drawback I see with the NoRouter is the danger of the LTM becoming a Monolith.

Any suggestions\ideas?

Regards,
Owais

Thanks Chris.
We had given the MALLOC_ARENA_MAX setting a wide birth because Lari had
mentioned it was buggy on lucid64 & we're still on that stemcell right now.

We do have a test case running all weekend on Tomcat 8.0.22, which I'll try
to remember to post back to the list on.





--
View this message in context: http://cf-dev.70369.x6.nabble.com/Re-cf-dev-Cf-dev-vcap-dev-Java-OOM-debugging-tp25p91.html
Sent from the CF Dev mailing list archive at Nabble.com.

Hi guys,

I am trying to use the tool Chaos Lemur to do HA test for CF. I got the guide from below link: http://blog.pivotal.io/cloud-foundry-pivotal/products/chaos-lemur-testing-high-availability-on-pivotal-cloud-foundry

My problem is:
Chaos Lemur seems always running in ‘DRYRUN’ mode(which means it does not destroy VMs actually). Below is the log(get from command: cf logs chaos-lemur):

2015-05-13T14:40:00.00+0800 [App/0] OUT [CHAOS LEMUR] INFO f3a09be7-8bc4-4bed-94dc-32f1a3a653f6 Beginning run...
2015-05-13T14:40:00.00+0800 [App/0] OUT [CHAOS LEMUR] INFO f3a09be7-8bc4-4bed-94dc-32f1a3a653f6 Destroyed: [id: id-3, deployment: deployment-3, job: job-3, name: name-3]
2015-05-13T14:40:00.00+0800 [App/0] OUT [CHAOS LEMUR] INFO f3a09be7-8bc4-4bed-94dc-32f1a3a653f6 Destroyed: [id: id-2, deployment: deployment-2, job: job-2, name: name-2]
2015-05-13T14:40:00.00+0800 [App/0] OUT [CHAOS LEMUR] INFO Chaos Lemur Destruction (f3a09be7-8bc4-4bed-94dc-32f1a3a653f6):
2015-05-13T14:40:00.00+0800 [App/0] OUT 2 VMs destroyed:
2015-05-13T14:40:00.00+0800 [App/0] OUT * name-2
2015-05-13T14:40:00.00+0800 [App/0] OUT * name-3

It seems that the tool is running in ‘DRYRUN’ mode because the destroyed ‘id’, ‘deployment’ and ‘job’ seems not be real names. My question is: I already set the environment variable ‘DRYRUN’ as false(also tried not set this variable). Do you have any idea?

Below are my environment variable setting:
User-Provided:
DIRECTOR_HOST: x.x.x.x
DIRECTOR_PASSWORD: admin
DIRECTOR_USERNAME: admin
DRYRUN: false
SCHEDULE: 0 0/5 * * * *
swift-dev_PROBABILITY: 0.5
swift_storage_PROBABILITY: 0.5

‘swift-dev’ is a deployment name and ‘swift_storage’ is a job name under previous deployment. I got the deployment and job from command: bosh vms. It will list all the deployments and their jobs. Is there any problems with my settings? I think if it is because that I do not get the correct ‘deployment’ and ‘job’?



Any help will be highly appreciated!



Stephen Zhou (周红星)
Mobile: +86 13683173521
Email: stephen.zhou(a)emc.com<mailto:Xu_Louie(a)emc.com>

Hey Guangcai:

Dr. Nic Williams from Stark & Wayne blogged [0] a pretty nice write up
about billing. He did a nice job updating it with the new endpoints that
Dieu noted earlier.

[0]
https://blog.starkandwayne.com/2015/01/22/billing-your-cloud-foundry-users/

Greg Oehmen
Cloud Foundry Product Manager
415.205.6596