Date   

Re: [vcap-dev] Java OOM debugging

Lari Hotari <Lari@...>
 

This Java native memory leak debugging war story from a Twitter engineer
is very interesting:
http://www.evanjones.ca/java-native-leak-bug.html
Tweet is https://twitter.com/epcjones/status/603295445067014144 .

It seems to be very important to check all locations where
GzipInputStream (and other InflaterInputStream impl) and
GzipOutputStream (and other DeflaterOutputStream impl) are used.

I assume that an InputStream opened from a resource URL originating from
a Jar file could also leak native memory.
(ClassLoader.getResource(...).openStream()). This makes it a very common
source of native memory problems in Java.

It could be a coincidence, but Tomcat 8.0.20 seems to have changes in
this area:
https://github.com/apache/tomcat/commit/6e5420c67fbad81973d888ad3701a392fac4fc71
(I linked to that commit in my email on May 14).

Lari

On 15-05-14 10:23 AM, Daniel Jones wrote:
Hi Lari,

Thanks again for your input. Have you seen this problem with versions
of Tomcat before 8.0.20?

David and I think we've narrowed down the issue to a change from using
Tomcat 8.0.18 to 8.0.21. We're running more tests and collaborating
with Pivotal support. We also noticed that non-prod versions of our
apps were taking longer to crash, so it would seem to be
activity-related at least.

Do you know how Tomcat's APR/NIO memory gets allocated? Is there a way
of telling from pmap whether pages are being used for NIO buffers or
by the APR?

I wonder if the other folks that have reported CF out of memory errors
with later versions of Tomcat are seeing slow creeps in native memory
consumption?

On Mon, May 11, 2015 at 2:19 PM, Lari Hotari <Lari(a)hotari.net
<mailto:Lari(a)hotari.net>> wrote:


fyi. Tomcat 8.0.20 might be consuming more memory than 8.0.18:
https://github.com/cloudfoundry/java-buildpack/issues/166#issuecomment-94517568

Other things we’ve tried:

- We set verbose garbage collection to verify there was
no memory size issues within the JVM. There wasn’t.

- We tried setting minimum memory for native, it had no
effect. The container still gets killed

- We tried adjusting the ‘memory heuristics’ so that
they added up to 80 rather than 100. This had the effect of
causing a delay in the container being killed. However it still
was killed.
I think adjusting memory heuristics so that they add up to 80
doesn't make a difference because the values aren't percentages.
The values are proportional weighting values used in the memory
calculation:
https://github.com/grails-samples/java-buildpack/blob/b4abf89/docs/jre-oracle_jre.md#memory-calculation

I found out that the only way to reserve "unused" memory is to set
a high value for the native memory lower bound in the
memory_sizes.native setting of config/open_jdk_jre.yml .
Example:
https://github.com/grails-samples/java-buildpack/blob/22e0f6a/config/open_jdk_jre.yml#L25



