Date   

Re: PLEASE READ: BOSH-Lite stemcell broken

Amit Kumar Gupta
 

This also affects work on the Routing API which relies on Consul to talk to
the UAA, entirely independent of Diego.

On Mon, Nov 30, 2015 at 3:50 PM, Dmitriy Kalinin <dkalinin(a)pivotal.io>
wrote:

we only pull stemcells in rare cases when something essential is broken
that affects everything. only diego-release is affected in this case due to
its usage of certain dns system files.

we will be issuing a new stemcell soon. it's been taking longer than
expected due to integration between bosh and garden-linux and how dns is
configured.

On Mon, Nov 30, 2015 at 3:15 PM, Kris Hicks <khicks(a)pivotal.io> wrote:

And why hasn't this stemcell been pulled yet?

KH

On Mon, Nov 30, 2015 at 3:07 PM, David Protasowski <
dprotasowski(a)pivotal.io> wrote:

When can we expect an updated stem cell?

On Mon, Nov 30, 2015 at 4:15 PM Warren Fernandes <wfernandes(a)pivotal.io>
wrote:

Thanks Amit.

This might solve our problem. We are seeing problems deploying
diego-release on bosh-lite with stemcell 3126.



On Mon, Nov 30, 2015 at 12:43 PM, Amit Gupta <agupta(a)pivotal.io> wrote:

Hey all,

TL;DR: Please DO NOT use BOSH-Lite stemcell 3126 for local development
or CI, use the previous version, 2776.

This issue has been announced multiple times before, but people are
still hitting it. Unfortunately it's a hard issue to diagnose, and by the
time it happens you might not remember this email, but several different
users and core CF development teams have sunk a fair bit of time tripping
over this so apologies for the alarmist subject line.

BOSH-Lite stemcell 3126 is not compatible with consul-release. This
only affects certain use cases, but it's recommended to err on the side of
caution and not use this stemcell. Use 2776 for local development, and if
you're deploying to BOSH-Lite in your CI pipelines, and you're pulling in
the latest stemcell, make sure you don't pull in 3126. If you're using
Concourse for CI, it's very simple to disable a particular version of a
resource.

If you'd like a more nuanced explanation of what the issue is, and
whether or not it's likely to affect your use case, please feel free to ask.

Best,
Amit


Questions about /v2/events

Piotr Przybylski <piotrp@...>
 

Hi,
I have couple of questions related to events that I could not find in the docs. 
There are two /v2/events defined in the docs [1] - audit.app.start and audit.app.stop that don't seem to be
emitted - at least for cf 221. Is there a specific scenario to get these triggered? When starting the application 
we get the audit.app.update with {"request":{"state":"STARTED"}} (and app usage event). 

The audit.app.update event is emitted for several user actions - above start/stop, rename, application push - is
there a way to differentiate between all these actions ? Sometimes it can be done using metadata of the 
event, eg start/stop but others have just the application name in the event metadata (push and rename). 
Piotr



Re: Go router and NTAS behavior

Mark St.Godard
 

Also bosh / monit scripts would handle case in which if gorouter starts up
but if NATS is unavailable (for some reason), once NATS becomes healthy,
gorouter will eventually be restarted via monit scripts and connect to NATS

For example, on bosh-lite, ssh into nats_z1, stop nats. Then ssh into
router_z1 and restart gorouter. It will fail since nats is down. The
gorouter process will not be running. Then start nats back up, and shortly
after you should see router_z1's gorouter start up and connect to NATS

Cheers


On Tue, Dec 1, 2015 at 9:24 AM, Mark St.Godard <markstgodard(a)gmail.com>
wrote:

Hi Minoru

This logic is just on initial startup of the gorouter. If a gorouter
instance starts up and connects to NATS server
but if NATS becomes temporarily unavailable, the gorouter instance will
not terminate.

Cheers

On Tue, Dec 1, 2015 at 4:16 AM, Nitta, Minoru <minoru.nitta(a)jp.fujitsu.com
wrote:
Hi all,

