The eirini repository's current README (https://github.com/cloudfoundry-incubator/eirini#y-tho-y) states: "Partly a fun experiment, partly a proof of concept" That phrasing doesn't read as a component

We originally wrote this to support ISV integrations, but from some discussions at summit last week, it seems like there was broader interest among platform operators as well for something like this.

That's great Guillaume, thanks! That's exactly what I was after Sabha, thanks for sharing. Looping in Matt McNeeney for the OSBPAI perspective: is this concept generic enough to fit into OSBAPI spec?

In a default deny situation, where the operator doesn't want to open up a foundation-wide security group at service installation time, it would be useful to create and bind a security group on the fly

Dr Nic, For me, it was gcp sdk's auto completion that breaks the above stack overflow post instructions. I added the following to my .zshrc *before* gcp's auto completion loads: _cf-cli() { # All argu

I'd guess WildFly is setting JSESSIONID when first visiting the app, which would stick your browser session to the same app instance. thomas.darimont+github(a)gmail.com> wrote:

Nice! Thanks for adding this support. -Matt

Got it. Thanks for the links to the commits, appreciate it. wrote:

We recently upgrade from 228 to 233. Since then, one thing I'm seeing is that neither DEA nor HM9000 is responding to a vcap.component.discover on nats. Is this expected? I've dug a bit and haven't fo

This is a source of confusion for our end users as well. Users will have the space manager role, but not the space developer role, and fail when they first try to push an application.

Your mileage may vary, but if you look at the full processes's environment there are differences. In our case, we'll see things like the ssh port in the diego environment but not the DEA, as well as I

We recently upgrades from 222 to 228 and saw a change we'd like to know the reason for. Looking at the generated uaa.yml for the job's config, in the newest version, oauth.client.autoapprove only cont

We use them for registering a route in nats. We could move to route-registrar at some point, but our code predates route-registrar and we haven't migrated.

If you're also interested in the community using these projects, we're using both yagnats and gibson in our Cloud Foundry install's custom login server. -Matt Cholick

Sorry to resurrect an older thread, but I wanted to chime in that this is a frustration I have too. There are several stories in the various CF teams public backlogs that I'd like to keep track of. Is

Configuring the consul agent to recurse does solve the issue. The consul agent's configuration is directory based: it loads every json file in its config directory. Since our deployment already consum

Sure. Here's the Ruby: dns_open: 8 ms | dns_close: 0 ms dns_open: 9 ms | dns_close: 0 ms dns_open: 10 ms | dns_close: 0 ms dns_open: 3013 ms | dns_close: 0 ms dns_open: 5015 ms | dns_close: 0 ms dns_o

So things got a little more interesting yesterday. We have some custom Golang jobs for auditing and some other purposes. A recent change added the consult_agent template to the box with these jobs and

Gotcha. Yeah, the rescue lets that test run; after 425k lookups, it never got slow. Here's a bit of the strace: https://gist.github.com/cholick/88c756760faca77208f8

Ah, I misunderstood. Consul isn't configured as a recursive resolver, so for a test with only the 127.0.0.1 in resolve.conf I changed the url in the ruby loop to "uaa.service.cf.internal", which is wh