Tero Marttila

> kontena agent logs shows that the newly created stack will keep pulling kontena/registry:latest Is this temporary? Does it actually deploy the replacement service instance with the correct image? First...

Probably related to #2625 and #2415

This may be a similar kind of case as in https://github.com/kontena/kontena/issues/2415#issuecomment-327501539, with `ServicePodWorker#update` calls that queue up during the long image pull retry loop (#2516). The `ServicePodWorker` would keep trying...

Confirm that the agent `ServicePodManager` will queue up multiple attempts to deploy the service pod using the wrong image. If you install a stack with the wrong image, and wait...

Fundamentally, the problem is that the the `ServicePodManager` calls `update` at a fixed 30s interval, but each such `ServicePodWorker#update` call can take longer than 30s. That means that the calls...

First thought for implementing this would be in the form of a stack file opto variables resolver that handles the `kontena certificate authorize` and `kontena certificate request`.

Because this PR introduces the `Kontena::WebsocketClient#closed?` state, I'm considering also fixing the reconnect-after-server-close bug in https://github.com/kontena/kontena/issues/3067#issuecomment-346029191... the `on_close` => `Kontena::Agent.shutdown` handlers just need to also set `@closed = true`?

> Should we move this to 1.5.0? I'm not aware of any specific 1.4 issues fixed by this PR, so doing it as a general cleanup in 1.5 sounds good.

@jakolehm still planning on taking a look at this for 1.5?

Ping @jnummelin not strictly required for 1.5, but it would be nice.