I have a question about GoRouter and NATs communication. According to the
source code
of Gorouter, GoRouter process exits when timeout occurs between the
connection to NATs.
That's because

https://github.com/cloudfoundry/gorouter/blob/master/main.go#L200-L203

I am wondering this behavior is reasonable. When timeout occurs between
NATS,
most probably all GoRouter processes would encounter the same problem,
which cause
all GoRouter processes down and severe high availability issues.

Regards,
Minoru


Re: Go router and NTAS behavior

Mark St.Godard
 

Hi Minoru

This logic is just on initial startup of the gorouter. If a gorouter
instance starts up and connects to NATS server
but if NATS becomes temporarily unavailable, the gorouter instance will not
terminate.

Cheers

On Tue, Dec 1, 2015 at 4:16 AM, Nitta, Minoru <minoru.nitta(a)jp.fujitsu.com>
wrote:

Hi all,

I have a question about GoRouter and NATs communication. According to the
source code
of Gorouter, GoRouter process exits when timeout occurs between the
connection to NATs.
That's because

https://github.com/cloudfoundry/gorouter/blob/master/main.go#L200-L203

I am wondering this behavior is reasonable. When timeout occurs between
NATS,
most probably all GoRouter processes would encounter the same problem,
which cause
all GoRouter processes down and severe high availability issues.

Regards,
Minoru


Re: Documentation on creating and deploying windows applications diego-windows-release

Vinay Vaidya
 

James, Thanks for the inputs. It took me a while to work on it.
I tried the app push but I am getting 'NoCompatbleCell' failure when starting. Here are the steps that I have followed:
1. Install the CF Diego release on bosh-vm
2. Install Diego-Windows-Release on another Win2012R2 server vm
3. Pushed the app with cf push APPNAME -s windows2012R2 -b binary_buildpack --no-start
4. Enabled diego for the app
5. Start the app

Here is the auctioneer log excerpt:
{"timestamp":"1448978418.765795946","source":"auctioneer","message":"auctioneer.request.serving","log_level":1,"data":{"method":"POST","request":"/v1/tasks","session":"8"}}
{"timestamp":"1448978418.766194105","source":"auctioneer","message":"auctioneer.request.task-auction-handler.create.submitted","log_level":1,"data":{"method":"POST","request":"/v1/tasks","session":"8.1.1","tasks":["902a58f7-efad-46b5-8569-6f962c84f03d-ef8e363bc9b34c86a397764aaeab9f16"]}}
{"timestamp":"1448978418.766262293","source":"auctioneer","message":"auctioneer.request.done","log_level":1,"data":{"method":"POST","request":"/v1/tasks","session":"8"}}
{"timestamp":"1448978418.766420841","source":"auctioneer","message":"auctioneer.auction.fetching-cell-reps","log_level":1,"data":{"session":"9"}}
{"timestamp":"1448978418.769232273","source":"auctioneer","message":"auctioneer.auction.fetched-cell-reps","log_level":1,"data":{"cell-reps-count":2,"session":"9"}}
{"timestamp":"1448978418.769321442","source":"auctioneer","message":"auctioneer.auction.fetching-zone-state","log_level":1,"data":{"session":"9"}}
{"timestamp":"1448978433.771463871","source":"auctioneer","message":"auctioneer.auction.failed-to-get-state","log_level":2,"data":{"cell-guid":"WIN-JQTPCVJ14JM","error":"Get http://10.0.3.15:1800/state: dial tcp 10.0.3.15:1800: i/o timeout","session":"9"}}
{"timestamp":"1448978433.771752357","source":"auctioneer","message":"auctioneer.auction.zone-state","log_level":1,"data":{"cell-count":1,"session":"9","zone":"z1"}}
{"timestamp":"1448978433.771788359","source":"auctioneer","message":"auctioneer.auction.fetched-zone-state","log_level":1,"data":{"cell-state-count":1,"duration":"15.002333005s","num-failed-requests":1,"session":"9"}}
{"timestamp":"1448978433.771812439","source":"auctioneer","message":"auctioneer.auction.fetching-auctions","log_level":1,"data":{"session":"9"}}
{"timestamp":"1448978433.771835566","source":"auctioneer","message":"auctioneer.auction.fetched-auctions","log_level":1,"data":{"lrp-start-auctions":0,"session":"9","task-auctions":1}}
{"timestamp":"1448978433.771849394","source":"auctioneer","message":"auctioneer.auction.scheduling","log_level":1,"data":{"session":"9"}}
{"timestamp":"1448978433.771918058","source":"auctioneer","message":"auctioneer.auction.scheduled","log_level":1,"data":{"failed-lrp-start-auctions":0,"failed-task-auctions":1,"session":"9","successful-lrp-start-auctions":0,"successful-task-auctions":0}}


