Live data from Hacker News

Docker 1.2.0, with restart policies

blog.docker.com

71–76 of 76 posts

Re: Docker 1.2.0, with restart policies

#71
post #63
post #62

Earlier quoted context omitted.

Why is this not supported during docker build? I'm not very familiar with the --privileged flag - isn't that only related to sharing on the host? Edits to /etc/hosts in a container don't affect the host, so it seems like everything should Just Work.

I think it is supported. The feature we are discussing allows the container to change its own resolv/host files, from the inside. I'm pretty sure that works from build also. But it's possible that I missed one of the patches (a sign of healthy autonomy and trust between maintainers).

No the PR that was chosen ensures that it doesn't commit it - so it can be setup fresh on start. So it is up to each container's startup to set it up as it needs before continuing.

(just tested it out as this was my assumption all along).

Re: Docker 1.2.0, with restart policies

#72
post #60

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.

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

Re: Docker 1.2.0, with restart policies

#73

Earlier quoted context omitted.

Yea, i really thought that this stuff should be out of dockerland. Not that i dislike the feature, just that it seems to overlap with established tools that excel at doing one thing well.

FWIW, now that docker is handling the restart/monitoring it can actually do it better than if systemd is doing it, since docker knows that it doesn't have to tear down and re-create the network namespace, unmount/remount the container's FS, etc. So when a container is restarted via the restart policy, it not only happens faster, it will get the same IP as well.

> it will get the same IP as well.

Not for me. Just tested it.

Re: Docker 1.2.0, with restart policies

#74
post #60

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.

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

Re: Docker 1.2.0, with restart policies

#75
post #73

Earlier quoted context omitted.

FWIW, now that docker is handling the restart/monitoring it can actually do it better than if systemd is doing it, since docker knows that it doesn't have to tear down and re-create the network namespace, unmount/remount the container's FS, etc. So when a container is restarted via the restart policy, it not only happens faster, it will get the same IP as well.

> it will get the same IP as well. Not for me. Just tested it.

How did you test it?

Re: Docker 1.2.0, with restart policies

#76
post #74

Earlier quoted context omitted.

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_principl…

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.

Post reply on HN