|
Re: Java Buildpack v3.7
Josh Long <starbuxman@...>
Congratulations on the massive new release!
toggle quoted message
Show quoted text
On Sat, Apr 23, 2016 at 18:43 James Bayer <jbayer(a)pivotal.io> wrote:
impressive list of new stuff ben and team! |
|
|
|
Re: Java Buildpack v3.7
James Bayer
impressive list of new stuff ben and team!
toggle quoted message
Show quoted text
On Thu, Apr 21, 2016 at 12:19 PM, Danny Rosen <drosen(a)pivotal.io> wrote:
Great work! --
Thank you, James Bayer |
|
|
|
Re: How can i configure HA Doppler at cf.yml?
inho cho
My question missed a point.
toggle quoted message
Show quoted text
yes. metron gets doppler addresses from etcd. But only dopplers in the same zone.if possible, I would like to know how to set and get different zone's doppler . For example, - cf.yml metron-agent: - zone : z1, z2 2016. 4. 23. 오전 3:50에 "Warren Fernandes" <wfernandes(a)pivotal.io>님이 작성: Metron reads the doppler addresses from etcd. Each doppler advertises its |
|
|
|
Re: Remarks about the “confab” wrapper for consul
Amit Kumar Gupta
Hi Benjamin,
Re bumping consul: Yes, soon: https://www.pivotaltracker.com/story/show/113007637 Re updating confab so that people can tweak their consul settings directly from BOSH deployment: Currently that's not in the plans, no. However, we'd very much like to understand your findings after changing configurations. Re updating this “skip_leave_on_interrupt” config in confab: We don't currently plan on changing it. Because RAFT needs to be very carefully orchestrated when rolling clusters, scaling up, scaling down, etc. we would need to see that there is a problem and that this is the root cause. There are Consul acceptance tests (CONSATS) that exercise all this orchestration: https://github.com/cloudfoundry-incubator/consul-release#acceptance-tests If you're having a lot of flapping, suspicions, failed acks, etc. this points to a different root cause. This often has to do with restricted UDP traffic, network ACLs, etc. I opened an issue about this on the consul repo a year ago, and it's still open: https://github.com/hashicorp/consul/issues/916. Please keep us posted on your discoveries. Best, Amit On Fri, Apr 15, 2016 at 5:32 AM, Benjamin Gandon <benjamin(a)gandon.org> wrote: As an update, it looks like I’m running into the Node health flapping |
|
|
|
removing global "domain" property from Cloud Foundry manifest
Amit Kumar Gupta
Hi all,
Every week, I see a user confused by the domain, system_domain, and app_domains properties in the Cloud Foundry manifest. The confusion is primarily around domain and system_domain. These properties can be confusing even for the core development teams, since these global properties are used by many different jobs coming from many different projects, and the usage may be inconsistent. I propose we consolidate on system_domain. Here's where the other property, domain, is currently used: $ grep -r ' domain:' -- */spec blobstore/spec: domain: cloud_controller_clock/spec: domain: cloud_controller_ng/spec: domain: cloud_controller_worker/spec: domain: dea_next/spec: domain: hm9000/spec: domain: uaa/spec: domain: uaa/spec: domain: <(String) domain for cookie, default is incoming request domain> Details: - *uaa* job spec actually says it's deprecated, so we can just delete it - *hm9000* doesn't actually use it, it probably used to when it registered its own route - *dea* seems to only use it for directory server, and can probably safely use system_domain instead - *cloud_controller_ng & friends* use both domain and system_domain, but the CAPI team has concluded that only system_domain is needed. I just wanted to give the community a heads-up on this coming change. I'll ask the PMs of the various teams to try to remove these properties from their BOSH job specs, and the Release Integration team will then make sure to remove it from any manifest generation templates and documentation. Cheers, Amit |
|
|
|
Re: How can i configure HA Doppler at cf.yml?
Warren Fernandes
Metron reads the doppler addresses from etcd. Each doppler advertises its
toggle quoted message
Show quoted text
address to etcd. Increasing the number of doppler instances will automatically spread the load from all the metrons over all the dopplers. On Mon, Apr 18, 2016 at 5:36 AM, 인호 조 <ihocho(a)crossent.com> wrote:
I read "Overview of the Loggregator System " - |
|
|
|
Re: pg gem and ruby app deployment issues
John Shahid
Hi Evgeniy,
toggle quoted message
Show quoted text
Are you using a customized stack with that cloudfdoundry deployment. I’m looking at cflinuxfs2 stack/rootfs and libpq-dev has been there for a while now. This package has provided pg_config since version 9.3.4 <http://packages.ubuntu.com/trusty/arm64/libpq-dev/filelist>. Another (unlikely) possiblity, have you set --with-pg-config locally? If you had there would be a .bundle/config inside your app with similar contents as below: BUNDLE_BUILD__PG: "--with-pg-config=/usr/pgsql-9.1/bin/pg_config" On Fri, Apr 22, 2016 at 5:44 AM Evgeniy Litvinenko mirakl577(a)gmail.com
<http://mailto:mirakl577(a)gmail.com> wrote: Good day, |
|
|
|
Automating Deployment Failure Handling
Steve Amerige
When I do commands such as bosh deploy, cf push, or cf start, I sometimes see failures that are due to problems in the underlying OpenStack. When I do the commands again, the identical same deploy, push, or start succeeds.
When writing deployment scripts, I'd like to be able to headlessly detect problems and attempt to deal with them before giving up the deployment. Is it possible to get JSON results back from doing BOSH or Cloud Foundry deployment commands such as those above? This might give me more ability to have deployment scripts either decide to just try the deployment again, or to take some specific remedial action depending on what the JSON data reveals. Any thoughts as to what is available now so that I can do a better job of handling at least some classes of failures in scripts? |
|
|
|
pg gem and ruby app deployment issues
Evgeniy Litvinenko
Good day,
We have ruby application which requires gem 'pg' for connection to postgres db, for some reason I can't deploy it, it fails on bundle install phase, I used different ruby buildpacks and ruby versions but without any luck, our cf version is 212. Gemfile: source "https://rubygems.org" ruby '2.3.0' gem "sinatra", "~> 1.4.3" gem 'json' gem 'rest-client' gem 'pg' ERROR: Cloning into '/tmp/buildpacks/ruby-buildpack'... Submodule 'compile-extensions' (https://github.com/cloudfoundry/compile-extensions) registered for path 'compile-extensions' Cloning into 'compile-extensions'... Submodule path 'compile-extensions': checked out '4a0e48afc46c1d467b7c75a8ae5e6f3a044d3d64' -------> Buildpack version 1.6.16 Downloaded [https://pivotal-buildpacks.s3.amazonaws.com/ruby/binaries/shared/bundler-1.11.2.tgz] -----> Compiling Ruby/Rack Downloaded [https://pivotal-buildpacks.s3.amazonaws.com/concourse-binaries/ruby/ruby-2.3.0-linux-x64.tgz] -----> Using Ruby version: ruby-2.3.0 -----> Installing dependencies using bundler 1.11.2 Downloaded [https://pivotal-buildpacks.s3.amazonaws.com/ruby/binaries/cflinuxfs2/libyaml-0.1.6.tgz] Running: bundle install --without development:test --path vendor/bundle --binstubs vendor/bundle/bin -j4 --deployment Fetching gem metadata from https://rubygems.org/......... Fetching version metadata from https://rubygems.org/.. Using json 1.8.3 Installing netrc 0.11.0 Installing unf_ext 0.0.7.2 with native extensions Installing mime-types 2.99.1 Installing pg 0.18.4 with native extensions Installing rack 1.6.4 Installing tilt 2.0.2 Using bundler 1.11.2 Installing rack-protection 1.5.3 Installing sinatra 1.4.7 Gem::Ext::BuildError: ERROR: Failed to build gem native extension. current directory: /tmp/staged/app/vendor/bundle/ruby/2.3.0/gems/pg-0.18.4/ext /tmp/staged/app/vendor/ruby-2.3.0/bin/ruby -r ./siteconf20160422-297-z2ly6c.rb extconf.rb checking for pg_config... no No pg_config... trying anyway. If building fails, please try again with --with-pg-config=/path/to/pg_config checking for libpq-fe.h... no Can't find the 'libpq-fe.h header *** extconf.rb failed *** |
|
|
|
Re: cloud_connector_ng not starting on cf 231
francois.bonelle@...
Hi,
I have also problems with the blobstore configuration. I have followed the doc to migrate from nfs to webdav. I am doing a migration to v233 (from 230). I am getting the same error with blobstore_nginx (on nfs job): "nginx: [emerg] could not build the server_names_hash, you should increase server_names_hash_bucket_size: 64" I fixed this by adding "server_names_hash_bucket_size 128;" manually in the conf (/var/vcap/jobs/blobstore/config/nginx.conf). Is there a right way to fix this error ? Regards _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. |
|
|
|
Re: pushing docker image to CF.
Eric Malm <emalm@...>
Hi, Sangeetha,
Sorry to hear you're running into difficulties. First, can you verify that you're intending to run the public Docker Hub image at https://hub.docker.com/r/jboss/drools-workbench-showcase on the Cloud Foundry instance you're targeting? If that's the case, the issue isn't that the Docker staging task can't connect to an insecure registry, it's that it can't connect to Docker Hub on the public Internet. Are you in control of your CF+Diego deployment? If so, can you provide some details about it? As a start, it would help to know which versions of the CF and Diego releases you have deployed, what infrastructure they are deployed to, and how you're generating your deployment manifests (for example, via the manifest-generation scripts in cf-release and diego-release, or manually). Also, can you push other apps successfully? For example, can you push a buildpack app that makes an HTTP or HTTPS connection to some other service on the public Internet and verify that that app stages, runs, and connects to that service correctly? Thanks, Eric, CF Runtime Diego PM On Thu, Apr 21, 2016 at 6:20 PM, Tomoe Sugihara <tsugihara(a)pivotal.io> wrote: On Fri, Apr 22, 2016 at 3:31 AM, James Myers <jmyers(a)pivotal.io> wrote:Hi,https://github.com/cloudfoundry-incubator/diego-release/blob/develop/jobs/stager/spec#L78-L80 |
|
|
|
Re: pushing docker image to CF.
Tomoe Sugihara
On Fri, Apr 22, 2016 at 3:31 AM, James Myers <jmyers(a)pivotal.io> wrote:
Hi,Looks like that file is gone by the commit: https://github.com/cloudfoundry-incubator/diego-release/commit/a8468ab7ded8d7408aa3274395671e10a3ab5334#diff-4efdf9a6a5de284f5f98a81bef3a2788L78 I found the setting here instead: https://github.com/cloudfoundry/capi-release/blob/ee42bd82a51875d462299b9ada92cf08a5c52f8f/jobs/stager/spec#L81 And I think it is related to this change: https://lists.cloudfoundry.org/archives/list/cf-dev(a)lists.cloudfoundry.org/thread/PVD6TC6TQVOEICYY2H6ZFZ4CUMMZIPEU/ Thanks, Tomoe |
|
|
|
Manifest updates to diego-release
Utako Ueda
Hi all,
As part of the effort to move CC Bridge components from diego-release to cf-release/capi-release, we have removed the cc bridge components from the diego-release manifest. These include cc-uploader, stager, nsync, and tps. *If you are not using the diego-release manifest generation scripts, you will have to update your diego manifests to point at cf release (instead of diego release) for the components like so:* jobs: cc_bridge_zX//collocated: templates: - name: stager release: cf - name: nsync release: cf - name: tps release: cf - name: cc_uploader release: cf This change will come with the next final release. Thanks, Connor and Utako, Diego and CAPI teams |
|
|
|
Re: Java Buildpack v3.7
Danny Rosen
Great work!
toggle quoted message
Show quoted text
On Thu, Apr 21, 2016 at 3:07 PM, Dieu Cao <dcao(a)pivotal.io> wrote:
Congrats on the release! Very exciting stuff. |
|
|
|
Re: Java Buildpack v3.7
Dieu Cao <dcao@...>
Congrats on the release! Very exciting stuff.
toggle quoted message
Show quoted text
On Thu, Apr 21, 2016 at 10:16 AM, Ben Hale <bhale(a)pivotal.io> wrote:
I'm pleased to announce the release of the java-buildpack, version 3.7. |
|
|
|
Re: Question regarding simple application statistics
Don Nelson
tyvm - there is an extra character at the end of Dan's link, which is why it didn't work for me. Turns out that's the api I was asking about, I just didn't notice the app index at the top of the JSON object.
Don |
|
|
|
Re: pushing docker image to CF.
James Myers
Hi,
toggle quoted message
Show quoted text
You can set this property ( https://github.com/cloudfoundry-incubator/diego-release/blob/develop/jobs/stager/spec#L78-L80) on your Diego deployment to add insecure docker registries that are publicly available. Let us know if you have any other questions, Jim On Mon, Apr 18, 2016 at 1:41 PM, sangeeus <sangeetha081315(a)gmail.com> wrote:
hi, I am pushing jboss/drools-workbench-showcase docker image to |
|
|
|
Java Buildpack v3.7
Ben Hale <bhale@...>
I'm pleased to announce the release of the java-buildpack, version 3.7. This release contains the addition of a number of frameworks and updates to the dependencies.
* Container Certificate Trust Store Framework * Ruxit APM Framework (via Alois Mayr) * Dynatrace Framework Enabled (via Mike Villiger) * Tomcat Configuration Extension Point (via Violeta Georgieva) * Improved Debug Framework Documentation (via Mike Youngstrom) * Improved Configuration Diagnostics (via Yann Robert) For a more detailed look at the changes in 3.7, please take a look at the commit log[1]. Packaged versions of the buildpack, suitable for use with create-buildpack and update-buildpack, can be found attached to the release. -Ben Hale Cloud Foundry Java Experience ## Packaged Dependencies AppDynamics 4.1.8_5 Dynatrace 6.3.0_1305 GemFire Modules Tomcat7 8.2.0 GemFire Modules 8.2.0 GemFire Security 8.2.0 GemFire 8.2.0 Groovy 2.4.6 JRebel 6.4.2 Log4j API 2.1.0 Log4j Core 2.1.0 Log4j Jcl 2.1.0 Log4j Jul 2.1.0 Log4j Slf4j 2.1.0 MariaDB JDBC 1.4.2 Memory Calculator (mountainlion) 2.0.2_RELEASE Memory Calculator (precise) 2.0.2_RELEASE Memory Calculator (trusty) 2.0.2_RELEASE New Relic Agent 3.27.0 OpenJDK JRE (mountainlion) 1.8.0_91 OpenJDK JRE (precise) 1.8.0_73 OpenJDK JRE (trusty) 1.8.0_91 Play Framework JPA Plugin 1.10.0_RELEASE PostgreSQL JDBC 9.4.1208 RedisStore 1.2.0_RELEASE Ruxit 1.91.271 SLF4J API 1.7.7 SLF4J JDK14 1.7.7 Spring Auto-reconfiguration 1.10.0_RELEASE Spring Boot CLI 1.3.3_RELEASE Spring Boot Container Customizer 1.0.0_RELEASE Tomcat Access Logging Support 2.5.0_RELEASE Tomcat Lifecycle Support 2.5.0_RELEASE Tomcat Logging Support 2.5.0_RELEASE Tomcat 8.33.0 YourKit Profiler (mountainlion) 2016.02.34 YourKit Profiler (precise) 2016.02.33 YourKit Profiler (trusty) 2016.02.34 [1]: https://github.com/cloudfoundry/java-buildpack/compare/v3.6...v3.7 |
|
|
|
Re: Apps and DEA Runner Affinity
Alexander Lomov <alexander.lomov@...>
The answer is “yes”. You can divide DEAs by stacks and then specify a stack during app deployment.
toggle quoted message
Show quoted text
On Apr 21, 2016, at 7:05 PM, Mohamed, Owais <Owais.Mohamed(a)covisint.com<mailto:Owais.Mohamed(a)covisint.com>> wrote:
Hi, We have not moved over to DIEGO yet. In the DEA execution world, is there anyway to segment Apps such that certain apps go to a particular set of DEA agents and certain other apps go to another set of DEA agents? This will help us select an appropriate VM flavor for the DEA Agent based on the types of apps being run by the DEA Agent. Regards, Owais |
|
|
|
Apps and DEA Runner Affinity
Owais Mohamed
Hi,
We have not moved over to DIEGO yet. In the DEA execution world, is there anyway to segment Apps such that certain apps go to a particular set of DEA agents and certain other apps go to another set of DEA agents? This will help us select an appropriate VM flavor for the DEA Agent based on the types of apps being run by the DEA Agent. Regards, Owais |
|
|