Re: server error, Docker support has not been enabled --what did I miss?

Rohit Raghuvanshi
 

Hi,
I ran the coomand cf enable-feature-flag diego_docker but i am getting ' You are not authorized to perform the requested action'.

I have the admin access and I ran cf login before it. any suggestion ?


Go router and NTAS behavior

Nitta, Minoru <minoru.nitta@...>
 

Hi all,

I have a question about GoRouter and NATs communication. According to the source code
of Gorouter, GoRouter process exits when timeout occurs between the connection to NATs.
That's because

https://github.com/cloudfoundry/gorouter/blob/master/main.go#L200-L203

I am wondering this behavior is reasonable. When timeout occurs between NATS,
most probably all GoRouter processes would encounter the same problem, which cause
all GoRouter processes down and severe high availability issues.

Regards,
Minoru


Re: CF CLI v6.14.0 Released Today

Marco Voelz
 

On 23/11/15 18:56, "Dieu Cao" <dcao(a)pivotal.io<mailto:dcao(a)pivotal.io>> wrote:

To clarify the point above, a space manager can manage space level roles for any user of the organization. They will not be able to add users to the space if that user is not yet a member of the space's organization.

Thanks Dieu for clarifying this, I was a little confused when adding users to a Space with just the SpaceAdmin role didn't work here. Is that really the intended and expected behavior?

From a technical perspective, I guess this is because adding someone to a Space makes her a member of the Org by implication as well. And therefore the person adding needs to either have rights to modify the Org membership or the person being added needs to be member of the Org already? If this is going to stay like this, we probably have to think about our internal structuring of Orgs and Spaces.

This restriction isn't really reflected in the documentation, though, right [1]?

[1] http://docs.cloudfoundry.org/concepts/roles.html#space-roles

Thanks and warm regards
Marco


Re: Support for route services as forwarding proxies per HTTP RFC

Guillaume Berche
 

Hi Shannon,

I'm wondering whether my comment last thursday on the design doc went
unnoticed. In case the google doc notification settings need a fix, here is
a copy:







*Can the route service url still be using HTTPS protocol instead of plain
HTTP, as to preserve confidentiality of routed exchanges, in particular
when the route service is accessed through the internet ?Would the gorouter
then use the usual HTTP Upgrade to TLS as per
https://www.ietf.org/rfc/rfc2817.txt
<https://www.google.com/url?q=https://www.ietf.org/rfc/rfc2817.txt&sa=D&ust=1448920443296000&usg=AFQjCNG7Ma5Bgjn97bZkKaPVo6aCqaYzkg>
section 5.2 ?If this is the case, then I would expect off-the-shelf proxies
not the add the Via header to the request (i.e honor the RFC2817 specs).If
this is not the case (i.e. CONNECT tls upgrade is not requested), then the
expected behavior is closer to a reverse proxy than a forward proxy.
Wouldn't this defeat the purpose of using off-the shelf forward proxy
software/equipments ?*

Thanks,

Guillaume.

On Thu, Nov 26, 2015 at 12:02 AM, Mike Youngstrom <youngm(a)gmail.com> wrote:

As an F5 and CF user we wouldn't have an issue changing this setting. I
wonder if F5 had a good reason to set this to "Remove" by default?

Mike

