Hacker News Reader

I'm not sure about how I feel about this (edit - restart policies). It's cool, but seems to ignore what the OTP part of erlang development learned. They've already gone to "X number of restarts = failure" but with no time involved. There's also no hierarchy, which is where you really start to get the benefits.

While great, I worry that this is a part-solution that will delay the implementation of a proper one.

View on HN

You can happily use containers supervised by systemd in a hierarchy like any other process if you like.

1) We do degrade restarts over time. 2) There is hierarchy (so it will start linked containers).

Perhaps I'm being a bit harsh.

> 1) We do degrade restarts over time.

Is this adjustable? X restarts in Y seconds? I feel this is something that could be quite application specific.

> 2) There is hierarchy (so it will start linked containers).

So if A has a link to B, will A be restarted if B is restarted?

I'd be aiming to build hierarchies with restart strategies like these:

http://www.erlang.org/doc/design_principles/sup_princ.html

1) I know you can specify the number of restarts, not sure yo can specify the gradual decay of the restarts

2) No, this is not the goal of the restart policies. I think this would be best implemented by something watching the docker event stream.

Reply on news.ycombinator.com