Date   

max length with Dropped log message: message too long (>64K ...)

James Bayer
 

erik,

is there a set of tests for log message length?

---------- Forwarded message ----------
From: Koper, Dies <diesk(a)fast.au.fujitsu.com>
Date: Thu, Aug 20, 2015 at 1:17 PM
Subject: [cf-dev] max length with Dropped log message: message too long
(>64K ...)
To: "cf-dev(a)lists.cloudfoundry.org" <cf-dev(a)lists.cloudfoundry.org>


Hi,



When my app outputs more than 64K of text, I get a message “Dropped *log*
message: message too long (>*64K* without a newline).

When my app outputs much less than 64K of text, I get the app’s output.

When my app outputs just under 64K of text, nothing is output: neither the
error message, nor the app’s output.



What is exactly the limit under which output is still guaranteed, and can
we update the error message accordingly?



I tried to read the source code. Not sure if the limit is because messages
are sent over UDP (UDP max data length is 65,507), or due to other data
that is included in the transmission of messages (timestamp, app id, etc.).



Cheers,

Dies Koper





--
Thank you,

James Bayer


Re: I'm getting different x_forwarded_for in my Gorouter access logs depending on what browser/cli-tool I use.

Christopher Piraino <cpiraino@...>
 

Ah I see the problem. Nice find.

I'll await reply from Golang devs, but I'm wondering how much of a problem
this is for you? We could come up with a work around if this was hurting
you in some way.

- Chris

On Fri, Aug 21, 2015 at 3:00 AM, Simon Johansson <simon(a)simonjohansson.com>
wrote:

I have now asked in golang-nuts[1] . It might take up to 24h for my
message to appear, it will be called "Inconsistent X-Forwarded-For when
using the httputil.ReverseProxy ?"

[1] https://groups.google.com/forum/#!forum/golang-nuts


Re: UAA local run stuck at "cargoRunLocal"

Filip Hanik
 

ok, so UAA is pretty picky about the "host names" that come in.

by default only

localhost and *.localhost where * is a zone name are allowed.
There is a property that configures that called

zones:
internal:
hostnames:
- 127.0.0.1
- some.other.hostname

in uaa.yml

Filip

On Fri, Aug 21, 2015 at 3:50 PM, Alex Lam <alex.c.lam(a)intel.com> wrote:

Hi Filip,

It works now.
Does Tomcat only listen to "localhost"?
Can I not point a browser from another machine to Tomcat?

thanks,
alex


Re: UAA local run stuck at "cargoRunLocal"

Alex Lam
 

Hi Filip,

It works now.
Does Tomcat only listen to "localhost"?
Can I not point a browser from another machine to Tomcat?

thanks,
alex


Re: UAA local run stuck at "cargoRunLocal"

Alex Lam
 

Hi Filip,

$ java -version
java version "1.8.0_60"
Java(TM) SE Runtime Environment (build 1.8.0_60-b27)
Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23, mixed mode)

$ javac -version
javac 1.8.0_60


And one thing, I want to add... the sad_cloud.png logo in the "Uh oh, something went amiss" page did not come out either. Perhaps the path to certain resources are broken?

And here are latest output from a "clean assemble run --info"

