Joshua Carp

We've seen workers stuck in a `stalled` state both after upgrading the concourse version (from 3.3.4 to 3.4) and after upgrading the bosh stemcell. I just ran a `bosh restart`...

@topherbullock: we just got another batch of stalled workers on updating stemcells: ``` ± fly -t fr workers name containers platform tags team state version 0eecd635-20b7-4fa0-8b48-6d3ac98c389d 250 linux none none...

This also seems to happen with >1 TSA. We have two "web" instances (running ATC and TSA, like in concourse-deployment) and see this happening regularly.

We just merged a patch that allow serialization and deserialization using compound primary keys at #32. Would you mind reinstalling from the `dev` branch and giving your example another try?...

I don't think I care how old a stemcell is in time--I only care whether it's the latest version. If no CVEs get patched over a few weeks it's fine...

A few things: * It doesn't look like the bosh-hub api currently includes release timestamps, although that would be a quick patch to https://github.com/cppforlife/bosh-hub/blob/a745e1693e553b5a5a2b07cf76dfb82be8344a93/ui/stemcell/stemcell.go#L224-L234 * I think I'm still misunderstanding...

When you say... > "Alert only if a deployment is not using the latest stemcell in the series and it has been more than x time since it was released"...

Derequire parses the JS and maps all instances of `require` to some other token, defaulting to `_dereq_`. This is necessary when you want to browserify a dependency that has already...

Ping @jehiah. This is a simple fix that should make the package `go get`-table again.

> What did you have in mind when you said "increase the default timeout in line with the GKE docs"? Hm, I took a closer look at the docs and...