On Wed, Nov 25, 2015 at 12:39 PM, Shannon Coen <scoen(a)pivotal.io> wrote:

The CF Routing team has nearly reached MVP for a feature called Route
Services. This feature extends the possibilities for how Marketplace
Services (and user-provided service instances) can extend the functionality
of the Cloud Foundry platform. By fulfilling integrations with the HTTP
routing tier in CF (Gorouters) and/or with the service broker API,
developers will be able to inject a marketplace service into their
application request path or dynamically configure a network component
already in the request path. This enables Marketplace Services to provide
API gateway features like rate limiting, authentication, request
transformation, logging, anaylytics, etc.

In support of the use case whereby a developer inserts a component into
the request path, the integration with the CF router requires service
authors to honor a few custom headers:

X-Cf-Forwarded-Url - The url to which the Route Service should forward
the request after processing.
X-Cf-Signature - An encrypted header used by the router to validate
requests and prevent loops. Route Services should not strip this header.
X-Cf-Metadata - Used by the router, in addition to a private key, to
decrypt the Signature header. Route Services should not strip this header.

Rather than use the custom X-Cf-Forwarded-Url header, we've been
exploring how we could support Route Services implemented as standardized
forwarding proxies per the HTTP RFC spec. Our proposal would require Route
Services to append their hostname to the *Via* header when forwarding
the request back to CF.

*Our primary concern is that the F5 load balancer will strip the Via
header by default [1]. Is it reasonable to require operators to switch this
setting from "Remove" to "Preserve", in order to support Route Services in
a CF deployment?*

We welcome your feedback; our proposal for this change is open for public
comment:
https://docs.google.com/document/d/1YYusMwGlAz91Mcd6gjZYiV_igkeAHRL-XedJPr10BZ8/edit#

[1]
https://support.f5.com/kb/en-us/products/wa/manuals/product/wa-concepts-11-2-0/18.html

Thank you,

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.


Updated our RDS service broker

Eric Poelke
 

If anyone is interested we updated our RDS service broker to support deploying a new DB instance from an existing DB snapshot. The main use case here was really to be able to have some prepopulated databases for projects as well as to easily make a copies of databases between environments with having to engage operations less. Currently you still need to get the snapshot name from a system operator but after that you can provision from snapshot.

https://github.com/epoelke/rds-service-broker/tree/v3


Re: PLEASE READ: BOSH-Lite stemcell broken

Dmitriy Kalinin <dkalinin@...>
 

we only pull stemcells in rare cases when something essential is broken
that affects everything. only diego-release is affected in this case due to
its usage of certain dns system files.

we will be issuing a new stemcell soon. it's been taking longer than
expected due to integration between bosh and garden-linux and how dns is
configured.

On Mon, Nov 30, 2015 at 3:15 PM, Kris Hicks <khicks(a)pivotal.io> wrote:

And why hasn't this stemcell been pulled yet?

KH

On Mon, Nov 30, 2015 at 3:07 PM, David Protasowski <
dprotasowski(a)pivotal.io> wrote:

When can we expect an updated stem cell?

On Mon, Nov 30, 2015 at 4:15 PM Warren Fernandes <wfernandes(a)pivotal.io>
wrote:

Thanks Amit.

This might solve our problem. We are seeing problems deploying
diego-release on bosh-lite with stemcell 3126.



On Mon, Nov 30, 2015 at 12:43 PM, Amit Gupta <agupta(a)pivotal.io> wrote:

Hey all,

TL;DR: Please DO NOT use BOSH-Lite stemcell 3126 for local development
or CI, use the previous version, 2776.

This issue has been announced multiple times before, but people are
still hitting it. Unfortunately it's a hard issue to diagnose, and by the
time it happens you might not remember this email, but several different
users and core CF development teams have sunk a fair bit of time tripping
over this so apologies for the alarmist subject line.