This seems like classic memory leak behaviour to me.
In my case it wasn't a classical Java memory leak, since the Java
application wasn't leaking memory. I was able to confirm this by
getting some heap dumps with the HeapDumpServlet
(https://github.com/lhotari/java-buildpack-diagnostics-app/blob/master/src/main/groovy/io/github/lhotari/jbpdiagnostics/HeapDumpServlet.groovy)
and analyzing them.

In my case the JVM's RSS memory size is slowly growing. It
probably is some kind of memory leak since one process I've been
monitoring now is very close to the memory limit. The uptime is
now almost 3 weeks.

Here is the latest diff of the meminfo report.
https://gist.github.com/lhotari/ee77decc2585f56cf3ad#file-meminfo_diff_example2-txt

From a Java perspective this isn't classical. The JVM heap isn't
filling up. The problem is that RSS size is slowly growing and
will eventually cause the Java process to cross the memory
boundary so that the process gets kill by the Linux kernel cgroups
OOM killer.

RSS size might be growing because of many reasons. I have been
able to slow down the growth by doing the various MALLOC_ and JVM
parameter tuning (-XX:MinMetaspaceExpansion=1M
-XX:CodeCacheExpansionSize=1M). I'm able to get a longer uptime,
but the problem isn't solved.

Lari



On 15-05-11 06:41 AM, Head-Rapson, David wrote:

Thanks for the continued advice.



We’ve hit on a key discovery after yet another a soak test this
weekend.

- When we deploy using Tomcat 8.0.18 we don’t see the issue

- When we deploy using Tomcat 8.0.20 (same app version,
same CF space, same services bound, same JBP code version, same
JRE version, running at the same time), we see the crashes
occurring after just a couple of hours.



Ideally we’d go ahead with the memory calculations you mentioned
however we’re stuck on lucid64 because we’re using Pivotal CF
1.3.x & we’re having upgrade issues to 1.4.x.

So we’re not able to adjust MALLOC_ARENA_MAX, nor are we able to
view RSS in pmap as you describe



Other things we’ve tried:

- We set verbose garbage collection to verify there was
no memory size issues within the JVM. There wasn’t.

- We tried setting minimum memory for native, it had no
effect. The container still gets killed

- We tried adjusting the ‘memory heuristics’ so that
they added up to 80 rather than 100. This had the effect of
causing a delay in the container being killed. However it still
was killed.



This seems like classic memory leak behaviour to me.



*From:*Lari Hotari [mailto:lari.hotari(a)sagire.fi] *On Behalf Of
*Lari Hotari
*Sent:* 08 May 2015 16:25
*To:* Daniel Jones; Head-Rapson, David
*Cc:* cf-dev(a)lists.cloudfoundry.org
<mailto:cf-dev(a)lists.cloudfoundry.org>
*Subject:* Re: [Cf-dev] [vcap-dev] Java OOM debugging




For my case, it turned out to be essential to reserve enough
memory for "native" in the JBP. For the 2GB total memory, I set
the minimum to 330M. With that setting I have been able to get
over 2 weeks up time by now.

I mentioned this in my previous email:

The workaround for that in my case was to add a native key under
memory_sizes in open_jdk_jre.yml and set the minimum to 330M
(that is for a 2GB total memory).
see example
https://github.com/grails-samples/java-buildpack/blob/22e0f6a/config/open_jdk_jre.yml#L25
that was how I got the app I'm running on CF to stay within the
memory bounds. I'm sure there is now also a way to get the keys
without forking the buildpack. I could have also adjusted the
percentage portions, but I wanted to set a hard minimum for this
case.


I've been trying to get some insight by diffing the reports
gathered from the meminfo servlet
https://github.com/lhotari/java-buildpack-diagnostics-app/blob/master/src/main/groovy/io/github/lhotari/jbpdiagnostics/MemoryInfoServlet.groovy
<https://github.com/lhotari/java-buildpack-diagnostics-app/blob/master/src/main/groovy/io/github/lhotari/jbpdiagnostics/MemoryInfoServlet.groovy>

Here is such an example of a diff:
https://gist.github.com/lhotari/ee77decc2585f56cf3ad#file-meminfo_diff_example-txt

meminfo has pmap output included to get the report of the memory
map of the process. I have just noticed that most of the memory
has already been mmap:ed from the OS and it's just growing in RSS
size. For example:
< 00000000a7600000 1471488 1469556 1469556 rw--- [ anon ]
> 00000000a7600000 1471744 1470444 1470444 rw--- [ anon ]

The pmap output from lucid64 didn't include the RSS size, so you
have to use cflinuxfs2 for this. It's also better because of
other reasons. The glibc in lucid64 is old and has some bugs
around the MALLOC_ARENA_MAX.

I was manually able to estimate the maximum size of the RSS size
of what the Java process will consume by simply picking the large
anon-blocks from the pmap report and calculating those blocks by
the allocated virtual size (VSS).
Based on this calculation, I picked the minimum of 330M for
"native" in open_jdk_jre.yml as I mentioned before.

It looks like these rows are for the Heap size:
< 00000000a7600000 1471488 1469556 1469556 rw--- [ anon ]
> 00000000a7600000 1471744 1470444 1470444 rw--- [ anon ]

It looks like the JVM doesn't fully allocate that block in RSS
initially and most of the growth of RSS size comes from that in
my case. In your case, it might be something different.

I also added a servlet for getting glibc malloc_info statistics
in XML format (). I haven't really analysed that information
because of time constraints and because I don't have a pressing
problem any more. btw. The malloc_info XML report is missing some
key elements, that has been added in later glibc versions
(https://github.com/bminor/glibc/commit/4d653a59ffeae0f46f76a40230e2cfa9587b7e7e).

If killjava.sh never fires and the app crashed with Warden out of
memory errors, then I believe it's the kernel's cgroups OOM
killer that has killed the container processes. I have found this
location where Warden oom notifier gets the OOM notification event:
https://github.com/cloudfoundry/warden/blob/ad18bff/warden/lib/warden/container/features/mem_limit.rb#L70
This is the oom.c source code:
https://github.com/cloudfoundry/warden/blob/ad18bff7dc56acbc55ff10bcc6045ebdf0b20c97/warden/src/oom/oom.c
. It reads the cgroups control files and receives events from the
kernel that way.

I'd suggest that you use pmap for the Java process after it has
started and calculate the maximum RSS size by calculating the VSS
size of the large anon blocks instead of RSS for the blocks that
the Java process has reserved for it's different memory areas (I
think you shouldn't . You should discard adding VSS for the
CompressedClassSpaceSize block.
After this calculation, add enough memory to the "native"
parameter in JBP until the RSS size calculated this way stays
under the limit.
That's the only "method" I have come up by now.

It might be required to have some RSS space allocated for any
zip/jar files read by the Java process. I think that Java uses
mmap files for zip file reading by default and that might go on
top of all other limits.
To test this theory, I'd suggest testing by adding
-Dsun.zip.disableMemoryMapping=true system property setting to
JAVA_OPTS. That disables the native mmap for zip/jar file
reading. I haven't had time to test this assumption.

I guess the only way to understand how Java allocates memory is
to look at the source code.
from http://openjdk.java.net/projects/jdk8u/ , the instructions
to get the source code of JDK 8:
hg clone http://hg.openjdk.java.net/jdk8u/jdk8u;cd jdk8u;sh
get_source.sh
This tool is really good for grepping and searching the source
code: http://geoff.greer.fm/ag/ <http://geoff.greer.fm/ag/>
On Ubuntu it's in silversearcher-ag package, "apt-get install
silversearcher-ag" and on MacOSX brew it's "brew install
the_silver_searcher".
This alias is pretty useful:
alias codegrep='ag --color --group --pager less -C 5'
Then you just search for the correct location in code by starting
with the tokens you know about:
codegrep MaxMetaspaceSize
this gives pretty good starting points in looking how the JDK
allocates memory.

So the JDK source code is only a few commands away.

It would be interesting to hear more about this if someone has
the time to dig in to this. This is about how far I got and I
hope sharing this information helps someone continue. :)


Lari
github/twitter: lhotari

On 15-05-08 10:02 AM, Daniel Jones wrote:

Hi Lari et al,



Thanks for your help Lari.



David and I are pairing on this issue, and we're yet to
resolve it. We're in the process of creating a repeatable
test case (our most crashy app makes calls to external
services that need mocking), but in the meantime, here's what
we've seen.



Between Java Buildpack commit e89e546 and 17162df, we see
apps crashing with Warden out of memory errors. killjava.sh
never fires, and this has led us to believe that the kernel
is shooting a cgroup process in the head after the cgroup
oversteps its memory limit. We cannot find any evidence of
the OOM killer firing in any logs, but we may not be looking
in the right place.



The JBP is setting heap to be 70%, metaspace to be 15% (with
max set to the same as initial), 5% for "stack", 5% for
"normalised stack" and 10% for "native". We do not understand
why this adds up to 105%, but haven't looked into the JBP
algorithm yet. Any pointers on what "normalised stack" is
would be much appreciated, as this doesn't appear in the list
of heuristics supplied via app env.



Other team members tried applying the same settings that you
suggested - thanks for this. Apps still crash with these
settings, albeit less frequently.



After reading the blog you linked to
(http://java.dzone.com/articles/java-8-permgen-metaspace) we
wondered whether the increased /reserved /metaspace claimed
after metaspace GC might be causing a problem; however we
reused the test code to create a metaspace leak in a CF app
and saw metaspace GCs occur correctly, and memory usage never
grow over MaxMetaspaceSize. This figures, as the committed
metaspace is still less than MaxMetaspaceSize, and the
reserved appears to be whatever RAM is free across the whole DEA.



We noted that an Oracle blog
(https://blogs.oracle.com/poonam/entry/about_g1_garbage_collector_permanent)
mentions that the metaspace size parameters are approximate.
We're currently wondering if native allocations by Tomcat
(APR, NIO) are taking up more container memory, and so when
the metaspace fills, it's creeping slightly over the limit
and triggering the kernel's OOM killer.



Any suggestions would be much appreciated. We've tried to
resist tweaking heuristics blindly, but are running out of
options as we're struggling to figure out how the Java
process is using /committed/ memory. pmap seems to show
virtual memory, and so it's hard to see if things like the
metaspace or NIO ByteBuffers are nabbing too much and trigger
the kernel's OOM killer.



Thanks for all your help,



Daniel Jones & David Head-Rapson



On Wed, Apr 29, 2015 at 8:07 PM, Lari Hotari <Lari(a)hotari.net
<mailto:Lari(a)hotari.net>> wrote:

Hi,

I created a few tools to debug OOM problems since the
application I was responsible for running on CF was failing
constantly because of OOM problems. The problems I had,
turned out not to be actual memory leaks in the Java
application.

In the "cf events appname" log I would get entries like this:
2015-xx-xxTxx:xx:xx.00-0400 app.crash appname
index: 1, reason: CRASHED, exit_description: out of memory,
exit_status: 255

These type of entries are produced when the container goes
over it's memory resource limits. It doesn't mean that there
is a memory leak in the Java application. The container gets
killed by the Linux kernel oom killer
(https://github.com/cloudfoundry/warden/blob/master/warden/README.md#limit-handle-mem-value)
based on the resource limits set to the warden container.

The memory limit is specified in number of bytes. It is
enforced using the control group associated with the
container. When a container exceeds this limit, one or more
of its processes will be killed by the kernel. Additionally,
the Warden will be notified that an OOM happened and it
subsequently tears down the container.

In my case it never got killed by the killjava.sh script that
gets called in the java-buildpack when an OOM happens in Java.

This is the tool I built to debug the problems:
https://github.com/lhotari/java-buildpack-diagnostics-app
I deployed that app as part of the forked buildpack I'm using.
Please read the readme about what it's limitations are. It
worked for me, but it might not work for you. It's opensource
and you can fork it. :)

There is a solution in my toolcase for creating a heapdump
and uploading that to S3:
https://github.com/lhotari/java-buildpack-diagnostics-app/blob/master/src/main/groovy/io/github/lhotari/jbpdiagnostics/HeapDumpServlet.groovy
The readme explains how to setup Amazon S3 keys for this:
https://github.com/lhotari/java-buildpack-diagnostics-app#amazon-s3-setup
Once you get a dump, you can then analyse the dump in a java
profiler tool like YourKit.

I also have a solution that forks the java-buildpack modifies
killjava.sh and adds a script that uploads the heapdump to S3
in the case of OOM:
https://github.com/lhotari/java-buildpack/commit/2d654b80f3bf1a0e0f1bae4f29cb85f56f5f8c46

In java-buildpack-diagnostics-app I have also other tools for
getting Linux operation system specific memory information,
for example:

https://github.com/lhotari/java-buildpack-diagnostics-app/blob/master/src/main/groovy/io/github/lhotari/jbpdiagnostics/MemoryInfoServlet.groovy
https://github.com/lhotari/java-buildpack-diagnostics-app/blob/master/src/main/groovy/io/github/lhotari/jbpdiagnostics/MemorySmapServlet.groovy
https://github.com/lhotari/java-buildpack-diagnostics-app/blob/master/src/main/groovy/io/github/lhotari/jbpdiagnostics/MallocInfoServlet.groovy

These tools are handy for looking at details of the Java
process RSS memory usage growth.

There is also a solution for getting ssh shell access inside
your application with tmate.io <http://tmate.io>:
https://github.com/lhotari/java-buildpack-diagnostics-app/blob/master/src/main/groovy/io/github/lhotari/jbpdiagnostics/TmateSshServlet.groovy
(this version is only compatible with the new "cflinuxfs2" stack)

It looks like there are serious problems on CloudFoundry with
the memory sizing calculation. An application that doesn't
have a OOM problem will get killed by the oom killer because
the Java process will go over the memory limits.
I filed this issue:
https://github.com/cloudfoundry/java-buildpack/issues/157 ,
but that might not cover everything.

The workaround for that in my case was to add a native key
under memory_sizes in open_jdk_jre.yml and set the minimum to
330M (that is for a 2GB total memory).
see example
https://github.com/grails-samples/java-buildpack/blob/22e0f6a/config/open_jdk_jre.yml#L25
that was how I got the app I'm running on CF to stay within
the memory bounds. I'm sure there is now also a way to get
the keys without forking the buildpack. I could have also
adjusted the percentage portions, but I wanted to set a hard
minimum for this case.

It was also required to do some other tuning.

I added this to JAVA_OPTS:
-XX:CompressedClassSpaceSize=256M
-XX:InitialCodeCacheSize=64M -XX:CodeCacheExpansionSize=1M
-XX:CodeCacheMinimumFreeSpace=1M
-XX:ReservedCodeCacheSize=200M -XX:MinMetaspaceExpansion=1M
-XX:MaxMetaspaceExpansion=8M -XX:MaxDirectMemorySize=96M
while trying to keep the Java process from growing in RSS
memory size.

The memory overhead of a 64 bit Java process on Linux can be
reduced by specifying these environment variables:

stack: cflinuxfs2
.
.
.
env:
MALLOC_ARENA_MAX: 2
MALLOC_MMAP_THRESHOLD_: 131072
MALLOC_TRIM_THRESHOLD_: 131072
MALLOC_TOP_PAD_: 131072
MALLOC_MMAP_MAX_: 65536

MALLOC_ARENA_MAX works only on cflinuxfs2 stack (the lucid64
stack has a buggy version of glibc).

explanation about MALLOC_ARENA_MAX from Heroku:
https://devcenter.heroku.com/articles/tuning-glibc-memory-behavior
some measurement data how it reduces memory consumption:
https://devcenter.heroku.com/articles/testing-cedar-14-memory-use

I have created a PR to add this to CF java-buildpack:
https://github.com/cloudfoundry/java-buildpack/pull/160

I also created an issues
https://github.com/cloudfoundry/java-buildpack/issues/163 and
https://github.com/cloudfoundry/java-buildpack/pull/159 .

I hope this information helps others struggling with OOM
problems in CF.
I'm not saying that this is a ready made solution just for
you. YMMV. It worked for me.

-Lari




On 15-04-29 10:53 AM, Head-Rapson, David wrote:

Hi,

I’m after some guidance on how to get profile Java apps
in CF, in order to get to the bottom of memory issues.

We have an app that’s crashing every few hours with OOM
error, most likely it’s a memory leak.

I’d like to profile the JVM and work out what’s eating
memory, however tools like yourkit require connectivity
INTO the JVM server (i.e. the warden container), either
via host / port or via SSH.

Since warden containers cannot be connected to on ports
other than for HTTP and cannot be SSHd to, neither of
these works for me.



I tried installed a standalone JDK onto the warden
container, however as soon as I ran ‘jmap’ to invoke the
dump, warden cleaned up the container – most likely for
memory over-consumption.



I had previously found a hack in the Weblogic buildpack
(https://github.com/pivotal-cf/weblogic-buildpack/blob/master/docs/container-wls-monitoring.md)
for modifying the start script which, when used with
–XX:HeapDumpOnOutOfMemoryError, should copy any heapdump
files to a file share somewhere. I have my own custom
buildpack so I could use something similar.

Has anyone got a better solution than this?



We would love to use newrelic / app dynamics for this
however we’re not allowed. And I’m not 100% certain they
could help with this either.



Dave



The information transmitted is intended for the person or
entity to which it is addressed and may contain
confidential, privileged or copyrighted material. If you
receive this in error, please contact the sender and
delete the material from any computer. Fidelity only
gives information on products and services and does not
give investment advice to retail clients based on
individual circumstances. Any comments or statements made
are not necessarily those of Fidelity. All e-mails may be
monitored. FIL Investments International (Reg.
No.1448245), FIL Investment Services (UK) Limited (Reg.
No. 2016555), FIL Pensions Management (Reg. No. 2015142)
and Financial Administration Services Limited (Reg. No.
1629709) are authorised and regulated in the UK by the
Financial Conduct Authority. FIL Life Insurance Limited
(Reg No. 3406905) is authorised in the UK by the
Prudential Regulation Authority and regulated in the UK
by the Financial Conduct Authority and the Prudential
Regulation Authority. Registered offices at Oakhill
House, 130 Tonbridge Road, Hildenborough, Tonbridge, Kent
TN11 9DZ.

--
You received this message because you are subscribed to
the Google Groups "Cloud Foundry Developers" group.
To view this discussion on the web visit
https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/DFFA4ADB9F3BC34194429921AB329336408CAB04%40UKFIL7006WIN.intl.intlroot.fid-intl.com
<https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/DFFA4ADB9F3BC34194429921AB329336408CAB04%40UKFIL7006WIN.intl.intlroot.fid-intl.com?utm_medium=email&utm_source=footer>.
To unsubscribe from this group and stop receiving emails
from it, send an email to
vcap-dev+unsubscribe(a)cloudfoundry.org
<mailto:vcap-dev+unsubscribe(a)cloudfoundry.org>.




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





--

Regards,



Daniel Jones

EngineerBetter.com





--
Regards,

Daniel Jones
EngineerBetter.com


metron_agent.deployment

Diego Lapiduz <diego@...>
 

Hi all,

I've been trying to figure out an issue here while upgrading to 210 from
208.

It seems that a requirement has been added to the deployment manifests for
a "metron_agent.deployment" property but I can't find it anywhere in the
cf-release manifests.

From what I can tell the only manifest with that setting is
https://github.com/cloudfoundry/cf-release/blob/master/example_manifests/minimal-aws.yml#L327
.

Is there a place to look for canonical manifests other than cf-release?
Should I just rely on the release notes?

I just added that property to cf-properties.yml and seems to work fine.

Thanks for understanding as we are going through our first couple of big
upgrades.

Cheers,
Diego


Re: metron_agent.deployment

Ivan Sim <ivans@...>
 

On Tue, May 26, 2015 at 7:40 PM, Diego Lapiduz <diego(a)lapiduz.com> wrote:

Hi all,

I've been trying to figure out an issue here while upgrading to 210 from
208.

It seems that a requirement has been added to the deployment manifests for
a "metron_agent.deployment" property but I can't find it anywhere in the
cf-release manifests.

From what I can tell the only manifest with that setting is
https://github.com/cloudfoundry/cf-release/blob/master/example_manifests/minimal-aws.yml#L327
.

Is there a place to look for canonical manifests other than cf-release?
Should I just rely on the release notes?

I just added that property to cf-properties.yml and seems to work fine.

Thanks for understanding as we are going through our first couple of big
upgrades.

Cheers,
Diego

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

--
Ivan Sim


Re: metron_agent.deployment

Diego Lapiduz <diego@...>
 

Thanks Ivan! That is exactly what I was looking for.

On Tue, May 26, 2015 at 10:47 PM, Ivan Sim <ivans(a)activestate.com> wrote:

For all the loggregator processes, you will be able to find their
configuration properties in their respective spec and ERB files in the loggregator
repository
<https://github.com/cloudfoundry/loggregator/tree/develop/bosh/jobs>[1].
In your case, the metron_agent.deployment property is seen here
<https://github.com/cloudfoundry/loggregator/blob/27490d3387566f42fb71bab3dc760ca1b5c1be6d/bosh/jobs/metron_agent/spec#L47>
[2]

[1] https://github.com/cloudfoundry/loggregator/tree/develop/bosh/jobs
[2]
https://github.com/cloudfoundry/loggregator/blob/27490d3387566f42fb71bab3dc760ca1b5c1be6d/bosh/jobs/metron_agent/spec#L47
.

On Tue, May 26, 2015 at 7:40 PM, Diego Lapiduz <diego(a)lapiduz.com> wrote:

Hi all,

I've been trying to figure out an issue here while upgrading to 210 from
208.

It seems that a requirement has been added to the deployment manifests
for a "metron_agent.deployment" property but I can't find it anywhere in
the cf-release manifests.

From what I can tell the only manifest with that setting is
https://github.com/cloudfoundry/cf-release/blob/master/example_manifests/minimal-aws.yml#L327
.

Is there a place to look for canonical manifests other than cf-release?
Should I just rely on the release notes?

I just added that property to cf-properties.yml and seems to work fine.

Thanks for understanding as we are going through our first couple of big
upgrades.

Cheers,
Diego

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


--
Ivan Sim


Re: Release Notes for v210

Dieu Cao <dcao@...>
 

The cf-release v210 was released on May 23rd, 2015
Runtime

- Addressed USN-2617-1 <http://www.ubuntu.com/usn/usn-2617-1/>
CVE-2015-3202
<http://people.canonical.com/~ubuntu-security/cve/2015/CVE-2015-3202.html>
FUSE
vulnerabilities
- Removed fuse binaries from lucid64 rootfs . Apps running on lucid64
stack requiring fuse should switch to cflinuxfs2 details
<https://www.pivotaltracker.com/story/show/95186578>
- fuse binaries updated on cflinuxfs2 rootfs. details
<https://www.pivotaltracker.com/story/show/95177810>
- [Experimental] Work continues on support for Asynchronous Service
Instance Operationsdetails
<https://www.pivotaltracker.com/epic/show/1561148>
- Support for configurable max polling duration
- [Experimental] Work continues on /v3 and Application Process Types
details <https://www.pivotaltracker.com/epic/show/1334418>
- [Experimental] Work continues on Route API details
<https://www.pivotaltracker.com/epic/show/1590160>
- [Experimental] Work continues on Context Path Routes details
<https://www.pivotaltracker.com/epic/show/1808212>
- Work continues on support for Service Keys details
<https://www.pivotaltracker.com/epic/show/1743366>
- Upgrade etcd server to 2.0.1 details
<https://www.pivotaltracker.com/story/show/91070214>
- Should be run as 1 node (for small deployments) or 3 nodes spread
across zones (for HA)
- Also upgrades hm9k dependencies. LAMB client to be upgraded in a
subsequent release. Older client is compatible.
- cloudfoundry/cf-release #670
<https://github.com/cloudfoundry/cf-release/pull/670>: Be able to
specify timeouts for acceptance tests without defaults in the spec.
details <https://www.pivotaltracker.com/story/show/93914198>
- Fix bug where ssl enabled routers were not draining properly details
<https://www.pivotaltracker.com/story/show/94718480>
- cloudfoundry/cloud_controller_ng #378
<https://github.com/cloudfoundry/cf-release/pull/378>: current usage
against the org quota details
<https://www.pivotaltracker.com/story/show/94171010>

UAA

- Bumped to UAA 2.3.0 details
<https://github.com/cloudfoundry/uaa/releases/tag/2.3.0>

Used Configuration

- BOSH Version: 152
- Stemcell Version: 2889
- CC Api Version: 2.27.0

Commit summary
<http://htmlpreview.github.io/?https://github.com/cloudfoundry-community/cf-docs-contrib/blob/master/release_notes/cf-210-whats-in-the-deploy.html>
Compatible Diego Version

- final release 0.1247.0 commit
<https://github.com/cloudfoundry-incubator/diego-release/commit/a122a78eeb344bbfc90b7bcd0fa987d08ef1a5d1>

Manifest and Job Spec Changes

- properties.acceptance_tests.skip_regex added
- properties.app_ssh.host_key_fingerprint added
- properties.app_ssh.port defaults to 2222
- properties.uaa.newrelic added
- properties.login.logout.redirect.parameter.whitelist

On Sat, May 23, 2015 at 9:50 PM, James Bayer <jbayer(a)pivotal.io> wrote:

CVE-2015-3202 details:
http://lists.cloudfoundry.org/pipermail/cf-dev/2015-May/000194.html

CVE-2015-1834 details:
http://lists.cloudfoundry.org/pipermail/cf-dev/2015-May/000195.html

On Sat, May 23, 2015 at 9:41 PM, James Bayer <jbayer(a)pivotal.io> wrote:

please note that this release addresses CVE-2015-3202 and CVE-2015-1834
and we strongly recommend upgrading to this release. more details will be
forthcoming after the long united states holiday weekend.

https://github.com/cloudfoundry/cf-release/releases/tag/v210

*https://github.com/cloudfoundry-community/cf-docs-contrib/wiki/v210
<https://github.com/cloudfoundry-community/cf-docs-contrib/wiki/v210>*

--
Thank you,

James Bayer


--
Thank you,

James Bayer

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


Multiple Availability Zone

iamflying
 

Hi,

I am trying to deploy cf into Openstack with multiple computing nodes.

Computer node 1: has all openstack services running, including cinder
service (az1)
Computer node 2: has computing service only. (az2)

when I deployed the cf, the job VMs has been provisioned into the two
availability zones evenly. When BOSH started to update the job VM (etcd was
provisioned in az2) to create a disk, I got an error "Availability zone
'az2' is invalid".

My question is how to specify the availability zone for VMs and their
persistent disk?

Thanks.


Re: Multiple Availability Zone

John McTeague
 

Try telling BOSH to ignore what AZ the server is in when provisioning disks:

https://github.com/cloudfoundry/bosh/blob/master/release/jobs/director/spec#L395

It will default to cinders default AZ for storage that you have configured.

John

From: cf-dev-bounces(a)lists.cloudfoundry.org [mailto:cf-dev-bounces(a)lists.cloudfoundry.org] On Behalf Of Guangcai Wang
Sent: 27 May 2015 08:23
To: cf-dev(a)lists.cloudfoundry.org
Subject: [cf-dev] Multiple Availability Zone

Hi,
I am trying to deploy cf into Openstack with multiple computing nodes.
Computer node 1: has all openstack services running, including cinder service (az1)
Computer node 2: has computing service only. (az2)
when I deployed the cf, the job VMs has been provisioned into the two availability zones evenly. When BOSH started to update the job VM (etcd was provisioned in az2) to create a disk, I got an error "Availability zone 'az2' is invalid".
My question is how to specify the availability zone for VMs and their persistent disk?
Thanks.

This email is confidential and subject to important disclaimers and conditions including on offers for the purchase or sale of securities, accuracy and completeness of information, viruses, confidentiality, legal privilege, and legal entity disclaimers, available at http://www.jpmorgan.com/pages/disclosures/email


Does DEA have any limitation on the network resources for warden containers a DEA

Shaozhen Ding
 

I have a small environment with old version as 183

It only has one DEA, having couple apps running on that, it suddenly stop
working when deploying apps (staging) without any obvious error and empty
logs.

I took a look at the DEA logs and found this (stackstrace below):

I added one more DEA, then I am able to deploy more apps.

{"timestamp":1432671377.9456468,"message":"instance.start.failed with error
Could not acquire
network","log_level":"warn","source":"Dea::Instance","data":{"attributes":{"prod":false,"executableFile":"deprecated","limits":{"mem":256,"disk":1024,"fds":16384},"cc_partition":"default","console":false,"debug":null,"start_command":null,"health_check_timeout":180,"vcap_application":{"limits":{"mem":256,"disk":1024,"fds":16384},"application_version":"f6a8cfc7-ae71-4cab-90f4-67c2a21a3e8a","application_name":"NewrelicServiceBroker-v1","application_uris":["
newrelic-broker.pcf.inbcu.com
"],"version":"f6a8cfc7-ae71-4cab-90f4-67c2a21a3e8a","name":"NewrelicServiceBroker-v1","space_name":"NewrelicServiceBroker-service-space","space_id":"7c372fd8-9e72-4e0a-b38c-a40024e88b29","uris":["
newrelic-broker.pcf.inbcu.com
"],"users":null},"egress_network_rules":[{"protocol":"all","destination":"
0.0.0.0-255.255.255.255
"}],"instance_index":0,"application_version":"f6a8cfc7-ae71-4cab-90f4-67c2a21a3e8a","application_name":"NewrelicServiceBroker-v1","application_uris":["
newrelic-broker.pcf.inbcu.com"],"application_id":"b7ebe668-1f3f-46c2-88d3-8377824a7dd8","droplet_sha1":"658859369d03874604d0131812f8e6cf9811265a","instance_id":"4abe2c22600449d8aa7beff84c5776fc","private_instance_id":"33991dacb5e94e5dbae9542ff3f218b8f648742aea50432ca1ddb2d1ae4328f4","state":"CRASHED","state_timestamp":1432671377.9454725,"state_born_timestamp":1432671377.6084838,"state_starting_timestamp":1432671377.609722,"state_crashed_timestamp":1432671377.9454768},"duration":0.335908487,"error":"Could
not acquire
network","backtrace":["/var/vcap/packages/dea_next/vendor/cache/warden-dd32a459c99d/em-warden-client/lib/em/warden/client/connection.rb:27:in
`get'","/var/vcap/packages/dea_next/vendor/cache/warden-dd32a459c99d/em-warden-client/lib/em/warden/client.rb:43:in
`call'","/var/vcap/packages/dea_next/lib/container/container.rb:192:in
`call'","/var/vcap/packages/dea_next/lib/container/container.rb:153:in
`block in
new_container_with_bind_mounts'","/var/vcap/packages/dea_next/lib/container/container.rb:229:in
`call'","/var/vcap/packages/dea_next/lib/container/container.rb:229:in
`with_em'","/var/vcap/packages/dea_next/lib/container/container.rb:137:in
`new_container_with_bind_mounts'","/var/vcap/packages/dea_next/lib/container/container.rb:120:in
`block in
create_container'","/var/vcap/packages/dea_next/lib/container/container.rb:229:in
`call'","/var/vcap/packages/dea_next/lib/container/container.rb:229:in
`with_em'","/var/vcap/packages/dea_next/lib/container/container.rb:119:in
`create_container'","/var/vcap/packages/dea_next/lib/dea/starting/instance.rb:520:in
`block in
promise_container'","/var/vcap/packages/dea_next/lib/dea/promise.rb:92:in
`call'","/var/vcap/packages/dea_next/lib/dea/promise.rb:92:in `block in
run'"]},"thread_id":4874360,"fiber_id":23565220,"process_id":28699,"file":"/var/vcap/packages/dea_next/lib/dea/task.rb","lineno":97,"method":"block
in resolve_and_log"}

{"timestamp":1432671655.6220152,"message":"nats.message.received","log_level":"debug","source":"Dea::Nats","data":{"subject":"dea.stop","data":{"droplet":"890cfbde-0957-444e-aa0c-249c0fef42ca"}},"thread_id":4874360,"fiber_id":13477840,"process_id":28699,"file":"/var/vcap/packages/dea_next/lib/dea/nats.rb","lineno":148,"method":"handle_incoming_message"}


api and api_worker jobs fail to bosh update, but monit start OK

Guillaume Berche
 

Hi,

I'm experiencing a weird situation where api and api_worker jobs fail to
update through bosh and end up being reported as "not running". However,
manually running "monit start cloud_controller_ng" (or rebooting the vm),
the faulty jobs starts fine, and bosh deployment proceeds without errors.
Looking at monit logs, it seems that there is an extra monit stop request
for the cc_ng.

Below are detailed traces illustrating the issue.

$ bosh deploy

[..]
Started updating job ha_proxy_z1 > ha_proxy_z1/0 (canary). Done (00:00:39)
Started updating job api_z1 > api_z1/0 (canary). Failed: `api_z1/0' is
not running after update (00:10:44)


When instructing bosh to update the job (in this case only a config
change), we indeed see the bosh agent asking monit to stop jobs, restart
monit itself, start jobs, and then we see the extra stop (at* 12:33:26) *before
the bosh director ends up timeouting and calling the canary failed.

$ less /var/vcap/monit/monit.log

[UTC May 22 12:33:17] info : Awakened by User defined signal 1[UTC
May 22 12:33:17] info : Awakened by the SIGHUP signal[UTC May 22
12:33:17] info : Reinitializing monit - Control file
'/var/vcap/bosh/etc/monitrc'[UTC May 22 12:33:17] info : Shutting
down monit HTTP server[UTC May 22 12:33:18] info : monit HTTP
server stopped[UTC May 22 12:33:18] info : Starting monit HTTP
server at [127.0.0.1:2822][UTC May 22 12:33:18] info : monit HTTP
server started[UTC May 22 12:33:18] info :
'system_897cdb8d-f9f7-4bfa-a748-512489b676e0' Monit reloaded[UTC May
22 12:33:23] info : start service 'consul_agent' on user
request[UTC May 22 12:33:23] info : monit daemon at 1050
awakened[UTC May 22 12:33:23] info : Awakened by User defined
signal 1[UTC May 22 12:33:23] info : 'consul_agent' start:
/var/vcap/jobs/consul_agent/bin/agent_ctl[UTC May 22 12:33:23] info
: start service 'nfs_mounter' on user request[UTC May 22 12:33:23]
info : monit daemon at 1050 awakened[UTC May 22 12:33:23] info
: start service 'metron_agent' on user request[UTC May 22 12:33:23]
info : monit daemon at 1050 awakened[UTC May 22 12:33:23] info
: start service 'cloud_controller_worker_1' on user request[UTC May 22
12:33:23] info : monit daemon at 1050 awakened[UTC May 22
12:33:24] info : 'consul_agent' start action done[UTC May 22
12:33:24] info : 'nfs_mounter' start:
/var/vcap/jobs/nfs_mounter/bin/nfs_mounter_ctl[UTC May 22 12:33:24]
info : 'cloud_controller_worker_1' start:
/var/vcap/jobs/cloud_controller_worker/bin/cloud_controller_worker_ctl*[UTC
May 22 12:33:25] info : 'cloud_controller_worker_1' start action
done
*[UTC May 22 12:33:25] info : 'metron_agent' start:
/var/vcap/jobs/metron_agent/bin/metron_agent_ctl[UTC May 22 12:33:26]
info : 'metron_agent' start action done*[UTC May 22 12:33:26] info
: 'cloud_controller_worker_1' stop:
/var/vcap/jobs/cloud_controller_worker/bin/cloud_controller_worker_ctl
*[UTC May 22 12:33:27] info : 'nfs_mounter' start action done[UTC
May 22 12:33:27] info : Awakened by User defined signal 1

There is no associated traces of the bosh agent asking this extra stop:

$ less /var/vcap/bosh/log/current
2015-05-22_12:33:23.73606 [monitJobSupervisor] 2015/05/22 12:33:23
DEBUG - Starting service
cloud_controller_worker_12015-05-22_12:33:23.73608 [http-client]
2015/05/22 12:33:23 DEBUG - Monit request:
url='http://127.0.0.1:2822/cloud_controller_worker_1'
body='action=start'2015-05-22_12:33:23.73608 [attemptRetryStrategy]
2015/05/22 12:33:23 DEBUG - Making attempt #02015-05-22_12:33:23.73609
[clientRetryable] 2015/05/22 12:33:23 DEBUG -
[requestID=52ede4f0-427d-4e65-6da1-d3b5c4b5cafd] Requesting
(attempt=1): Request{ Method: 'POST', URL:
'http://127.0.0.1:2822/cloud_controller_worker_1'
}2015-05-22_12:33:23.73647 [clientRetryable] 2015/05/22 12:33:23 DEBUG
- [requestID=52ede4f0-427d-4e65-6da1-d3b5c4b5cafd] Request succeeded
(attempts=1), response: Response{ StatusCode: 200, Status: '200
OK'}2015-05-22_12:33:23.73648 [MBus Handler] 2015/05/22 12:33:23 INFO
- Responding2015-05-22_12:33:23.73650 [MBus Handler] 2015/05/22
12:33:23 DEBUG - Payload2015-05-22_12:33:23.73650
********************2015-05-22_12:33:23.73651
{"value":"started"}2015-05-22_12:33:23.73651 ********************
2015-05-22_12:33:36.69397 [NATS Handler] 2015/05/22 12:33:36 DEBUG -
Message Payload2015-05-22_12:33:36.69397
********************2015-05-22_12:33:36.69397
{"job":"api_worker_z1","index":0,"job_state":"failing","vitals":{"cpu":{"sys":"6.5","user":"14.4","wait":"0.4"},"disk":{"ephemeral":{"inode_percent":"10","percent":"14"},"persistent":{"inode_percent":"36","percent":"48"},"system":{"inode_percent":"36","percent":"48"}},"load":["0.19","0.06","0.06"],"mem":{"kb":"81272","percent":"8"},"swap":{"kb":"0","percent":"0"}}}


This is reproducing systematically on our set up using bosh release 152
with stemcell bosh-vcloud-esxi-ubuntu-trusty-go_agent version 2889, and cf
release 207 running stemcell 2889.

Enabling monit verbose logs discarded the theory of monit restarting cc_ng
jobs because of too much ram usage, or failed http health check (along with
the short time window in which the extra stop is requested: ~15s). I also
discarded possibility of multiple monit instances, or pid inconsistency
with cc_ng process. I'm now suspecting either the bosh agent to send extra
stop request, or something with the cc_ng ctl scripts.

As a side question, can someone explain how the cc_ng ctl script works, I'm
suprised with the following process tree, where ruby seems to call the ctl
script. Is the cc spawning it self ?

$ ps auxf --cols=2000 | less
[...]
vcap 8011 0.6 7.4 793864 299852 ? S<l May26 6:01 ruby
/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/bin/cloud_controller
-m -c /var/vcap/jobs/cloud_controller_ng/config/cloud_controller_ng.yml
root 8014 0.0 0.0 19596 1436 ? S< May26 0:00 \_
/bin/bash /var/vcap/jobs/cloud_controller_ng/bin/cloud_controller_ng_ctl
start
root 8023 0.0 0.0 5924 1828 ? S< May26 0:00 |
\_ tee -a /dev/fd/63
root 8037 0.0 0.0 19600 1696 ? S< May26 0:00 |
| \_ /bin/bash
/var/vcap/jobs/cloud_controller_ng/bin/cloud_controller_ng_ctl start
root 8061 0.0 0.0 5916 1924 ? S< May26 0:00 |
| \_ logger -p user.info -t vcap.cloud_controller_ng_ctl.stdout
root 8024 0.0 0.0 7552 1788 ? S< May26 0:00 |
\_ awk -W Interactive {lineWithDate="echo [`date +\"%Y-%m-%d
%H:%M:%S%z\"`] \"" $0 "\""; system(lineWithDate) }
root 8015 0.0 0.0 19600 1440 ? S< May26 0:00 \_
/bin/bash /var/vcap/jobs/cloud_controller_ng/bin/cloud_controller_ng_ctl
start
root 8021 0.0 0.0 5924 1832 ? S< May26 0:00
\_ tee -a /dev/fd/63
root 8033 0.0 0.0 19600 1696 ? S< May26 0:00
| \_ /bin/bash
/var/vcap/jobs/cloud_controller_ng/bin/cloud_controller_ng_ctl start
root 8060 0.0 0.0 5912 1920 ? S< May26 0:00
| \_ logger -p user.error -t vcap.cloud_controller_ng_ctl.stderr
root 8022 0.0 0.0 7552 1748 ? S< May26 0:00
\_ awk -W Interactive {lineWithDate="echo [`date +\"%Y-%m-%d
%H:%M:%S%z\"`] \"" $0 "\""; system(lineWithDate) }


I was wondering whether this could come from our setting running CF with a
more recent stemcell version (2922) than what the cf release notes are
mentionning as "tested configuration". Are the latest stemcells tested
against latest CF release ? Is there any way to see what stemcell version
the runtime team pipelines is using [1] seemed to accept env vars and [2]
required logging in ? I scanned through the bosh agent commit logs to spot
something related but without luck so far.

Thanks in advance for your help,

Guillaume.

[1]
https://github.com/cloudfoundry/bosh-lite/blob/master/ci/ci-stemcell-bats.sh
<https://github.com/cloudfoundry/bosh-lite/blob/master/ci/ci-stemcell-bats.sh>
[2] https://concourse.diego-ci.cf-app.com/
<https://concourse.diego-ci.cf-app.com/>


Cloud Foundry Warden Mechanism

Kenneth Ham <kenneth.ham@...>
 

I need some help here. I have been working on this for a week now and have
researched the entire web but I couldn¹t find any relevant resource to this.

1. Lib/warden/container/linux.rb ­ I am trying to create a callback
mechanism during do_create, do_destroy, etc, and publish my callback to a
web API. How can I best achieve this?
2. Using unix socket, I tried to read /tmp/warden.sock and intercept
messages, I can¹t seem to get this to work, any advise what I have done
wrong?

Please advise what is the best way that I can approach this.

Thank you.

/kennetham


Important: This email and any attachments are confidential and may also be
privileged. If you are not the intended addressee, please delete this email
and any attachments from your system and notify the sender immediately; you
should not copy, distribute, circulate or in any other way use or take
actions in reliance on the information contained in this email or any
attachments for any purpose, nor disclose its contents to any other person.
Thank you.


Re: scheduler

Corentin Dupont <corentin.dupont@...>
 

Some other questions:
- is there a consolidation mechanism? From what I can see from the videos,
Diego is only doing load balancing when allocating an application to a DEA.
What is more important to us is to consolidate: we want to minimize the
number of DEAs.
Is there an extensibility mechanism to the scheduler?

- is there an auto-scaling mechanism? I'm thinking of auto-scaling at two
levels:
At application level, it would be nice to have auto-scaling in the
manifest.yml: if some KPI goes up, launch more instances.
At DEA level, a bit like in bosh-scaler: if DEAs are full, launch a new one.

Thanks!!
Corentin

On Tue, May 26, 2015 at 5:25 PM, Onsi Fakhouri <ofakhouri(a)pivotal.io> wrote:

Diego is very much usable at this point and we're encouraging beta testers
to start putting workloads on it. Check out
github.com/cloudfoundry-incubator/diego for all things Diego.

Diego supports one off tasks. It's up to the consumer (e.g. Cloud
Controller) to submit the tasks when they want them run. We'd like to
bubble this functionality up to the CC but it's not a very high priority at
the moment.

Onsi

Sent from my iPad

On May 26, 2015, at 8:21 AM, Corentin Dupont <
corentin.dupont(a)create-net.org> wrote:

Another question, what is the status of Diego? Is there an expected date
for its release?
Is it useable already?
If I understand correctly, Diego doesn't supports cron-like jobs, but will
facilitate them?

On Tue, May 26, 2015 at 5:08 PM, James Bayer <jbayer(a)pivotal.io> wrote:

those are exciting use cases, thank you for sharing the background!


On Tue, May 26, 2015 at 2:37 AM, Corentin Dupont <cdupont(a)create-net.org>
wrote:

Hi James, thanks for the answer!
We are interested to implement a job scheduler for CF. Do you think this
could be interesting to have?

We are working in a project called DC4Cities (http://www.dc4cities.eu)
were the objective is to make data centres use more renewable energy.
We want to use PaaS frameworks such as CloudFoundry to achieve this goal.
The idea is to schedule some PaaS tasks at the moment there is more
renewable energies (when the sun is shining).

That's why I had the idea to implement a job scheduler for batch jobs in
CF. For example one could state "I need to have this task to run for 2
hours per day" and the scheduler could choose when to run it.

Another possibility is to have application-oriented SLA implemented at
CF level. For example if some KPIs of the application are getting too low,
CF would spark a new container. If the SLA is defined with some
flexibility, it could also be used to schedule renewable energies. For
example in our trial scenarios we have an application that convert images.
Its SLA says that it needs to convert 1000 images per day, but you are free
to produce them when you want i.e. when renewable energies are available...


On Mon, May 25, 2015 at 7:29 PM, James Bayer <jbayer(a)pivotal.io> wrote:

there is ongoing work to support process types using buildpacks, so
that the same application codebase could be used for multiple different
types of processes (web, worker, etc).

once process types and diego tasks are fully available, we expect to
implement a user-facing api for running batch jobs as application processes.

what people do today is run a long-running process application which
uses something like quartz scheduler [1] or ruby clock with a worker system
like resque [2]

[1] http://quartz-scheduler.org/
[2] https://github.com/resque/resque-scheduler

On Mon, May 25, 2015 at 6:19 AM, Corentin Dupont <
cdupont(a)create-net.org> wrote:

To complete my request, I'm thinking of something like this in the
manifest.yml:

applications:
- name: virusscan
memory: 512M
instances: 1




*schedule: - startFrom : a date endBefore : a
date walltime : a duration*
* precedence : other application name moldable :
true/false*

What do you think?

On Mon, May 25, 2015 at 11:25 AM, Corentin Dupont <
cdupont(a)create-net.org> wrote:


---------- Forwarded message ----------
From: Corentin Dupont <corentin.dupont(a)create-net.org>
Date: Mon, May 25, 2015 at 11:21 AM
Subject: scheduler
To: cf-dev(a)lists.cloudfoundry.org


Hi guys,
just to know, is there a project to add a job scheduler in Cloud
Foundry?
I'm thinking of something like the Heroku scheduler (
https://devcenter.heroku.com/articles/scheduler).
That would be very neat to have regular tasks triggered...
Thanks,
Corentin


--

Corentin Dupont
Researcher @ Create-Netwww.corentindupont.info


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


--
Thank you,

James Bayer

--
Thank you,

James Bayer


--

Corentin Dupont
Researcher @ Create-Netwww.corentindupont.info

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

--

Corentin Dupont
Researcher @ Create-Netwww.corentindupont.info


Re: [vcap-dev] bosh create release --force

Filip Hanik
 

The script that is executing at the time is:

https://github.com/cloudfoundry/cf-release/blob/master/packages/uaa/pre_packaging#L36

So what my suggestion is to test if this works is that you can do

1. 'cd src/uaa'
2. ensure that you have a JDK 7 installed
3. run the command './gradlew assemble --info'

and this will tell us if the build process works on your machine.
We're looking for the output

BUILD SUCCESSFUL

Total time: 40.509 secs
Task timings:
579ms :cloudfoundry-identity-common:jar
7056ms :cloudfoundry-identity-common:javadoc
1981ms :cloudfoundry-identity-scim:compileJava
747ms :cloudfoundry-identity-login:compileJava
3800ms :cloudfoundry-identity-scim:javadoc
3141ms :cloudfoundry-identity-login:javadoc
3055ms :cloudfoundry-identity-uaa:war
1379ms :cloudfoundry-identity-samples:cloudfoundry-identity-api:javadoc
2176ms :cloudfoundry-identity-samples:cloudfoundry-identity-api:war
1443ms :cloudfoundry-identity-samples:cloudfoundry-identity-app:javadoc
2178ms :cloudfoundry-identity-samples:cloudfoundry-identity-app:war


On Wed, May 27, 2015 at 7:22 AM, Dhilip Kumar S <dhilip.kumar.s(a)huawei.com>
wrote:

Hi All,



While I was following the bosh release steps to deploy diego in bosh-lite
environment . It gets stuck at at the below area for hours how do I debug
this? Any clue would be great



Building golang1.4...

Using final version 'f57ddbc8d55d7a0f08775bf76bb6a27dc98c7ea7'



Building cloud_controller_ng...

Using final version 'e20142a32939a531038ace16a3cbe3b8242987e9'



Building libpq...

Using final version '49cc7477fcf9a3fef7a1f61e1494b32288587ed8'



Building nginx...

Using final version 'c916c10937c83a8be507d3100133101eb403c826'



Building rtr...

Using final version 'cd0d40ad56132a4d1cbc19223078f8ff96727d22'



Building doppler...

Using final version '2135434c91dc5e6f4aab6406b03ac02f9c2207fa'



Building uaa...

No artifact found for uaa

Generating...

Pre-packaging...





Regards,

Dhilip



*From:* Matthew Sykes [mailto:matthew.sykes(a)gmail.com]
*Sent:* Friday, May 22, 2015 3:32 PM
*To:* vcap-dev(a)cloudfoundry.org
*Subject:* Re: [vcap-dev] container cannot communicate with the host



Warden explicitly disables access to the container host. If you move up to
a more recent level of cf-release, that behavior is configurable with the
`allow_host_access` flag. When that flag is true, this line is skipped:




https://github.com/cloudfoundry/warden/blob/4f1e5c049a12199fdd1f29cde15c9a786bd5fac8/warden/root/linux/net.sh#L128



At the level you're at, that rule is always specified so you'd have to
manually change it.




https://github.com/cloudfoundry/warden/blob/17f34e2d7ff1994856a61961210a82e83f24ecac/warden/root/linux/net.sh#L124



On Fri, May 22, 2015 at 3:17 AM, Youzhi Zhu <zhuyouzhi03(a)gmail.com> wrote:

Hi all

I have an app A and a service B, service B is running on the dea
server(ip 10.0.0.254), app A need to connect with service B through tcp, it
works normally in my LAN, but when I push A to cf, it cannot connect to B,
then I execute bin/wsh to get into the container and ping the host ip,
it's unreachable, as below:







*root(a)18mkbd9n808:~# ping 10.0.0.254 PING 10.0.0.254 (10.0.0.254) 56(84)
bytes of data. From 10.0.0.254 icmp_seq=1 Destination Port Unreachable From
10.0.0.254 icmp_seq=2 Destination Port Unreachable ^C --- 10.0.0.254 ping
statistics --- 2 packets transmitted, 0 received, +2 errors, 100% packet
loss, time 1002ms*

But if I ping another host in the LAN. it can be reached!!!








*root(a)18mkbd9n808:~# ping 10.0.0.253 PING 10.0.0.253 (10.0.0.253) 56(84)
bytes of data. 64 bytes from 10.0.0.253 <http://10.0.0.253>: icmp_seq=1
ttl=63 time=1.60 ms 64 bytes from 10.0.0.253 <http://10.0.0.253>:
icmp_seq=2 ttl=63 time=0.421 ms ^C --- 10.0.0.253 ping statistics --- 2
packets transmitted, 2 received, 0% packet loss, time 1001ms rtt
min/avg/max/mdev = 0.421/1.013/1.606/0.593 ms*

It's wired!!! my cf-release is cf-175 and I have only one dea server.Does
anyone met this situation before? thanks!

--
This mailing list is for closed, and is available for archival purposes
only. For active discussion, please visit
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev or email
cf-dev(a)lists.cloudfoundry.org
---
You received this message because you are subscribed to the Google Groups
"Cloud Foundry Developers" group.
To view this discussion on the web visit
https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/CAGO-E6pv-Z3kEVUwMu2Wce1wBDHUpa49mjdOe1PXXrO-bKpVPg%40mail.gmail.com
<https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/CAGO-E6pv-Z3kEVUwMu2Wce1wBDHUpa49mjdOe1PXXrO-bKpVPg%40mail.gmail.com?utm_medium=email&utm_source=footer>
.





--

Matthew Sykes
matthew.sykes(a)gmail.com

--
This mailing list is for closed, and is available for archival purposes
only. For active discussion, please visit
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev or email
cf-dev(a)lists.cloudfoundry.org
---
You received this message because you are subscribed to the Google Groups
"Cloud Foundry Developers" group.
To view this discussion on the web visit
https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/CAFcj6oQfRC5fQCEBaK24WeMSBWWhkBZBcZzEzO49zy-PLBRpYg%40mail.gmail.com
<https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/CAFcj6oQfRC5fQCEBaK24WeMSBWWhkBZBcZzEzO49zy-PLBRpYg%40mail.gmail.com?utm_medium=email&utm_source=footer>
.

--
This mailing list is for closed, and is available for archival purposes
only. For active discussion, please visit
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev or email
cf-dev(a)lists.cloudfoundry.org
---
You received this message because you are subscribed to the Google Groups
"Cloud Foundry Developers" group.
To view this discussion on the web visit
https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/DB525612315D2C41BB1177C30F24024D295850%40blreml508-mbx
<https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/DB525612315D2C41BB1177C30F24024D295850%40blreml508-mbx?utm_medium=email&utm_source=footer>
.


Re: scheduler

Eric Malm <emalm@...>
 

Hi, Corentin,

Diego, like the DEAs, supports evacuation of LRP instances during
controlled shutdown of a cell VM (the analog of a single DEA in Diego's
architecture). If you're using BOSH to deploy your Diego cluster and you
redeploy to scale down the number of cell VMs, BOSH will trigger evacuation
via the `drain` script in the rep job template. This will cause that cell's
rep process to signal to the rest of the system via the BBS that its
instances should be started on the other cells. Once those instances are
all placed elsewhere, or the drain timeout is reached, the cell will finish
shutting down. If you're not using BOSH to deploy your cluster, the drain
script template in diego-release should show you how to trigger the rep to
evacuate manually.

If you're reducing the size of your deployment, you should of course ensure
that you have sufficient capacity in the scaled-down cluster to run all
your application instances, with some headroom for staging tasks and
placement of high-memory app instances. Diego's placement algorithm
currently prefers an even distribution of instances across availability
zones and cell VMs, so its ideal placement results in roughly the same
amount of capacity free on each cell.

Diego itself does not include an autoscaling mechanism for long-running
processes, although it does now report instance CPU/disk/memory usage
metrics through the loggregator system. One could use that to build an
autoscaler for CF apps via the CC API; if existing autoscalers use those
fields from the 'stats' endpoint on the CC API, they should continue to
function with the Diego backend. Likewise, Diego has no knowledge of its
provisioner (BOSH or otherwise), so it can't scale its own deployment
automatically, but one could automate monitoring Diego's capacity metrics
(also emitted through the loggregator system) and scaling up or down the
cell deployment in response to certain capacity thresholds.

Thanks,
Eric, CF Runtime Diego PM


On Wed, May 27, 2015 at 5:22 AM, Corentin Dupont <
corentin.dupont(a)create-net.org> wrote:

Some other questions:
- is there a consolidation mechanism? From what I can see from the videos,
Diego is only doing load balancing when allocating an application to a DEA.
What is more important to us is to consolidate: we want to minimize the
number of DEAs.
Is there an extensibility mechanism to the scheduler?

- is there an auto-scaling mechanism? I'm thinking of auto-scaling at two
levels:
At application level, it would be nice to have auto-scaling in the
manifest.yml: if some KPI goes up, launch more instances.
At DEA level, a bit like in bosh-scaler: if DEAs are full, launch a new
one.

Thanks!!
Corentin


On Tue, May 26, 2015 at 5:25 PM, Onsi Fakhouri <ofakhouri(a)pivotal.io>
wrote:

Diego is very much usable at this point and we're encouraging beta
testers to start putting workloads on it. Check out
github.com/cloudfoundry-incubator/diego for all things Diego.

Diego supports one off tasks. It's up to the consumer (e.g. Cloud
Controller) to submit the tasks when they want them run. We'd like to
bubble this functionality up to the CC but it's not a very high priority at
the moment.

Onsi

Sent from my iPad

On May 26, 2015, at 8:21 AM, Corentin Dupont <
corentin.dupont(a)create-net.org> wrote:

Another question, what is the status of Diego? Is there an expected date
for its release?
Is it useable already?
If I understand correctly, Diego doesn't supports cron-like jobs, but
will facilitate them?

On Tue, May 26, 2015 at 5:08 PM, James Bayer <jbayer(a)pivotal.io> wrote:

those are exciting use cases, thank you for sharing the background!


On Tue, May 26, 2015 at 2:37 AM, Corentin Dupont <cdupont(a)create-net.org
wrote:
Hi James, thanks for the answer!
We are interested to implement a job scheduler for CF. Do you think
this could be interesting to have?

We are working in a project called DC4Cities (http://www.dc4cities.eu)
were the objective is to make data centres use more renewable energy.
We want to use PaaS frameworks such as CloudFoundry to achieve this
goal.
The idea is to schedule some PaaS tasks at the moment there is more
renewable energies (when the sun is shining).

That's why I had the idea to implement a job scheduler for batch jobs
in CF. For example one could state "I need to have this task to run for 2
hours per day" and the scheduler could choose when to run it.

Another possibility is to have application-oriented SLA implemented at
CF level. For example if some KPIs of the application are getting too low,
CF would spark a new container. If the SLA is defined with some
flexibility, it could also be used to schedule renewable energies. For
example in our trial scenarios we have an application that convert images.
Its SLA says that it needs to convert 1000 images per day, but you are free
to produce them when you want i.e. when renewable energies are available...


On Mon, May 25, 2015 at 7:29 PM, James Bayer <jbayer(a)pivotal.io> wrote:

there is ongoing work to support process types using buildpacks, so
that the same application codebase could be used for multiple different
types of processes (web, worker, etc).

once process types and diego tasks are fully available, we expect to
implement a user-facing api for running batch jobs as application processes.

what people do today is run a long-running process application which
uses something like quartz scheduler [1] or ruby clock with a worker system
like resque [2]

[1] http://quartz-scheduler.org/
[2] https://github.com/resque/resque-scheduler

On Mon, May 25, 2015 at 6:19 AM, Corentin Dupont <
cdupont(a)create-net.org> wrote:

To complete my request, I'm thinking of something like this in the
manifest.yml:

applications:
- name: virusscan
memory: 512M
instances: 1




*schedule: - startFrom : a date endBefore : a
date walltime : a duration*
* precedence : other application name moldable :
true/false*

What do you think?

On Mon, May 25, 2015 at 11:25 AM, Corentin Dupont <
cdupont(a)create-net.org> wrote:


---------- Forwarded message ----------
From: Corentin Dupont <corentin.dupont(a)create-net.org>
Date: Mon, May 25, 2015 at 11:21 AM
Subject: scheduler
To: cf-dev(a)lists.cloudfoundry.org


Hi guys,
just to know, is there a project to add a job scheduler in Cloud
Foundry?
I'm thinking of something like the Heroku scheduler (
https://devcenter.heroku.com/articles/scheduler).
That would be very neat to have regular tasks triggered...
Thanks,
Corentin


--

Corentin Dupont
Researcher @ Create-Netwww.corentindupont.info


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


--
Thank you,

James Bayer

--
Thank you,

James Bayer


--

Corentin Dupont
Researcher @ Create-Netwww.corentindupont.info

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


--

Corentin Dupont
Researcher @ Create-Netwww.corentindupont.info


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


Re: api and api_worker jobs fail to bosh update, but monit start OK

Mike Youngstrom
 

We recently experienced a similar issue. Not sure if it is the same. But
it was caused when we moved the nfs_mounter job template to the first item
in the list of templates for the CC job. We moved nfs_mounter to the last
job template in the list and we haven't had a problem since. It was really
strange cause you think you'd want nfs_mounter first. Anyway, something to
try.

Mike

On Wed, May 27, 2015 at 4:51 AM, Guillaume Berche <bercheg(a)gmail.com> wrote:

Hi,

I'm experiencing a weird situation where api and api_worker jobs fail to
update through bosh and end up being reported as "not running". However,
manually running "monit start cloud_controller_ng" (or rebooting the vm),
the faulty jobs starts fine, and bosh deployment proceeds without errors.
Looking at monit logs, it seems that there is an extra monit stop request
for the cc_ng.

Below are detailed traces illustrating the issue.

$ bosh deploy

[..]
Started updating job ha_proxy_z1 > ha_proxy_z1/0 (canary). Done (00:00:39)
Started updating job api_z1 > api_z1/0 (canary). Failed: `api_z1/0' is not running after update (00:10:44)


When instructing bosh to update the job (in this case only a config
change), we indeed see the bosh agent asking monit to stop jobs, restart
monit itself, start jobs, and then we see the extra stop (at* 12:33:26) *before
the bosh director ends up timeouting and calling the canary failed.

$ less /var/vcap/monit/monit.log

[UTC May 22 12:33:17] info : Awakened by User defined signal 1[UTC May 22 12:33:17] info : Awakened by the SIGHUP signal[UTC May 22 12:33:17] info : Reinitializing monit - Control file '/var/vcap/bosh/etc/monitrc'[UTC May 22 12:33:17] info : Shutting down monit HTTP server[UTC May 22 12:33:18] info : monit HTTP server stopped[UTC May 22 12:33:18] info : Starting monit HTTP server at [127.0.0.1:2822][UTC May 22 12:33:18] info : monit HTTP server started[UTC May 22 12:33:18] info : 'system_897cdb8d-f9f7-4bfa-a748-512489b676e0' Monit reloaded[UTC May 22 12:33:23] info : start service 'consul_agent' on user request[UTC May 22 12:33:23] info : monit daemon at 1050 awakened[UTC May 22 12:33:23] info : Awakened by User defined signal 1[UTC May 22 12:33:23] info : 'consul_agent' start: /var/vcap/jobs/consul_agent/bin/agent_ctl[UTC May 22 12:33:23] info : start service 'nfs_mounter' on user request[UTC May 22 12:33:23] info : monit daemon at 1050 awakened[UTC May 22 12:33:23] info : start service 'metron_agent' on user request[UTC May 22 12:33:23] info : monit daemon at 1050 awakened[UTC May 22 12:33:23] info : start service 'cloud_controller_worker_1' on user request[UTC May 22 12:33:23] info : monit daemon at 1050 awakened[UTC May 22 12:33:24] info : 'consul_agent' start action done[UTC May 22 12:33:24] info : 'nfs_mounter' start: /var/vcap/jobs/nfs_mounter/bin/nfs_mounter_ctl[UTC May 22 12:33:24] info : 'cloud_controller_worker_1' start: /var/vcap/jobs/cloud_controller_worker/bin/cloud_controller_worker_ctl*[UTC May 22 12:33:25] info : 'cloud_controller_worker_1' start action done
*[UTC May 22 12:33:25] info : 'metron_agent' start: /var/vcap/jobs/metron_agent/bin/metron_agent_ctl[UTC May 22 12:33:26] info : 'metron_agent' start action done*[UTC May 22 12:33:26] info : 'cloud_controller_worker_1' stop: /var/vcap/jobs/cloud_controller_worker/bin/cloud_controller_worker_ctl
*[UTC May 22 12:33:27] info : 'nfs_mounter' start action done[UTC May 22 12:33:27] info : Awakened by User defined signal 1

There is no associated traces of the bosh agent asking this extra stop:

$ less /var/vcap/bosh/log/current
2015-05-22_12:33:23.73606 [monitJobSupervisor] 2015/05/22 12:33:23 DEBUG - Starting service cloud_controller_worker_12015-05-22_12:33:23.73608 [http-client] 2015/05/22 12:33:23 DEBUG - Monit request: url='http://127.0.0.1:2822/cloud_controller_worker_1' body='action=start'2015-05-22_12:33:23.73608 [attemptRetryStrategy] 2015/05/22 12:33:23 DEBUG - Making attempt #02015-05-22_12:33:23.73609 [clientRetryable] 2015/05/22 12:33:23 DEBUG - [requestID=52ede4f0-427d-4e65-6da1-d3b5c4b5cafd] Requesting (attempt=1): Request{ Method: 'POST', URL: 'http://127.0.0.1:2822/cloud_controller_worker_1' }2015-05-22_12:33:23.73647 [clientRetryable] 2015/05/22 12:33:23 DEBUG - [requestID=52ede4f0-427d-4e65-6da1-d3b5c4b5cafd] Request succeeded (attempts=1), response: Response{ StatusCode: 200, Status: '200 OK'}2015-05-22_12:33:23.73648 [MBus Handler] 2015/05/22 12:33:23 INFO - Responding2015-05-22_12:33:23.73650 [MBus Handler] 2015/05/22 12:33:23 DEBUG - Payload2015-05-22_12:33:23.73650 ********************2015-05-22_12:33:23.73651 {"value":"started"}2015-05-22_12:33:23.73651 ********************
2015-05-22_12:33:36.69397 [NATS Handler] 2015/05/22 12:33:36 DEBUG - Message Payload2015-05-22_12:33:36.69397 ********************2015-05-22_12:33:36.69397 {"job":"api_worker_z1","index":0,"job_state":"failing","vitals":{"cpu":{"sys":"6.5","user":"14.4","wait":"0.4"},"disk":{"ephemeral":{"inode_percent":"10","percent":"14"},"persistent":{"inode_percent":"36","percent":"48"},"system":{"inode_percent":"36","percent":"48"}},"load":["0.19","0.06","0.06"],"mem":{"kb":"81272","percent":"8"},"swap":{"kb":"0","percent":"0"}}}


This is reproducing systematically on our set up using bosh release 152
with stemcell bosh-vcloud-esxi-ubuntu-trusty-go_agent version 2889, and cf
release 207 running stemcell 2889.

Enabling monit verbose logs discarded the theory of monit restarting cc_ng
jobs because of too much ram usage, or failed http health check (along with
the short time window in which the extra stop is requested: ~15s). I also
discarded possibility of multiple monit instances, or pid inconsistency
with cc_ng process. I'm now suspecting either the bosh agent to send extra
stop request, or something with the cc_ng ctl scripts.

As a side question, can someone explain how the cc_ng ctl script works,
I'm suprised with the following process tree, where ruby seems to call the
ctl script. Is the cc spawning it self ?

$ ps auxf --cols=2000 | less
[...]
vcap 8011 0.6 7.4 793864 299852 ? S<l May26 6:01 ruby /var/vcap/packages/cloud_controller_ng/cloud_controller_ng/bin/cloud_controller -m -c /var/vcap/jobs/cloud_controller_ng/config/cloud_controller_ng.yml
root 8014 0.0 0.0 19596 1436 ? S< May26 0:00 \_ /bin/bash /var/vcap/jobs/cloud_controller_ng/bin/cloud_controller_ng_ctl start
root 8023 0.0 0.0 5924 1828 ? S< May26 0:00 | \_ tee -a /dev/fd/63
root 8037 0.0 0.0 19600 1696 ? S< May26 0:00 | | \_ /bin/bash /var/vcap/jobs/cloud_controller_ng/bin/cloud_controller_ng_ctl start
root 8061 0.0 0.0 5916 1924 ? S< May26 0:00 | | \_ logger -p user.info -t vcap.cloud_controller_ng_ctl.stdout
root 8024 0.0 0.0 7552 1788 ? S< May26 0:00 | \_ awk -W Interactive {lineWithDate="echo [`date +\"%Y-%m-%d %H:%M:%S%z\"`] \"" $0 "\""; system(lineWithDate) }
root 8015 0.0 0.0 19600 1440 ? S< May26 0:00 \_ /bin/bash /var/vcap/jobs/cloud_controller_ng/bin/cloud_controller_ng_ctl start
root 8021 0.0 0.0 5924 1832 ? S< May26 0:00 \_ tee -a /dev/fd/63
root 8033 0.0 0.0 19600 1696 ? S< May26 0:00 | \_ /bin/bash /var/vcap/jobs/cloud_controller_ng/bin/cloud_controller_ng_ctl start
root 8060 0.0 0.0 5912 1920 ? S< May26 0:00 | \_ logger -p user.error -t vcap.cloud_controller_ng_ctl.stderr
root 8022 0.0 0.0 7552 1748 ? S< May26 0:00 \_ awk -W Interactive {lineWithDate="echo [`date +\"%Y-%m-%d %H:%M:%S%z\"`] \"" $0 "\""; system(lineWithDate) }


I was wondering whether this could come from our setting running CF with a
more recent stemcell version (2922) than what the cf release notes are
mentionning as "tested configuration". Are the latest stemcells tested
against latest CF release ? Is there any way to see what stemcell version
the runtime team pipelines is using [1] seemed to accept env vars and [2]
required logging in ? I scanned through the bosh agent commit logs to spot
something related but without luck so far.

Thanks in advance for your help,

Guillaume.

[1]
https://github.com/cloudfoundry/bosh-lite/blob/master/ci/ci-stemcell-bats.sh
<https://github.com/cloudfoundry/bosh-lite/blob/master/ci/ci-stemcell-bats.sh>
[2] https://concourse.diego-ci.cf-app.com/
<https://concourse.diego-ci.cf-app.com/>


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


Re: api and api_worker jobs fail to bosh update, but monit start OK

Dieu Cao <dcao@...>
 

We have environments on stemcell 2977 that are running well.

We have an environment using NFS that ran into that same issue and we have
this bug open. [1]
Specifying the nfs_mounter job last should work in the mean time until we
get the order switched.
This was apparently introduced when we added consul_agent to the cloud
controller jobs.
I'll update the release notes for the affected releases.

-Dieu
CF Runtime PM

[1] https://www.pivotaltracker.com/story/show/94152506

On Wed, May 27, 2015 at 10:09 AM, Mike Youngstrom <youngm(a)gmail.com> wrote:

We recently experienced a similar issue. Not sure if it is the same. But
it was caused when we moved the nfs_mounter job template to the first item
in the list of templates for the CC job. We moved nfs_mounter to the last
job template in the list and we haven't had a problem since. It was really
strange cause you think you'd want nfs_mounter first. Anyway, something to
try.

Mike

On Wed, May 27, 2015 at 4:51 AM, Guillaume Berche <bercheg(a)gmail.com>
wrote:

Hi,

I'm experiencing a weird situation where api and api_worker jobs fail to
update through bosh and end up being reported as "not running". However,
manually running "monit start cloud_controller_ng" (or rebooting the vm),
the faulty jobs starts fine, and bosh deployment proceeds without errors.
Looking at monit logs, it seems that there is an extra monit stop request
for the cc_ng.

Below are detailed traces illustrating the issue.

$ bosh deploy

[..]
Started updating job ha_proxy_z1 > ha_proxy_z1/0 (canary). Done (00:00:39)
Started updating job api_z1 > api_z1/0 (canary). Failed: `api_z1/0' is not running after update (00:10:44)


When instructing bosh to update the job (in this case only a config
change), we indeed see the bosh agent asking monit to stop jobs, restart
monit itself, start jobs, and then we see the extra stop (at* 12:33:26) *before
the bosh director ends up timeouting and calling the canary failed.

$ less /var/vcap/monit/monit.log

[UTC May 22 12:33:17] info : Awakened by User defined signal 1[UTC May 22 12:33:17] info : Awakened by the SIGHUP signal[UTC May 22 12:33:17] info : Reinitializing monit - Control file '/var/vcap/bosh/etc/monitrc'[UTC May 22 12:33:17] info : Shutting down monit HTTP server[UTC May 22 12:33:18] info : monit HTTP server stopped[UTC May 22 12:33:18] info : Starting monit HTTP server at [127.0.0.1:2822][UTC May 22 12:33:18] info : monit HTTP server started[UTC May 22 12:33:18] info : 'system_897cdb8d-f9f7-4bfa-a748-512489b676e0' Monit reloaded[UTC May 22 12:33:23] info : start service 'consul_agent' on user request[UTC May 22 12:33:23] info : monit daemon at 1050 awakened[UTC May 22 12:33:23] info : Awakened by User defined signal 1[UTC May 22 12:33:23] info : 'consul_agent' start: /var/vcap/jobs/consul_agent/bin/agent_ctl[UTC May 22 12:33:23] info : start service 'nfs_mounter' on user request[UTC May 22 12:33:23] info : monit daemon at 1050 awakened[UTC May 22 12:33:23] info : start service 'metron_agent' on user request[UTC May 22 12:33:23] info : monit daemon at 1050 awakened[UTC May 22 12:33:23] info : start service 'cloud_controller_worker_1' on user request[UTC May 22 12:33:23] info : monit daemon at 1050 awakened[UTC May 22 12:33:24] info : 'consul_agent' start action done[UTC May 22 12:33:24] info : 'nfs_mounter' start: /var/vcap/jobs/nfs_mounter/bin/nfs_mounter_ctl[UTC May 22 12:33:24] info : 'cloud_controller_worker_1' start: /var/vcap/jobs/cloud_controller_worker/bin/cloud_controller_worker_ctl*[UTC May 22 12:33:25] info : 'cloud_controller_worker_1' start action done
*[UTC May 22 12:33:25] info : 'metron_agent' start: /var/vcap/jobs/metron_agent/bin/metron_agent_ctl[UTC May 22 12:33:26] info : 'metron_agent' start action done*[UTC May 22 12:33:26] info : 'cloud_controller_worker_1' stop: /var/vcap/jobs/cloud_controller_worker/bin/cloud_controller_worker_ctl
*[UTC May 22 12:33:27] info : 'nfs_mounter' start action done[UTC May 22 12:33:27] info : Awakened by User defined signal 1

There is no associated traces of the bosh agent asking this extra stop:

$ less /var/vcap/bosh/log/current
2015-05-22_12:33:23.73606 [monitJobSupervisor] 2015/05/22 12:33:23 DEBUG - Starting service cloud_controller_worker_12015-05-22_12:33:23.73608 [http-client] 2015/05/22 12:33:23 DEBUG - Monit request: url='http://127.0.0.1:2822/cloud_controller_worker_1' body='action=start'2015-05-22_12:33:23.73608 [attemptRetryStrategy] 2015/05/22 12:33:23 DEBUG - Making attempt #02015-05-22_12:33:23.73609 [clientRetryable] 2015/05/22 12:33:23 DEBUG - [requestID=52ede4f0-427d-4e65-6da1-d3b5c4b5cafd] Requesting (attempt=1): Request{ Method: 'POST', URL: 'http://127.0.0.1:2822/cloud_controller_worker_1' }2015-05-22_12:33:23.73647 [clientRetryable] 2015/05/22 12:33:23 DEBUG - [requestID=52ede4f0-427d-4e65-6da1-d3b5c4b5cafd] Request succeeded (attempts=1), response: Response{ StatusCode: 200, Status: '200 OK'}2015-05-22_12:33:23.73648 [MBus Handler] 2015/05/22 12:33:23 INFO - Responding2015-05-22_12:33:23.73650 [MBus Handler] 2015/05/22 12:33:23 DEBUG - Payload2015-05-22_12:33:23.73650 ********************2015-05-22_12:33:23.73651 {"value":"started"}2015-05-22_12:33:23.73651 ********************
2015-05-22_12:33:36.69397 [NATS Handler] 2015/05/22 12:33:36 DEBUG - Message Payload2015-05-22_12:33:36.69397 ********************2015-05-22_12:33:36.69397 {"job":"api_worker_z1","index":0,"job_state":"failing","vitals":{"cpu":{"sys":"6.5","user":"14.4","wait":"0.4"},"disk":{"ephemeral":{"inode_percent":"10","percent":"14"},"persistent":{"inode_percent":"36","percent":"48"},"system":{"inode_percent":"36","percent":"48"}},"load":["0.19","0.06","0.06"],"mem":{"kb":"81272","percent":"8"},"swap":{"kb":"0","percent":"0"}}}


This is reproducing systematically on our set up using bosh release 152
with stemcell bosh-vcloud-esxi-ubuntu-trusty-go_agent version 2889, and cf
release 207 running stemcell 2889.

Enabling monit verbose logs discarded the theory of monit restarting
cc_ng jobs because of too much ram usage, or failed http health check
(along with the short time window in which the extra stop is requested:
~15s). I also discarded possibility of multiple monit instances, or pid
inconsistency with cc_ng process. I'm now suspecting either the bosh agent
to send extra stop request, or something with the cc_ng ctl scripts.

As a side question, can someone explain how the cc_ng ctl script works,
I'm suprised with the following process tree, where ruby seems to call the
ctl script. Is the cc spawning it self ?

$ ps auxf --cols=2000 | less
[...]
vcap 8011 0.6 7.4 793864 299852 ? S<l May26 6:01 ruby /var/vcap/packages/cloud_controller_ng/cloud_controller_ng/bin/cloud_controller -m -c /var/vcap/jobs/cloud_controller_ng/config/cloud_controller_ng.yml
root 8014 0.0 0.0 19596 1436 ? S< May26 0:00 \_ /bin/bash /var/vcap/jobs/cloud_controller_ng/bin/cloud_controller_ng_ctl start
root 8023 0.0 0.0 5924 1828 ? S< May26 0:00 | \_ tee -a /dev/fd/63
root 8037 0.0 0.0 19600 1696 ? S< May26 0:00 | | \_ /bin/bash /var/vcap/jobs/cloud_controller_ng/bin/cloud_controller_ng_ctl start
root 8061 0.0 0.0 5916 1924 ? S< May26 0:00 | | \_ logger -p user.info -t vcap.cloud_controller_ng_ctl.stdout
root 8024 0.0 0.0 7552 1788 ? S< May26 0:00 | \_ awk -W Interactive {lineWithDate="echo [`date +\"%Y-%m-%d %H:%M:%S%z\"`] \"" $0 "\""; system(lineWithDate) }
root 8015 0.0 0.0 19600 1440 ? S< May26 0:00 \_ /bin/bash /var/vcap/jobs/cloud_controller_ng/bin/cloud_controller_ng_ctl start
root 8021 0.0 0.0 5924 1832 ? S< May26 0:00 \_ tee -a /dev/fd/63
root 8033 0.0 0.0 19600 1696 ? S< May26 0:00 | \_ /bin/bash /var/vcap/jobs/cloud_controller_ng/bin/cloud_controller_ng_ctl start
root 8060 0.0 0.0 5912 1920 ? S< May26 0:00 | \_ logger -p user.error -t vcap.cloud_controller_ng_ctl.stderr
root 8022 0.0 0.0 7552 1748 ? S< May26 0:00 \_ awk -W Interactive {lineWithDate="echo [`date +\"%Y-%m-%d %H:%M:%S%z\"`] \"" $0 "\""; system(lineWithDate) }


I was wondering whether this could come from our setting running CF with
a more recent stemcell version (2922) than what the cf release notes are
mentionning as "tested configuration". Are the latest stemcells tested
against latest CF release ? Is there any way to see what stemcell version
the runtime team pipelines is using [1] seemed to accept env vars and [2]
required logging in ? I scanned through the bosh agent commit logs to spot
something related but without luck so far.

Thanks in advance for your help,

Guillaume.

[1]
https://github.com/cloudfoundry/bosh-lite/blob/master/ci/ci-stemcell-bats.sh
<https://github.com/cloudfoundry/bosh-lite/blob/master/ci/ci-stemcell-bats.sh>
[2] https://concourse.diego-ci.cf-app.com/
<https://concourse.diego-ci.cf-app.com/>


_______________________________________________
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


(No subject)

Abderrahim Chibani
 

We recently experienced a similar issue. Not sure if it is the same. But
it was caused when we moved the nfs_mounter job template to the first item
in the list of templates for the CC job. We moved nfs_mounter to the last
job template in the list and we haven't had a problem since. It was really
strange cause you think you'd want nfs_mounter first. Anyway, something to
try.


Diego Question

Daniel Mikusa
 

I was testing an app on Diego today and part of the test was for the app to
fail. I simulated this by putting some garbage into the `-c` argument of
`cf push`. This had the right effect and my app failed.

At the same time, I was tailing the logs in another window. While I got my
logs, I also got a hundreds of lines like this...

```
2015-05-27T16:46:01.64-0400 [HEALTH/0] OUT healthcheck failed
2015-05-27T16:46:01.65-0400 [HEALTH/0] OUT Exit status 1
2015-05-27T16:46:02.19-0400 [HEALTH/0] OUT healthcheck failed
2015-05-27T16:46:02.19-0400 [HEALTH/0] OUT Exit status 1
2015-05-27T16:46:02.74-0400 [HEALTH/0] OUT healthcheck failed
2015-05-27T16:46:02.74-0400 [HEALTH/0] OUT Exit status 1
...
```

Is that expected? It seems to add a lot of noise.

Sorry, I don't know the exact version of Diego. I was testing on PWS.

Thanks,

Dan


Re: Diego Question

Karen Wang <khwang@...>
 

Dan,

We announce the PWS's CF version on status.run.pivotal.io:

About This Site

If you encounter any issues please contact support(a)run.pivotal.io. Pivotal
Web Services is the latest public release of the OSS Cloud Foundry Project
The current release of Cloud Foundry deployed on PWS is v210 on 23 May
2015. Details about this release can be found at the Cloud Foundry
community wiki which is located at:
https://github.com/cloudfoundry-community/cf-docs-contrib/wiki/All-CF-Releases

When you click on the link and go to the release note for v210, there
you'll see:

Compatible Diego Version



- final release 0.1247.0 commit
<https://github.com/cloudfoundry-incubator/diego-release/commit/a122a78eeb344bbfc90b7bcd0fa987d08ef1a5d1>


And this is the version of Diego deployed along side the specific CF
release.

Karen

On Wed, May 27, 2015 at 1:53 PM, Daniel Mikusa <dmikusa(a)pivotal.io> wrote:

I was testing an app on Diego today and part of the test was for the app
to fail. I simulated this by putting some garbage into the `-c` argument
of `cf push`. This had the right effect and my app failed.

At the same time, I was tailing the logs in another window. While I got
my logs, I also got a hundreds of lines like this...

```
2015-05-27T16:46:01.64-0400 [HEALTH/0] OUT healthcheck failed
2015-05-27T16:46:01.65-0400 [HEALTH/0] OUT Exit status 1
2015-05-27T16:46:02.19-0400 [HEALTH/0] OUT healthcheck failed
2015-05-27T16:46:02.19-0400 [HEALTH/0] OUT Exit status 1
2015-05-27T16:46:02.74-0400 [HEALTH/0] OUT healthcheck failed
2015-05-27T16:46:02.74-0400 [HEALTH/0] OUT Exit status 1
...
```

Is that expected? It seems to add a lot of noise.

Sorry, I don't know the exact version of Diego. I was testing on PWS.

Thanks,

Dan

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


Re: Multiple Availability Zone

iamflying
 

I updated my bosh (using bosh-init) with enabling
ignore_server_availability_zone. but it still failed when I deployed my cf.
Anything suggestion?

openstack: &openstack
auth_url: http://137.172.74.78:5000/v2.0 # <--- Replace with OpenStack
Identity API endpoint
tenant: cf # <--- Replace with OpenStack tenant name
username: cf-admin # <--- Replace with OpenStack username
api_key: passw0rd # <--- Replace with OpenStack password
default_key_name: cf-keypair
default_security_groups: [default,bosh]
ignore_server_availability_zone: true


Error message from the deployment of cf:
Started updating job etcd_z1 > etcd_z1/0 (canary). Failed: OpenStack API
Bad Request (Invalid input received: Availability zone 'cloud-cf-az2' is
invalid). Check task debug log for details. (00:00:19)

Error 100: OpenStack API Bad Request (Invalid input received: Availability
zone 'cloud-cf-az2' is invalid). Check task debug log for details.


I checked the api request on first computing node. (/var/log/cinder/api.log)
2015-05-27 16:28:40.652 32174 DEBUG cinder.api.v1.volumes
[req-4df6ac85-e986-438a-a953-5a2190ec5f62 8b0d5a75bd9c4539ba7fa64e5669c6c8
48a0898a9c4944f1b321da699ca4c37a - - -] Create volume request body:
{u'volume': {'scheduler_hints': {}, u'availability_zone': u'cloud-cf-az2',
u'display_name': u'volume-36f9a2eb-8bc9-4f27-9530-34c9d24fa881',
u'display_description': u'', u'size': 10}} create
/usr/lib/python2.6/site-packages/cinder/api/v1/volumes.py:316


Attached my cf deployment file for reference.
cf-deployment-single-az.yml
<http://cf-dev.70369.x6.nabble.com/file/n206/cf-deployment-single-az.yml>





--
View this message in context: http://cf-dev.70369.x6.nabble.com/cf-dev-Multiple-Availability-Zone-tp192p206.html
Sent from the CF Dev mailing list archive at Nabble.com.


Custom Login Server with UAA 2.0+

Matt Cholick
 

Prior to the consolidation of uaa and the login server in uaa release 2.0,
we were running our own login server to handle auth to our platform. We
simply reduced the instance of the bundled CF login server to 0 and put our
own in place, which snagged the login subdomain. This worked just fine; our
solution implemented all the needed endpoints to login.

We're now upgrading to a newer release with uaa 2.0+ and having
difficulties. The uaa registrar hardcodes grabbing the login subdomains:
...
- login.<%= properties.domain %>
- '*.login.<%= properties.domain %>'
...

See:
https://github.com/cloudfoundry/cf-release/blob/master/jobs/uaa/templates/cf-registrar.config.yml.erb

This prevents us from taking over login. We locally removed those list
items and our custom login server does continue to work. We have some
questions about the right approach going forward though.

Are uaa and the login server going to continue to merge: to the point where
we can no longer take over the login subdomain? Will this strategy no
longer be feasible? What's the right answer non ldap/saml environments, if
the uaa project's roadmap makes this replacement impossible?

If our current solution will continue to work for the foreseeable future,
would the uaa team be amenable to a pull-request making the uri values
configurable, so we can continue to take over the login subdomain?

-Matt Cholick

221 - 240 of 9378