Date   

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
<https://github.com/hashicorp/consul/issues/1212> issue that is more
frequent with consul 0.5.x servers compared to 0.6.x servers.

→ Q1: Are you planning to upgrade the consul version used in CF and Diego
from 0.5.2 to 0.6.4 in near future?


Also, people recommend the following settings to mitigate the issue.

"dns_config": {
"allow_stale": true,
"node_ttl": "5s",
"service_ttl": {
"*": "5s"
}
}

I’ll try those and keep you updated with the results next week.
Unfortunately, I’ll have to fork the consul-release
<https://github.com/cloudfoundry-incubator/consul-release> because those
settings are also hardwired to their default
<https://github.com/cloudfoundry-incubator/consul-release/blob/master/src/confab/config/consul_config_definer.go#L13-L35> in
confab.

→ Q2: Are you planing so update of confab so that people can tweak their
consul settings directly from BOSH deployment?


Regarding my previous remark about properly configuring “
skip_leave_on_interrupt” and “leave_on_terminate” in confab, I understand
that the default value of “true” for “leave_on_terminate” might be
necessary to properly scale down a consul cluster with BOSH.

But I saw today that skip_leave_on_interrupt will default to true
<https://github.com/hashicorp/consul/blob/master/CHANGELOG.md> for consul
*servers* in the upcoming version 0.7.0. Currently, this config is
hard-wired to its default value of “false” in confab.

→ Q3: Are you planning to update this “skip_leave_on_interrupt” config in
confab?


/Benjamin


Le 14 avr. 2016 à 17:00, Benjamin Gandon <benjamin(a)gandon.org> a écrit :

Thank you Amit for your answer.


I ran again in the “all-consuls-go-crazy” situation today, as quite every
day actually. As soon as they start this flapping membership issue, the
whole cf+diego deployment goes down.

Before I delete the content of the persistent storage, when I restart the
consul servers, they don’t manage to elect a leader :
https://gist.github.com/bgandon/08707466324be7c9a093a56fd95a64e4

After I delete */var/vcap/store/consul_agent* on all 3 consul servers, a
consul leader is properly elected, but the cluster rapidly re-start
flapping again with failures suspicions, missing acks, and timeouts :
https://gist.github.com/bgandon/cab53c22da66b24beff46389ba7f0bdc

And at that time, the load of the bosh-ite VM goes up to 280+ and
everything becomes very unresponsive.

How is it possible to bring the consul cluster in a healthy state again? I
don’t want to reboot the bosh-lite VM and recreate all deployments with
cloudchecks anymore.


/Benjamin


Le 11 avr. 2016 à 22:40, Amit Gupta <agupta(a)pivotal.io> a écrit :

Orchestrating a raft cluster in a way that requires no manual intervention
is incredibly difficult. We write the PID file late for a specific reason:

https://www.pivotaltracker.com/story/show/112018069

For dealing with wedged states like the one you encountered, we have some
recommendations in the documentation:

https://github.com/cloudfoundry-incubator/consul-release/#disaster-recovery

We have acceptance tests we run in CI that exercise rolling a 3 node
cluster, so if you hit a failure it would be useful to get logs if you have
any.

Cheers,
Amit

On Mon, Apr 11, 2016 at 9:38 AM, Benjamin Gandon <benjamin(a)gandon.org>
wrote:

Actually, doing some further tests, I realize a mere 'join' is definitely
not enough.

Instead, you need to restore the raft/peers.json on each one of the 3
consul server nodes:

monit stop consul_agent
echo '["10.244.0.58:8300","10.244.2.54:8300","10.244.0.54:8300"]' >
/var/vcap/store/consul_agent/raft/peers.json


And make sure you start them quite at the same time with “monit start
consul_agent”

So this advocates a strongly for setting *skip_leave_on_interrupt=true*
and *leave_on_terminate=false* in confab, because loosing the peers.json
is really something we don't want in our CF deployments!

/Benjamin


Le 11 avr. 2016 à 18:15, Benjamin Gandon <benjamin(a)gandon.org> a écrit :

Hi cf devs,


I’m running a CF deployment with redundancy, and I just experienced my
consul servers not being able to elect any leader.
That’s a VERY frustrating situation that keeps the whole CF deployment
down, until you get a deeper understanding of consul, and figure out they
just need a silly manual 'join' so that they get back together.

But that was definitely not easy to nail down because at first look, I
could just see monit restarting the “agent_ctl” every 60 seconds because
confab was not writing the damn PID file.


More specifically, the 3 consul servers (i.e. consul_z1/0, consul_z1/1
and consul_z2/0) had properly left oneanother uppon a graceful shutdown.
This state was persisted in /var/vcap/store/raft/peers.json being “null” on
each one of them, so they would not get back together on restart. A manual
'join' was necessary. But it took me hours to get there because I’m no
expert with consul.

