Hi, Tom, Thanks for asking. The Diego team has a semi-supported tool called 'veritas' (at https://github.com/pivotal-cf-experimental/veritas) that can give similar sorts of diagnostics on the command

> what will be the scope for securing internal Abacus pipeline that Assk describes as system token ? It is 'abacus.usage.write'. Updated my previous statements to make it more specific: We have

Makes sense, and just to complete - what will be the scope for securing internal Abacus pipeline that Assk describes as system token ? Piotr

Since usage reporting service is reporting usage for an account, for an organization or for a set of organizations, Abacus delegates the authorization to account and organization information resource

Thanks that's a really nice job !

Throwing this out there for anyone who might find it useful. https://github.com/epoelke/rds-service-broker

Hi, thanks for your reply. I understood that "application_version" is mainly used by CF components so I cannot used it as an actual version of application. Thanks. Hiroaki UKAJI -- View this

Hey Piotr, To read usage I believe you'll need 'abacus.usage.read', as 'abacus.usage.write' is for, well... writing. P.S. That reminds me of a period of my life long time ago when I was a contractor

Hi Ponraj, It could be that your token may have expired. Also, silly question but you may want to check that you have access to the app in question. A good way to verify this is by running `cf logs

Assk, can you confirm that the same scope (abacus.usage.write) is sufficient to retrieve usage ? Piotr

We have enabled scope based authorization for REST endpoints at usage collector and usage reporting service. While we are working on using system OAuth bearer access token at internal Abacus pipeline,

Hi Ben, I'm adding a 'processed' time field to the usage docs, hoping that'll help maintain the history of usage within the slack window we've been discussing here (more precisely that will help you

Great! Thanks Jim. Sounds completely reasonable. Hopefully we can keep this thread moving and help derive some future designs out of it. Would you prefer to keep this discussion on the mailling

We are using it. Though we plan to fix this. If we could get a general timeline for what release you plan to remove it in then we can plan to remove it from our code by then. Mike

As many of you are aware, the Cloud Foundry Java Client has been a bit neglected lately. There are various reasons for this, but today I’m pleased to announce that we’ve begun a V2 effort and

New Loggregator PM chiming in. This is definitely on the Loggregator roadmap. Only issues are selecting a design and finalizing (as much as is ever possible) where it lives in the priority order. We

Thanks Phil! I couldn't make the call so this saved my bacon. Mike alexander.lomov(a)altoros.com> wrote:

Any thoughts on what protocol this socket would listen too? Raw Dropsonde? Syslog? I've been thinking about your questions regarding the '\' approach: As Erik mentioned in the last thread,

There's no technical reason why it can't be used for deployments, but there are plenty of bug and security fixes that have gone out in later releases. Joseph CF Release Integration Team

application_version is mostly an internal cloud foundry concern. The DEAs broadcast the application version they are running, and the health manager uses that with what version it expects to be