BOSH-Lite stemcell 3126 is not compatible with consul-release. This
only affects certain use cases, but it's recommended to err on the side of
caution and not use this stemcell. Use 2776 for local development, and if
you're deploying to BOSH-Lite in your CI pipelines, and you're pulling in
the latest stemcell, make sure you don't pull in 3126. If you're using
Concourse for CI, it's very simple to disable a particular version of a
resource.

If you'd like a more nuanced explanation of what the issue is, and
whether or not it's likely to affect your use case, please feel free to ask.

Best,
Amit


Re: PLEASE READ: BOSH-Lite stemcell broken

Kris Hicks <khicks@...>
 

And why hasn't this stemcell been pulled yet?

KH

On Mon, Nov 30, 2015 at 3:07 PM, David Protasowski <dprotasowski(a)pivotal.io>
wrote:

When can we expect an updated stem cell?

On Mon, Nov 30, 2015 at 4:15 PM Warren Fernandes <wfernandes(a)pivotal.io>
wrote:

Thanks Amit.

This might solve our problem. We are seeing problems deploying
diego-release on bosh-lite with stemcell 3126.



On Mon, Nov 30, 2015 at 12:43 PM, Amit Gupta <agupta(a)pivotal.io> wrote:

Hey all,

TL;DR: Please DO NOT use BOSH-Lite stemcell 3126 for local development
or CI, use the previous version, 2776.

This issue has been announced multiple times before, but people are
still hitting it. Unfortunately it's a hard issue to diagnose, and by the
time it happens you might not remember this email, but several different
users and core CF development teams have sunk a fair bit of time tripping
over this so apologies for the alarmist subject line.

BOSH-Lite stemcell 3126 is not compatible with consul-release. This
only affects certain use cases, but it's recommended to err on the side of
caution and not use this stemcell. Use 2776 for local development, and if
you're deploying to BOSH-Lite in your CI pipelines, and you're pulling in
the latest stemcell, make sure you don't pull in 3126. If you're using
Concourse for CI, it's very simple to disable a particular version of a
resource.

If you'd like a more nuanced explanation of what the issue is, and
whether or not it's likely to affect your use case, please feel free to ask.

Best,
Amit


Re: PLEASE READ: BOSH-Lite stemcell broken

David Protasowski <dprotasowski@...>
 

When can we expect an updated stem cell?
On Mon, Nov 30, 2015 at 4:15 PM Warren Fernandes <wfernandes(a)pivotal.io>
wrote:

Thanks Amit.

This might solve our problem. We are seeing problems deploying
diego-release on bosh-lite with stemcell 3126.



On Mon, Nov 30, 2015 at 12:43 PM, Amit Gupta <agupta(a)pivotal.io> wrote:

Hey all,

TL;DR: Please DO NOT use BOSH-Lite stemcell 3126 for local development or
CI, use the previous version, 2776.

This issue has been announced multiple times before, but people are still
hitting it. Unfortunately it's a hard issue to diagnose, and by the time
it happens you might not remember this email, but several different users
and core CF development teams have sunk a fair bit of time tripping over
this so apologies for the alarmist subject line.

BOSH-Lite stemcell 3126 is not compatible with consul-release. This only
affects certain use cases, but it's recommended to err on the side of
caution and not use this stemcell. Use 2776 for local development, and if
you're deploying to BOSH-Lite in your CI pipelines, and you're pulling in
the latest stemcell, make sure you don't pull in 3126. If you're using
Concourse for CI, it's very simple to disable a particular version of a
resource.

If you'd like a more nuanced explanation of what the issue is, and
whether or not it's likely to affect your use case, please feel free to ask.

Best,
Amit


Re: PLEASE READ: BOSH-Lite stemcell broken

Warren Fernandes
 

Thanks Amit.

This might solve our problem. We are seeing problems deploying
diego-release on bosh-lite with stemcell 3126.

On Mon, Nov 30, 2015 at 12:43 PM, Amit Gupta <agupta(a)pivotal.io> wrote:

Hey all,

TL;DR: Please DO NOT use BOSH-Lite stemcell 3126 for local development or
CI, use the previous version, 2776.