And until the 'join' is made, VerifySynced() was negative in confab, and
monit was constantly starting and stopping it every 60 seconds. But once
you step back, you realize confab was actually waiting for the new leader
to be elected before it writes the PID file. Which is questionable.

So, I’m asking 3 questions here:

1. Does writing the PID file in confab *that* late really makes sense?
2. Could someone please write some minimal documentation about confab, at
least to tell what it is supposed to do?
3. Wouldn’t it be wiser that whenever any of the consul servers is not
here, then the cluster gets unhealthy?

With this 3rd question, I mean that even on a graceful TERM or INT, no
consul server should not perform any graceful 'leave'. With this different
approach, then they would properly be back up even when performing a
complete graceful restart of the cluster.

This can be done with those extra configs from the “confab” wrapper:

{
"skip_leave_on_interrupt": true,
"leave_on_terminate": false
}

What do you guys think of it?


/Benjamin




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
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 " -
https://docs.cloudfoundry.org/loggregator/architecture.html

In that document, metron_agent can forward metrics or logs to N doppler.

But i don't know how to do it.

Would you let me know how to configure it at cf.yml.

Thanks & Regards


Re: pg gem and ruby app deployment issues

John Shahid
 

Hi Evgeniy,

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,

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 ***


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,

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.
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


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,

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.
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!

On Thu, Apr 21, 2016 at 3:07 PM, Dieu Cao <dcao(a)pivotal.io> wrote:

Congrats on the release! Very exciting stuff.

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.
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: Java Buildpack v3.7

Dieu Cao <dcao@...>
 

Congrats on the release! Very exciting stuff.

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.
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: 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,

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
cloudfoundry
from my CLI.
This is the command,

cf push workbench -o jboss/drools-workbench-showcase:6.2.0.Final
But I get an error
Failed to talk to docker registry: Get http://registry-1.docker.io/v2/:
net/http: request canceled while waiting for connection.

How to add docker insecure registry to cloud foundry.

This image works fine in my local



--
View this message in context:
http://cf-dev.70369.x6.nabble.com/pushing-docker-image-to-CF-tp4649.html
Sent from the CF Dev mailing list archive at Nabble.com.


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.

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


bosh-init with external s3 blobstore

Anuj Jain <anuj17280@...>
 

Hi,

I want to use external s3 compatible blobstore with bosh-init deployment
- for that I provided the required configuration in bosh-init.yml manifest
file (mentioned blobstore config below) - now after deploying bosh-init - I
can upload the releases to s3 compatible blobstore - but when I am trying
to deploy cloud foundry I am getting errors when deployment is trying to
fetch the blobs form blobstore (see the error below)

I think - I might need to do some changes in bosh-init manifest
properties - but not sure what exactly.

Note: I tried blobstore: *blobstore in bosh-init properties without any
luck.

Blobstore config:

blobstore: &blobstore
provider: s3
bucket_name: bucketname
access_key_id: keyid
secret_access_key: my_secret
use_ssl: true
ssl_port: 443
port: 443
director: {user: director, password: *svcs_password}
agent: {user: agent, password: *svcs_password}
s3_force_path_style: true
host: my_s3_host_name

properties:
blobstore: {provider: local, path: /var/vcap/micro_bosh/data/cache}


============ Error
Failed compiling packages >
buildpack_java/d65c2d20fc067c9995c18d195e0ff117ea9202c0: Action Failed
get_task: Task c9ab7ba8-c034-4c18-51b4-1a04a3b014ae result: Compiling
package buildpack_java: Fetching package buildpack_java: Fetching package
blob f95e361f-ab27-4146-a2a0-a11f54fbef66: Getting blob from inner
blobstore: Getting blob from inner blobstore: Shelling out to
bosh-blobstore-s3 cli: Running command: 'bosh-blobstore-s3 -c
/var/vcap/bosh/etc/blobstore-s3.json get
f95e361f-ab27-4146-a2a0-a11f54fbef66
/var/vcap/data/tmp/bosh-blobstore-externalBlobstore-Get733130718', stdout:
'', stderr: '2016/04/21 12:11:17 performing operation get: AccessDenied:
Access Denied

- Anuj


Re: Question regarding simple application statistics

Graham Bleach
 

On 20 April 2016 at 19:21, Don Nelson <dieseldonx(a)gmail.com> wrote:

Oops, replied too quickly. Looks like that's an internal site. Is there
any external-facing documentation equivalence?
Can you clarify what you think is an internal site?

Both the links Dan sent;
http://apidocs.cloudfoundry.org/234/apps/get_detailed_stats_for_a_started_app.html
and http://apidocs.cloudfoundry.org/234/apps/retrieve_a_particular_app.html
are public and return content to me.

Regards,
Graham


Re: Question regarding simple application statistics

Don Nelson
 

Oops, replied too quickly. Looks like that's an internal site. Is there any external-facing documentation equivalence?