|
Re: Stdout from Spring Boot app in CF
James Bayer
can you supply a simple sample example on github or similar that
toggle quoted message
Show quoted text
demonstrates the issue? i haven't had issues with using spring boot logs on CF before. On Thu, Sep 10, 2015 at 5:56 AM, Qing Gong <qinggong(a)gmail.com> wrote:
I can get a simple Java app stdout (deployed using cf push JavaClass) to --
Thank you, James Bayer |
|
|
|
Re: Java Buildpack v3.2
James Bayer
chris,
congrats on the release. this has lots of very nice improvements. i thought Luna HSM was more about a hardware security module for establishing trust instead of a way to add entropy to a system. does it also have capabilities related to entropy? On Thu, Sep 10, 2015 at 4:22 AM, Christopher Frost <cfrost(a)pivotal.io> wrote: I'm pleased to announce the release of the java-buildpack, version 3.2. This -- Thank you, James Bayer |
|
|
|
Re: UAA user dynamic properties
Sree Tummidi
Hi,
toggle quoted message
Show quoted text
We do have plans to support custom attributes and is a roadmap item. This is however not in the immediate future. Thanks, Sree Sent from my iPhone On Sep 10, 2015, at 4:13 AM, Viktor Khoroshko <oceansize(a)tut.by> wrote: |
|
|
|
Stdout from Spring Boot app in CF
Qing Gong
I can get a simple Java app stdout (deployed using cf push JavaClass) to go to firehose as logging messages. However, when I deployed a Spring Boot app, I don't get the logging (to stdout) messages from the firehose. If I just ran the Spring Boot app alone (using java -jar SpringBootApp.jar instead of cf push SpringBootApp.jar), I could get the messages coming out in the console or log file that I configured through log4j. System.out also works fine in the console. So, why stdout doesn't work from a Spring Boot app for firehose collection? How is it different from a plain Java app which works fine for firehose?
Thanks! |
|
|
|
Re: Add app monitoring agent framework in custom buildpack
Christopher Frost
Hi,
toggle quoted message
Show quoted text
The Java Buildpack is under the Apache License so you can reuse the code as you like but obviously you will need to rewrite it from Ruby to Java if your buildpack is written in Java. The steps you will need to go through to get New Relic or Wily working will be very similar regardless of the language the buildpack is written in. Christopher Frost - Pivotal UK Java Buildpack Team On Thu, Sep 10, 2015 at 9:07 AM, Swatz bosh <swatzron(a)gmail.com> wrote:
Hello, |
|
|
|
Java Buildpack v3.2
Christopher Frost
I'm pleased to announce the release of the java-buildpack, version 3.2. This
release focuses on more options to configure JRE memory settings. It has the following highlights: - Memory calculator 2.0.0 which includes support for specifying initial memory values and expected thread values. - Support for Luna HSM service to provide entropy. - Improved Dynatrace documentation. (via Josef Hoerandtner <https://github.com/cloudfoundry/java-buildpack/pull/207>) - Allow any additional New Relic configuration to be passed through to the agent. (via Bryan Custer <https://github.com/cloudfoundry/java-buildpack/issues/221>) - Support for Spring Insight updated to version 2.0.0. For a more detailed look at the changes in 3.2, please take a look at the commit log <https://github.com/cloudfoundry/java-buildpack/compare/v3.1.1...v3.2>. Packaged versions of the buildpack, suitable for use with create-buildpack and update-buildpack, can be found attached to this release <https://github.com/cloudfoundry/java-buildpack/releases/tag/v3.2>. *Packaged Dependencies* - AppDynamics Agent: 4.1.3_1 - GemFire 8.0.0 - GemFire Modules 8.0.0.1 - GemFire Modules Tomcat7 8.0.0.1 - GemFire Security 8.0.0 - Groovy: 2.4.4 - JRebel 6.2.3 - MariaDB JDBC: 1.2.0 - Memory Calculator (mountainlion): 2.0.0.RELEASE - Memory Calculator (precise): 2.0.0.RELEASE - Memory Calculator (trusty): 2.0.0.RELEASE - New Relic Agent: 3.20.0 - OpenJDK JRE (mountainlion): 1.8.0_60 - OpenJDK JRE (precise): 1.8.0_60 - OpenJDK JRE (trusty): 1.8.0_60 - Play Framework JPA Plugin: 1.10.0.RELEASE - PostgreSQL JDBC: 9.4.1202 - RedisStore: 1.2.0_RELEASE - Spring Auto-reconfiguration: 1.10.0_RELEASE - Spring Boot CLI: 1.2.5_RELEASE - Tomcat Access Logging Support: 2.4.0_RELEASE - Tomcat Lifecycle Support: 2.4.0_RELEASE - Tomcat Logging Support: 2.4.0_RELEASE - Tomcat: 8.0.26 Christopher Frost - Pivotal UK Java Buildpack Team |
|
|
|
UAA user dynamic properties
Viktor Khoroshko
Hello everyone,
We're currently evaluating UAA to be used as Central Identity Provider in our system. And the issue for us is that It's not allowed to store additional user properties (you're limited by users columns that are currently supported). Therefore, we have a question - are there any plans to add user dynamic properties support in future releases? Or, at least, do you agree that this would be an useful feature (so we may contribute)? Thanks in advance |
|
|
|
Add app monitoring agent framework in custom buildpack
Swatz bosh
Hello,
I have a custom buildpack of my software and and I want to use NewRelic/CA Wily agent frameworks which is added in java-buildpack [1]. So may I know what all components of these agents I can reuse from java-buildpack? I found that these agents are written in Ruby, so can I reuse them in my buildpack which is on java? [1] https://github.com/cloudfoundry/java-buildpack/blob/master/lib/java_buildpack/framework/new_relic_agent.rb Thanks |
|
|
|
script cleanup in cf-release
Amit Kumar Gupta
Hi cf-dev,
This is a final reminder that we will be cleaning up the various scripts that had sprawled across cf-release, deleting unused ones and moving the rest to the scripts directory. Moves: * bosh-lite/make_manifest -> scripts/generate-bosh-lite-dev-manifest * generate_deployment_manifest -> scripts/generate_deployment_manifest * update -> scripts/update * update.bat -> scripts\update.bat Deletions: * scripts/travis/install_spiff * check_travis.rb * outdated * outdated_stats * the entire "shared" submodule Please update your workflows, dev tooling, and CI scripts to reflect the upcoming changes. Best, Amit |
|
|
|
Re: How to deploy a Web application using HTTPs
James Bayer
the standard way to do this is to terminate SSL at a load balancer, which
then forwards to the CF routing tier. the hop between the load balancer and the cf router may be done with SSL. the network path from gorouter to the DEA / Diego Cell backend is only supported with http today. the gorouter must be able to inspect the request to see the http host header and cookies (to evaluate session stickiness) to know which app the request is intended for. the TCP router which is coming soon and available to preview with lattice.cf would open up the opportunity to use a random port to identify the app, which could then pass through to the the backend that had a secure listen port. On Wed, Sep 9, 2015 at 1:45 AM, Juan Antonio Breña Moral < bren(a)juanantonio.info> wrote: Hi James, -- Thank you, James Bayer |
|
|
|
Re: cf push hanged in after package donwload
Amit Gupta
Hi David,
Looks like this question is a duplicate of the issue you just opened here: https://github.com/cloudfoundry/cf-release/issues/783 Please look for our response to this question in the next few days over on the github issue. Best, Amit |
|
|
|
Re: consolidated routing api
Shannon Coen
Some of the proposed changes to the Routing API are backward incompatible.
toggle quoted message
Show quoted text
We don't believe anyone is using it yet, as adoption has generally be blocked on securing connections to Consul, but we'd like to confirm. Please raise your hand if you're using the routing API. Thank you! Shannon Coen Product Manager, Cloud Foundry Pivotal, Inc. On Wed, Sep 9, 2015 at 12:10 PM, Shannon Coen <scoen(a)pivotal.io> wrote:
We currently have two routing APIs in CF. |
|
|
|
Re: tcp-routing in Lattice
Marco Nicosia
Hi Jack,
toggle quoted message
Show quoted text
In addition to Atul's suggestions, could you please give us the exact command lines which you used to launch the two apps? The CLI arguments are tricky, we may be able to see something about the way you've tried to configure the routes by looking at how you've launched the apps. -- Marco Nicosia Product Manager Pivotal Software, Inc. mnicosia(a)pivotal.io c: 650-796-2948 On Wed, Sep 9, 2015 at 2:32 PM, Jack Cai <greensight(a)gmail.com> wrote:
I'm playing around with the tcp-routing feature in the latest Lattice |
|
|
|
Important changes in CF v217
Amit Kumar Gupta
This release introduces significant improvements to the security of the
consul cluster, however the operator must introduce these changes over the course of multiple deployments. If you are not running any consul servers as part of your deployment, you can ignore these instructions. Otherwise, please do the following: 1. Scale the number of consul servers in your existing deployment down to 1 instance. The consul.agent.servers.lan property must be updated to reflect this; this should happen for free if you are using the standard tooling for manifest generation. If you are deploying Diego alongside CF, you must redeploy Diego as well to pick up the consul.agent.servers.lan change; again, this should happen for free if using the standard manifest generation tooling. 2. Generate SSL certificates, keys, and a separate encryption key for the gossip protocol used by consul (instructions: https://docs.cloudfoundry.org/deploying/consul-security.html). Upload the v217 release and generate your manifest for CF (and then Diego, if also deploying Diego). 3. Deploy CF (and then Diego, if also deploying Diego). 4. Scale the number of consul servers back up to whatever you had it at before. Regenerate all relevant manifests and deploy. Best, Amit |
|
|
|
Re: tcp-routing in Lattice
Atul Kshirsagar
Its possible that HAProxy was not properly configured. Can you provide output of `ltc status <app name>`? This will tell if tcp route has been configured for the app.
Some things you can try: 1) You can then try doing `ltc update --tcp-route externalport:containerport` and see if that fixes the problem (this will result in reconfiguring HAProxy again). 2) If that doesn't work too...then try vagrant reload to make sure all the processes in lattice brain are restarted to rule out the problem that HAproxy is not in bad state. |
|
|
|
Re: v3 cc api style guide feedback requested
Dieu Cao <dcao@...>
Thanks Guillaume!
toggle quoted message
Show quoted text
On Wed, Sep 9, 2015 at 2:33 PM, Guillaume Berche <bercheg(a)gmail.com> wrote:
Hi Dieu, |
|
|
|
Re: v3 cc api style guide feedback requested
Hi Dieu,
toggle quoted message
Show quoted text
Here are corresponding issues/comments submitted https://github.com/cloudfoundry/cc-api-v3-style-guide/issues/46 https://github.com/cloudfoundry/cc-api-v3-style-guide/issues/47 https://github.com/cloudfoundry/cc-api-v3-style-guide/issues/48 https://github.com/cloudfoundry/cc-api-v3-style-guide/issues/49 https://github.com/cloudfoundry/cc-api-v3-style-guide/issues/41#issuecomment-139050180 https://github.com/cloudfoundry/cc-api-v3-style-guide/issues/41#issuecomment-139051114 Guillaume. On Wed, Sep 9, 2015 at 10:39 AM, Dieu Cao <dcao(a)pivotal.io> wrote:
Hi Guillaume, |
|
|
|
tcp-routing in Lattice
Jack Cai
I'm playing around with the tcp-routing feature in the latest Lattice
release. I started two node.js applications in the pushed image (listening on two ports), one mapped to an http route and the other to a tcp route. I can connect to the http route successfully in the browser, but when I try to connect to the tcp port in the browser, I got connection refused. It looks like the mapped public tcp port on 192.168.11.11 is not open at all. Any advice on how to diagnose this? Thanks in advance! Jack |
|
|
|
Re: Loggregator not accessible, errors in the logs
Rohit Kumar
Answers to your questions:
toggle quoted message
Show quoted text
1. That error might be caused if your doppler servers aren't healthy and therefore not listed in etcd. The traffic-controller polls etcd to discover dopplers. 2. You do need metron and dopplers to access logs via "cf logs". The logs are emitted by the DEA agent to metron, which forwards them to doppler servers. Doppler servers deal with buffering logs (so that they are accessible via the "cf logs --recent" command) and also deal with syslog forwarding. Thanks, Rohit On Wed, Sep 9, 2015 at 2:33 PM, kyle havlovitz <kylehav(a)gmail.com> wrote:
I'm seeing this message repeating over and over in the traffic controller |
|
|
|
Loggregator not accessible, errors in the logs
kyle havlovitz <kylehav@...>
I'm seeing this message repeating over and over in the traffic controller
logs: {"timestamp":1441830145.719944000,"process_id":32413,"source":"loggregator trafficcontroller","log_level":"debug","message":"ServerAddressList.Run: Unable to recursively find keys with prefix /healthstatus/doppler","data":null,"file":"/opt/cloudfoundry/cf-release/src/loggregator/src/ github.com/cloudfoundry/loggregatorlib/servicediscovery/servicediscovery.go ","line":78,"method":" github.com/cloudfoundry/loggregatorlib/servicediscovery.(*serverAddressList).DiscoverAddresses "} Here's my config: "EtcdUrls" : ["http://localhost:4001"], "EtcdMaxConcurrentRequests" : 10, "WSMessageBufferSize": 100, "OutgoingDropsondePort": 8082, "DopplerPort": 8082, "IncomingPort": 3456, "OutgoingPort": 9090, "SkipCertVerify": true, "Index": 0, "MaxRetainedLogMessages": 100, "SharedSecret": "secret", "Host": "0.0.0.0", "SystemDomain": "local.example.com", "ApiHost": "http://127.0.0.1:8181", "NatsHosts": ["127.0.0.1"], "NatsPort": 4222, "NatsUser": "nats", "NatsPass": "password", "VarzUser": "varz", "VarzPass": "password", "VarzPort": 8888, "MetronPort": 3457, "Syslog" : "", "Zone": "CRAZY_TOWN", "UaaHost": "http://localhost:8080", "UaaClientId": "doppler", "UaaClientSecret": "tokensecret" } I have all the components running locally, using cf-release 215. I have two questions: 1. what's causing this error? 2. if all I want out of the system are logs (via cf logs command), can I get away with just having a traffic controller and dea agent running or do I need metron and doppler? |
|
|