This issue has been announced multiple times before, but people are still
hitting it. Unfortunately it's a hard issue to diagnose, and by the time
it happens you might not remember this email, but several different users
and core CF development teams have sunk a fair bit of time tripping over
this so apologies for the alarmist subject line.

BOSH-Lite stemcell 3126 is not compatible with consul-release. This only
affects certain use cases, but it's recommended to err on the side of
caution and not use this stemcell. Use 2776 for local development, and if
you're deploying to BOSH-Lite in your CI pipelines, and you're pulling in
the latest stemcell, make sure you don't pull in 3126. If you're using
Concourse for CI, it's very simple to disable a particular version of a
resource.

If you'd like a more nuanced explanation of what the issue is, and whether
or not it's likely to affect your use case, please feel free to ask.

Best,
Amit


PLEASE READ: BOSH-Lite stemcell broken

Amit Kumar Gupta
 

Hey all,

TL;DR: Please DO NOT use BOSH-Lite stemcell 3126 for local development or
CI, use the previous version, 2776.

This issue has been announced multiple times before, but people are still
hitting it. Unfortunately it's a hard issue to diagnose, and by the time
it happens you might not remember this email, but several different users
and core CF development teams have sunk a fair bit of time tripping over
this so apologies for the alarmist subject line.

BOSH-Lite stemcell 3126 is not compatible with consul-release. This only
affects certain use cases, but it's recommended to err on the side of
caution and not use this stemcell. Use 2776 for local development, and if
you're deploying to BOSH-Lite in your CI pipelines, and you're pulling in
the latest stemcell, make sure you don't pull in 3126. If you're using
Concourse for CI, it's very simple to disable a particular version of a
resource.

If you'd like a more nuanced explanation of what the issue is, and whether
or not it's likely to affect your use case, please feel free to ask.

Best,
Amit


Provided service broker API version is not supported: Expected Version = 2.4, Provided Version = null

Mark Spielman
 

I'm trying to explore Cloud Foundry services. To start I wanted to get the sample spring-boot-cf-service-broker-mongo running. When I launch this in cloud foundry or even outside of cloud foundry as a spring boot application, I get the following response when I poll the catalog:

http://localhost:8080/v2/catalog

{"description":"The provided service broker API version is not supported: Expected Version = 2.4, Provided Version = null"}

I saw these docs on the spring-boot-cf-service-broker README:

API version verification

By default, spring-boot-cf-service-broker will verify the version of the service broker API for each request it receives. To disable service broker API version header verification, provide a BrokerApiVersion bean that accepts any API version:

@Bean
public BrokerApiVersion brokerApiVersion() {
return new BrokerApiVersion();
}

I figure, I must be failing to disable the version header verification. But I'm not sure where to provide the BrokerApiVersion bean in the spring-boot-cf-service-broker-mongo sample. Would anyone be able to give me a few more pointers.

Thanks
Mark


Re: Changing CF Encryption Keys (was Re: Re: Re: Re: Cloud Controller - s3 encryption for droplets)

Sandy Cash Jr <lhcash@...>
 

Hi Dieu,

I created https://github.com/cloudfoundry/cloud_controller_ng/issues/465
for this. See if that covers what you envision re: scope, etc., and let me
know if you think additional details are needed before I submit any PRs.

Thanks,

-Sandy


--
Sandy Cash
Certified Senior IT Architect/Senior SW Engineer
IBM BlueMix
lhcash(a)us.ibm.com
(919) 543-0209

"I skate to where the puck is going to be, not to where it has been.” -
Wayne Gretzky



From: Dieu Cao <dcao(a)pivotal.io>
To: "Discussions about Cloud Foundry projects and the system
overall." <cf-dev(a)lists.cloudfoundry.org>
Date: 11/13/2015 12:54 PM
Subject: [cf-dev] Re: Changing CF Encryption Keys (was Re: Re: Re: Re:
Cloud Controller - s3 encryption for droplets)



Hi Sandy,

Yes, I'm happy to help work through requirements on these via a github
issue in support of PRs to follow through on implementation.

-Dieu
CF CAPI PM