Press Ctrl-C to stop the container...
[2015-08-21 14:37:14.647] cloudfoundry-identity-uaa - ???? [http-bio-8080-exec-2] .... DEBUG --- UaaRequestMatcher: [loginAuthenticateRequestMatcher] Checking match of request : '/uaa/'; '/uaa/authenticate' with parameters={} and headers {Authorization=[bearer ], accept=[application/json]}
[2015-08-21 14:37:14.655] cloudfoundry-identity-uaa - ???? [http-bio-8080-exec-2] .... DEBUG --- UaaRequestMatcher: [loginAuthorizeRequestMatcher] Checking match of request : '/uaa/'; '/uaa/oauth/authorize' with parameters={source=login} and headers {accept=[application/json]}
[2015-08-21 14:37:14.656] cloudfoundry-identity-uaa - ???? [http-bio-8080-exec-2] .... DEBUG --- UaaRequestMatcher: [loginTokenRequestMatcher] Checking match of request : '/uaa/'; '/uaa/oauth/token' with parameters={source=login, grant_type=password, add_new=} and headers {Authorization=[bearer ], accept=[application/json]}
[2015-08-21 14:37:14.656] cloudfoundry-identity-uaa - ???? [http-bio-8080-exec-2] .... DEBUG --- UaaRequestMatcher: [loginAuthorizeRequestMatcherOld] Checking match of request : '/uaa/'; '/uaa/oauth/authorize' with parameters={login={} and headers {accept=[application/json]}
[2015-08-21 14:37:14.656] cloudfoundry-identity-uaa - ???? [http-bio-8080-exec-2] .... DEBUG --- UaaRequestMatcher: [passcodeTokenMatcher] Checking match of request : '/uaa/'; '/uaa/oauth/token' with parameters={grant_type=password, passcode=} and headers {accept=[application/json, application/x-www-form-urlencoded]}
[2015-08-21 14:37:14.657] cloudfoundry-identity-uaa - ???? [http-bio-8080-exec-2] .... DEBUG --- UaaRequestMatcher: [oauthAuthorizeRequestMatcher] Checking match of request : '/uaa/'; '/uaa/oauth/authorize' with parameters={response_type=token, source=credentials} and headers {accept=[application/json, application/x-www-form-urlencoded]}
[2015-08-21 14:37:14.657] cloudfoundry-identity-uaa - ???? [http-bio-8080-exec-2] .... DEBUG --- UaaRequestMatcher: [oauthAuthorizeRequestMatcherOld] Checking match of request : '/uaa/'; '/uaa/oauth/authorize' with parameters={response_type=token, credentials={} and headers {accept=[application/json, application/x-www-form-urlencoded]}
[2015-08-21 14:37:14.657] cloudfoundry-identity-uaa - ???? [http-bio-8080-exec-2] .... DEBUG --- UaaRequestMatcher: [autologinAuthorizeRequestMatcher] Checking match of request : '/uaa/'; '/uaa/oauth/authorize' with parameters={response_type=code, code=} and headers {}
[2015-08-21 14:37:14.818] cloudfoundry-identity-uaa - ???? [http-bio-8080-exec-2] .... INFO --- TemplateEngine: [THYMELEAF] INITIALIZING TEMPLATE ENGINE
[2015-08-21 14:37:14.927] cloudfoundry-identity-uaa - ???? [http-bio-8080-exec-2] .... INFO --- AbstractTemplateResolver: [THYMELEAF] INITIALIZING TEMPLATE RESOLVER: org.thymeleaf.templateresolver.TemplateResolver
[2015-08-21 14:37:14.927] cloudfoundry-identity-uaa - ???? [http-bio-8080-exec-2] .... INFO --- AbstractTemplateResolver: [THYMELEAF] TEMPLATE RESOLVER INITIALIZED OK
[2015-08-21 14:37:14.927] cloudfoundry-identity-uaa - ???? [http-bio-8080-exec-2] .... INFO --- AbstractMessageResolver: [THYMELEAF] INITIALIZING MESSAGE RESOLVER: org.thymeleaf.spring4.messageresolver.SpringMessageResolver
[2015-08-21 14:37:14.928] cloudfoundry-identity-uaa - ???? [http-bio-8080-exec-2] .... INFO --- AbstractMessageResolver: [THYMELEAF] MESSAGE RESOLVER INITIALIZED OK
[2015-08-21 14:37:14.932] cloudfoundry-identity-uaa - ???? [http-bio-8080-exec-2] .... INFO --- CONFIG: [THYMELEAF] TEMPLATE ENGINE CONFIGURATION:
[THYMELEAF] * Cache Factory implementation: org.thymeleaf.cache.StandardCacheManager
[THYMELEAF] * Template modes:
[THYMELEAF] * VALIDXML
[THYMELEAF] * HTML5
[THYMELEAF] * XML
[THYMELEAF] * LEGACYHTML5
[THYMELEAF] * VALIDXHTML
[THYMELEAF] * XHTML
[THYMELEAF] * Template resolvers (in order):
[THYMELEAF] * org.thymeleaf.templateresolver.TemplateResolver
[THYMELEAF] * Message resolvers (in order):
[THYMELEAF] * org.thymeleaf.spring4.messageresolver.SpringMessageResolver
[THYMELEAF] * Dialect [1 of 3]: org.thymeleaf.spring4.dialect.SpringStandardDialect
[THYMELEAF] * Prefix: "th"
[THYMELEAF] * Dialect [2 of 3]: nz.net.ultraq.thymeleaf.LayoutDialect
[THYMELEAF] * Prefix: "layout"
[THYMELEAF] * Dialect [3 of 3]: org.thymeleaf.extras.springsecurity3.dialect.SpringSecurityDialect
[THYMELEAF] * Prefix: "sec"
[THYMELEAF] TEMPLATE ENGINE CONFIGURED OK
[2015-08-21 14:37:14.932] cloudfoundry-identity-uaa - ???? [http-bio-8080-exec-2] .... INFO --- TemplateEngine: [THYMELEAF] TEMPLATE ENGINE INITIALIZED
[2015-08-21 14:37:19.620] cloudfoundry-identity-uaa/uaa - ???? [ZoneAwareMetadataManager.Refresh[metadata]] .... DEBUG --- ZoneAwareMetadataManager: Running SAML IDP refresh[ZoneAwareMetadataManager.Refresh[metadata]-107518315] - ignoreTimestamp=false

thanks,
alex


Re: UAA local run stuck at "cargoRunLocal"

Filip Hanik
 

hi Alex, can you confirm that.

java -version
javac -version

both return Java 8

"Uh oh, something went amiss" means that Tomcat is indeed up, but the app
is not working.

So try

./gradlew clean assemble run --info


Filip

On Fri, Aug 21, 2015 at 3:07 PM, Alex Lam <alex.c.lam(a)intel.com> wrote:

and http://localhost:8080/uaa
returned the same


Uh oh.
Something went amiss.

© 2015 Pivotal Software, Inc. All Rights Reserved.


Re: UAA local run stuck at "cargoRunLocal"

Alex Lam
 

and http://localhost:8080/uaa
returned the same


Uh oh.
Something went amiss.

© 2015 Pivotal Software, Inc. All Rights Reserved.


Re: UAA local run stuck at "cargoRunLocal"

Alex Lam
 

Hi Filip,

Yes, the "--info" help to know tomcat is up @ 8080.
However, it's still aint working properly..
I see this on my browser..

Uh oh.
Something went amiss.

© 2015 Pivotal Software, Inc. All Rights Reserved.

And these are the logs on the console.

[2015-08-21 14:01:10.154] cloudfoundry-identity-uaa - ???? [http-bio-8080-exec-5] .... DEBUG --- UaaRequestMatcher: [loginAuthenticateRequestMatcher] Checking match of request : '/uaa/login'; '/uaa/authenticate' with parameters={} and headers {Authorization=[bearer ], accept=[application/json]}
[2015-08-21 14:01:10.154] cloudfoundry-identity-uaa - ???? [http-bio-8080-exec-5] .... DEBUG --- UaaRequestMatcher: [loginAuthorizeRequestMatcher] Checking match of request : '/uaa/login'; '/uaa/oauth/authorize' with parameters={source=login} and headers {accept=[application/json]}
[2015-08-21 14:01:10.154] cloudfoundry-identity-uaa - ???? [http-bio-8080-exec-5] .... DEBUG --- UaaRequestMatcher: [loginTokenRequestMatcher] Checking match of request : '/uaa/login'; '/uaa/oauth/token' with parameters={source=login, grant_type=password, add_new=} and headers {Authorization=[bearer ], accept=[application/json]}
[2015-08-21 14:01:10.155] cloudfoundry-identity-uaa - ???? [http-bio-8080-exec-5] .... DEBUG --- UaaRequestMatcher: [loginAuthorizeRequestMatcherOld] Checking match of request : '/uaa/login'; '/uaa/oauth/authorize' with parameters={login={} and headers {accept=[application/json]}
[2015-08-21 14:01:10.155] cloudfoundry-identity-uaa - ???? [http-bio-8080-exec-5] .... DEBUG --- UaaRequestMatcher: [passcodeTokenMatcher] Checking match of request : '/uaa/login'; '/uaa/oauth/token' with parameters={grant_type=password, passcode=} and headers {accept=[application/json, application/x-www-form-urlencoded]}
[2015-08-21 14:01:10.155] cloudfoundry-identity-uaa - ???? [http-bio-8080-exec-5] .... DEBUG --- UaaRequestMatcher: [oauthAuthorizeRequestMatcher] Checking match of request : '/uaa/login'; '/uaa/oauth/authorize' with parameters={response_type=token, source=credentials} and headers {accept=[application/json, application/x-www-form-urlencoded]}
[2015-08-21 14:01:10.155] cloudfoundry-identity-uaa - ???? [http-bio-8080-exec-5] .... DEBUG --- UaaRequestMatcher: [oauthAuthorizeRequestMatcherOld] Checking match of request : '/uaa/login'; '/uaa/oauth/authorize' with parameters={response_type=token, credentials={} and headers {accept=[application/json, application/x-www-form-urlencoded]}
[2015-08-21 14:01:10.156] cloudfoundry-identity-uaa - ???? [http-bio-8080-exec-5] .... DEBUG --- UaaRequestMatcher: [autologinAuthorizeRequestMatcher] Checking match of request : '/uaa/login'; '/uaa/oauth/authorize' with parameters={response_type=code, code=} and headers {}
[2015-08-21 14:01:30.557] cloudfoundry-identity-uaa/uaa - ???? [ZoneAwareMetadataManager.Refresh[metadata]] .... DEBUG --- ZoneAwareMetadataManager: Running SAML IDP refresh[ZoneAwareMetadataManager.Refresh[metadata]-1297020509] - ignoreTimestamp=false


Re: UAA local run stuck at "cargoRunLocal"

Filip Hanik
 

and yes, you will see gradle stuck on

Tomcat 7.x started on port [8080]
[ant:cargo] Press Ctrl-C to stop the container...
Press Ctrl-C to stop the container...
Building 97% > :cargoRunLocal
Until you hit Ctrl+C

Filip


On Fri, Aug 21, 2015 at 2:48 PM, Filip Hanik <fhanik(a)pivotal.io> wrote:

./gradlew run --info

The --info flag will print out the UAA and Tomcat logs to screen.

the server will then be accessible on http://localhost:8080/uaa



On Fri, Aug 21, 2015 at 2:43 PM, Alex Lam <alex.c.lam(a)intel.com> wrote:

Can someone shed some light on why my UAA local run got stuck at
cargoRunLocal?
I don't think the service is up because I don't see anything listening to
port 8080.

When I did a Ctrl-C, everything ended.

I am using Oracle Java 1.8

thanks,
alex

:cargoRunLocal
Press Ctrl-C to stop the container...
:cargoRunLocal took 254765ms
:run
:run took 0ms

BUILD SUCCESSFUL

Total time: 6 mins 27.502 secs
Task timings:
642ms :cloudfoundry-identity-common:compileJava
690ms :cloudfoundry-identity-common:processResources
1279ms :cloudfoundry-identity-common:jar
19984ms :cloudfoundry-identity-common:javadoc
946ms :cloudfoundry-identity-common:javadocJar
3346ms :cloudfoundry-identity-scim:compileJava
1213ms :cloudfoundry-identity-login:compileJava
4263ms :cloudfoundry-identity-scim:javadoc
4022ms :cloudfoundry-identity-login:javadoc
11868ms :cloudfoundry-identity-uaa:war
3286ms
:cloudfoundry-identity-samples:cloudfoundry-identity-api:javadoc
7085ms :cloudfoundry-identity-samples:cloudfoundry-identity-api:war
1969ms
:cloudfoundry-identity-samples:cloudfoundry-identity-app:javadoc
6920ms :cloudfoundry-identity-samples:cloudfoundry-identity-app:war
254765ms :cargoRunLocal


Re: UAA local run stuck at "cargoRunLocal"

Filip Hanik
 

./gradlew run --info

The --info flag will print out the UAA and Tomcat logs to screen.

the server will then be accessible on http://localhost:8080/uaa

On Fri, Aug 21, 2015 at 2:43 PM, Alex Lam <alex.c.lam(a)intel.com> wrote:

Can someone shed some light on why my UAA local run got stuck at
cargoRunLocal?
I don't think the service is up because I don't see anything listening to
port 8080.

When I did a Ctrl-C, everything ended.

I am using Oracle Java 1.8

thanks,
alex

:cargoRunLocal
Press Ctrl-C to stop the container...
:cargoRunLocal took 254765ms
:run
:run took 0ms

BUILD SUCCESSFUL

Total time: 6 mins 27.502 secs
Task timings:
642ms :cloudfoundry-identity-common:compileJava
690ms :cloudfoundry-identity-common:processResources
1279ms :cloudfoundry-identity-common:jar
19984ms :cloudfoundry-identity-common:javadoc
946ms :cloudfoundry-identity-common:javadocJar
3346ms :cloudfoundry-identity-scim:compileJava
1213ms :cloudfoundry-identity-login:compileJava
4263ms :cloudfoundry-identity-scim:javadoc
4022ms :cloudfoundry-identity-login:javadoc
11868ms :cloudfoundry-identity-uaa:war
3286ms :cloudfoundry-identity-samples:cloudfoundry-identity-api:javadoc
7085ms :cloudfoundry-identity-samples:cloudfoundry-identity-api:war
1969ms :cloudfoundry-identity-samples:cloudfoundry-identity-app:javadoc
6920ms :cloudfoundry-identity-samples:cloudfoundry-identity-app:war
254765ms :cargoRunLocal


UAA local run stuck at "cargoRunLocal"

Alex Lam
 

Can someone shed some light on why my UAA local run got stuck at cargoRunLocal?
I don't think the service is up because I don't see anything listening to port 8080.

When I did a Ctrl-C, everything ended.

I am using Oracle Java 1.8

thanks,
alex

:cargoRunLocal
Press Ctrl-C to stop the container...
:cargoRunLocal took 254765ms
:run
:run took 0ms

BUILD SUCCESSFUL

Total time: 6 mins 27.502 secs
Task timings:
642ms :cloudfoundry-identity-common:compileJava
690ms :cloudfoundry-identity-common:processResources
1279ms :cloudfoundry-identity-common:jar
19984ms :cloudfoundry-identity-common:javadoc
946ms :cloudfoundry-identity-common:javadocJar
3346ms :cloudfoundry-identity-scim:compileJava
1213ms :cloudfoundry-identity-login:compileJava
4263ms :cloudfoundry-identity-scim:javadoc
4022ms :cloudfoundry-identity-login:javadoc
11868ms :cloudfoundry-identity-uaa:war
3286ms :cloudfoundry-identity-samples:cloudfoundry-identity-api:javadoc
7085ms :cloudfoundry-identity-samples:cloudfoundry-identity-api:war
1969ms :cloudfoundry-identity-samples:cloudfoundry-identity-app:javadoc
6920ms :cloudfoundry-identity-samples:cloudfoundry-identity-app:war
254765ms :cargoRunLocal


Re: Using s3 for blobstore bucket prefix

Rich Wohlstadter
 

Thanks for the confirmation. Guess for now we will use 4 buckets. Hopefully this could be an added feature in the future.

-Rich


Re: Is spiff dead?

Amit Kumar Gupta
 

Spiff is not currently replaced by another tool, but it is not the ideal
tool for the job (too many features to shoot yourself in the foot with, not
enough features about BOSH knowledge, and just some general awkward hoops
it makes you jump through). We have it on our roadmap to improve manifest
generation, so we're not investing more activity into spiff that will slow
our progress towards where we eventually want to end up. For now, manifest
generation remains the same, and we will aim to introduce improvements in a
smooth manner.

A great majority of the improvements in manifest generation will come from
BOSH itself. See the bosh-notes for a list of current and upcoming
features (https://github.com/cloudfoundry/bosh-notes). Specifically the
list under the "Deployment configuration" heading in the README. Those
features open up some exciting possibilities for how simple manifest might
become.

Best,
Amit, Release Integration (MEGA) team PM

On Thu, Aug 20, 2015 at 11:29 PM, Kei YAMAZAKI <daydream.yamazaki(a)gmail.com>
wrote:

Hi all,

I consider use the spiff to manage a lot of manifest.
But I found statement that the spiff is not under active development.

https://github.com/cloudfoundry-incubator/spiff/commit/e7af3990e58b7390826b606d6de76ea576d9ad4f

Manifest management is very complex and cf-release has same problem (
diego-release also ).
I think the spiff is unable to resolve this problem completely and I
recognize the mega team is working on this problem.

So I have questions,
- Is spiff replaced by other tool?
- How to manage manifest files in the mega team.

Thanks,


Update Dashboard URL with Asynchronous Provisioning

Robert Moss
 

Hi,

My service broker provisions a service asynchronously but doesn't get the
management url until the service is provisioned. Currently the poll to the
endpoint /{instanceId}/last_operation doesn't return this field in its body
to update the service. Is there any other way to update the service when
this value becomes available?

Robert

--
Cloudsoft Corporation Limited, Registered in Scotland No: SC349230.
Registered Office: 13 Dryden Place, Edinburgh, EH9 1RP

This e-mail message is confidential and for use by the addressee only. If
the message is received by anyone other than the addressee, please return
the message to the sender by replying to it and then delete the message
from your computer. Internet e-mails are not necessarily secure. Cloudsoft
Corporation Limited does not accept responsibility for changes made to this
message after it was sent.

Whilst all reasonable care has been taken to avoid the transmission of
viruses, it is the responsibility of the recipient to ensure that the
onward transmission, opening or use of this message and any attachments
will not adversely affect its systems or data. No responsibility is
accepted by Cloudsoft Corporation Limited in this regard and the recipient
should carry out such virus and other checks as it considers appropriate.


Re: I'm getting different x_forwarded_for in my Gorouter access logs depending on what browser/cli-tool I use.

Simon Johansson <simon@...>
 

I have now asked in golang-nuts[1] . It might take up to 24h for my message to appear, it will be called "Inconsistent X-Forwarded-For when using the httputil.ReverseProxy ?"

[1] https://groups.google.com/forum/#!forum/golang-nuts


Re: CF integration with logger and monitoring tools

Swatz bosh
 

Thanks James.

So for Wily introscope( wily-agent based monitoring tool) integration, if I go with firehose approach, I need to write my own nozzle for Introscope like for datadog ?

https://github.com/cloudfoundry-incubator/datadog-firehose-nozzle

I am assuming that I will be using dea-agent to fetch metrics and logs instead of wily-agent?

My introscope nozzle will call doppler to fetch metrics and Introscope forwarder will forward it to Introscope Enterprise Manager (a server which has web-client to access metrics dashboard) ?


Is spiff dead?

Kei YAMAZAKI
 

Hi all,

I consider use the spiff to manage a lot of manifest.
But I found statement that the spiff is not under active development.
https://github.com/cloudfoundry-incubator/spiff/commit/e7af3990e58b7390826b606d6de76ea576d9ad4f

Manifest management is very complex and cf-release has same problem ( diego-release also ).
I think the spiff is unable to resolve this problem completely and I recognize the mega team is working on this problem.

So I have questions,
- Is spiff replaced by other tool?
- How to manage manifest files in the mega team.

Thanks,


App syslog drain performance improvements

Erik Jasiak
 

Hi CF community,

The Loggregator team has two medium-impact changes as part of CF v215.

* First, we fixed a bug causing slower performance with application
syslog drains. [1][2] The impact is that doppler should stream
application log messages much faster, and by default you should see
fewer “We’ve dropped 100 messages” problems, and related scalability issues.

** Special thanks to Daniel Jones / “EngineerBetter” in the CF community
for identifying the issue - it’s fantastic to see this level of
investigation and participation in the code base, which is what open
source is all about.

* Second, the buffer size for a Doppler is now configurable in bosh for
loggregator dopplers. The number of messages to buffer in doppler is
configurable as:

doppler.message_drain_buffer_size = 100

The default buffer size for dopplers is still set to 100 messages for
now, while we evaluate the effectiveness of fixing the latency bug.
However, we would appreciate feedback from those that do re-configure
their buffer sizes.

Known impacts of reconfiguring buffer size:

1) Memory usage from increased buffer analyzed, please see story[3].
Overhead of upping size appears to be minor, but if you have a different
experience please let us know.
2) When buffer size increased, falling behind a doppler runs the risk of
a much larger number of dropped messages.

Thank you all, and happy loggregating!

Erik Jasiak
PM, Loggregator team

[1] https://www.pivotaltracker.com/n/projects/993188/stories/99494586
[2] https://github.com/cloudfoundry/loggregator/pull/71
[3] https://www.pivotaltracker.com/story/show/100163298


Re: Overcommit on Diego Cells

Mike Youngstrom
 

Thanks Will.

If btrfs does free disk space then I can just use the bosh ephemeral disk
metric to monitor. If it doesn't then I'll need Garden to provide me with
something.

Thanks,
Mike

On Thu, Aug 20, 2015 at 10:58 AM, Will Pragnell <wpragnell(a)pivotal.io>
wrote:

Apparently my last reply to this thread never made it through. Hope this
one does!

Mike, you're right that there are currently no btrfs metrics being emitted
from garden-linux. There are currently no immediate plans to implement
this, but clearly such metrics are useful, so I'll raise this with the team
and see where we land.

As for your question about btrfs freeing disk space, I'm afraid I don't
know off hand. I'll have to do some investigation and get back to you on
that next week.

On 19 August 2015 at 23:46, Mike Youngstrom <youngm(a)gmail.com> wrote:

Thanks for the response Eric. It was very helpful.

One last question. Any thoughts on what would be the best way to monitor
free ephemeral disk space in my overcommitted situation? If using
btrfs_store_size_mb=-1 will btrfs free ephemeral disk space when less is
being used or does it just grow when it needs more? Looking at firehose
stats in 1398 I don't see any btrfs usage metrics being sent from
garden-linux.

Thanks,
Mike

On Mon, Aug 17, 2015 at 9:14 PM, Eric Malm <emalm(a)pivotal.io> wrote:

Hi, Mike,

Apologies, I emailed this to cf-dev a few days ago, but it seems not to
have gone through. Anyway, thanks for asking about the different
configuration values Diego exposes for disk and memory. Yes, you can use
the 'diego.executor.memory_capacity_mb' and
'diego.executor.disk_capacity_mb' properties to specify overcommits in
absolute terms rather than the relative factors configurable on the DEAs.
The cell reps will advertise those values as their maximum memory and disk
capacity, and subtract memory and disk for allocated containers when
reporting their available capacity during auctions.

The 'btrfs_store_size_mb' property on garden-linux is more of a moving
target as garden-linux settles in on that filesystem as a backing store. As
of garden-linux-release 0.292.0, which diego-release 0.1412.0 and later
consume, that property accepts a '-1' value that allows it to grow up to
the full size of the available disk on the /var/vcap/data ephemeral disk
volume. The btrfs volume itself is sparse, so it will start at effectively
zero size and grow as needed to accommodate the container layers. Since
you're already monitoring disk usage on your VMs carefully and scaling out
when you hit certain limits, this might be a good option for you. This is
also effectively how the DEAs operate today, without an explicit limit on
the total amount of disk they allocate for containers.

If you do want more certainty in the maximum size that the garden-linux
btrfs volume will grow to, or if you're on a version of diego-release
earlier than 0.1412.0, you should set btrfs_store_size_mb to a positive
value, and garden-linux will create the volume to grow only up to that
size. One strategy to determine that value would be to use the maximum size
of the ephemeral disk, less the size of the BOSH-deployed packages (for the
executor, currently around 1.3 GB, including the untarred cflinuxfs2
rootfs), less the size allocated to the executor cache in the
'diego.executor.max_cache_size_in_bytes' property (which currently defaults
to 10GB).

Best,
Eric


Re: Using s3 for blobstore bucket prefix

CF Runtime
 

Currently there is no way to use a single bucket with prefixes for the
different blobstores. In theory you could point them all at the same bucket
and nothing would break, but you'd probably regret that some day when you
wanted to clean out the resource matching blobstore or something like that.

Joseph
OSS Release Integration Team

On Thu, Aug 20, 2015 at 11:58 AM, Rich Wohlstadter <lethwin(a)gmail.com>
wrote:

Hi,

I'm trying to setup so that cloud controller uses s3 for blobstore in
AWS. I can get it working by supplying bucket names in the relevant key
fields(resource_directory_key,etc). Want I wanted to know is if there is
anyway we can supply prefix's. For instance, I want to use the same bucket
for droplets, buildpacks, etc and organize them as so:

mybucket/prod/cc-buildpacks for buildpacks
mybucket/prod/cc-droplets for droplets
mybucket/prod/cc-packages for packages
mybucket/prod/cc-resources for resources

Just cant find a way to specify the prefix's so I don't have to create 4
buckets. Any way to do this?

Thanks,

Rich

8081 - 8100 of 9426