On Fri, Nov 13, 2015 at 6:44 AM, Sandy Cash Jr <lhcash(a)us.ibm.com> wrote:
Hi,

I'm not sure what strategies exist either. This same topic came up
partially in the context of my resubmitted FIPS proposal, and I was
curious - is it worth creating an issue (or even a separate feature
proposal/blueprint) for tooling to rotate encryption keys? It's
nontrivial (unless there is tooling about which I am unaware) to do, and
a good solution in this space would IMHO fill a significant operational
need.

Thoughts?

-Sandy


--
Sandy Cash
Certified Senior IT Architect/Senior SW Engineer
IBM BlueMix
lhcash(a)us.ibm.com
(919) 543-0209

"I skate to where the puck is going to be, not to where it has been.” -
Wayne Gretzky

Inactive hide details for Dieu Cao ---11/12/2015 02:19:53 PM---Hi
William, Thanks for the links.Dieu Cao ---11/12/2015 02:19:53 PM---Hi
William, Thanks for the links.

From: Dieu Cao <dcao(a)pivotal.io>
To: "Discussions about Cloud Foundry projects and the system overall." <
cf-dev(a)lists.cloudfoundry.org>
Date: 11/12/2015 02:19 PM
Subject: [cf-dev] Re: Re: Re: Cloud Controller - s3 encryption for
droplets



Hi William,

Thanks for the links.
We don't have support for client side encryption currently.
Cloud Controller and Diego's blobstore clients would need to be modified
to encrypt and decrypt for client side encryption and I'm not clear what
strategies exist for rotation of keys in these scenarios.

If you're very interested in this feature and are open to working through
requirements with me and submitting a PR, please open up an issue on
github and we can discuss this further.

-Dieu

On Tue, Nov 10, 2015 at 4:16 PM, William C Penrod <wcpenrod(a)gmail.com>
wrote:
I first ran across it here:
http://cloudfoundryjp.github.io/docs/running/bosh/components/blobstore.html


and checked here for additional info:
https://github.com/cloudfoundry/bosh/blob/master/blobstore_client/lib/blobstore_client/s3_blobstore_client.rb


Re: Cloud Foundry Asia Summit Unconference: Call for Participation

Layne Peng
 

Cool, will be there~ :)


Re: Questions about purge app usage event API

Hristo Iliev
 

Hi Minoru,

AFAIK the API does not handle the race condition and this is documented in
the link you provided: "There is the potential race condition if apps are
currently being started, stopped, or scaled"

The purging has to be called only once, before you start/connect your
billing infrastructure. Have a look at this blog for more detailed
explanation: https://www.cloudfoundry.org/how-to-bill-on-cloud-foundry/

Regards,
Hristo Iliev

2015-11-30 3:56 GMT+02:00 Nitta, Minoru <minoru.nitta(a)jp.fujitsu.com>:

Hi,

I have some questions about 'Purge and reseed App Usage Events' API.

https://apidocs.cloudfoundry.org/212/app_usage_events/purge_and_reseed_app_usage_events.html

I am wondering about app started events. The API populates new events for
started app.
This may cause the problems if the API and stopping app occur at the same
time (race condition).
(e.g. app stopped after the API execution, which populates new app start
event but stop app event
never occur).

How can I workaround this problem? Or CloudFoundry handles such race
condition internally and
I do not have to consider the workaround for it?

Regards,
Minoru


Questions about purge app usage event API

Nitta, Minoru <minoru.nitta@...>
 

Hi,

I have some questions about 'Purge and reseed App Usage Events' API.
https://apidocs.cloudfoundry.org/212/app_usage_events/purge_and_reseed_app_usage_events.html

I am wondering about app started events. The API populates new events for started app.
This may cause the problems if the API and stopping app occur at the same time (race condition).
(e.g. app stopped after the API execution, which populates new app start event but stop app event
never occur).

How can I workaround this problem? Or CloudFoundry handles such race condition internally and
I do not have to consider the workaround for it?

Regards,
Minoru

6501 - 6520 of 9426