Skip to content
This repository was archived by the owner on Jan 5, 2025. It is now read-only.

Conversation

@flavio-fernandes
Copy link
Contributor

I'm using this with pipework, so
at launch time the interface in dhcpd container is not yet created.

docker run -itd --net=none --name dhcpd -v "$(pwd)/data":/data networkboot/dhcpd eth1 pipework ${PARENT_IF} -i eth1 dhcpd 10.2.0.254/24@10.2.0.1 @1000

@robinsmidsrod
Copy link
Contributor

@flavio-fernandes Looks good as far as I can tell.

Two things:

  1. Can you make the additional tools (iproute and net-tools) be installed on the same line as all the others dependencies? I don't see why they should need a separate line (except for avoiding long lines, but I don't really care that much about that). Also, why do you need iproute and net-tools? Nothing in your commit seems to need it...

  2. In your example command you have more than one argument to the docker run command, and the behavior you want is only supposed to trigger with ONE argument. It seems to me that your misusing the fact that the entrypoint script is only testing if the first argument as an interface name. Or maybe your example was supposed to be two lines and not one? That would make more sense...

@flavio-fernandes
Copy link
Contributor Author

flavio-fernandes commented Dec 20, 2016

Can you make the additional tools (iproute and net-tools) be installed on the same line as all the
others dependencies? I don't see why they should need a separate line (except for avoiding long
lines, but I don't really care that much about that). Also, why do you need iproute and net-tools?
Nothing in your commit seems to need it...

oops... right, these should not be there at all. Let me push a revised PR w/out that. Sorry for that.

In your example command you have more than one argument to the docker run command, and
the behavior you want is only supposed to trigger with ONE argument. It seems to me that your
misusing the fact that the entrypoint script is only testing if the first argument as an interface
name. Or maybe your example was supposed to be two lines and not one? That would make more
sense...

Right, sorry for the confusion. In the example, these were 2 separate commands, having the pipework done a little while after the docker container is started:

$ docker run -itd --net=none --name dhcpd -v "$(pwd)/data":/data networkboot/dhcpd eth1
$ PARENT_IF=ens04 ; # an interface in the host running docker container
$ pipework  ${PARENT_IF} -i eth1 dhcpd 10.2.0.254/24@10.2.0.1 @1000

@flavio-fernandes
Copy link
Contributor Author

Please review revised change. Thanks.

@robinsmidsrod
Copy link
Contributor

Thank you! That looks much better!

Just one thing. If I understood your code correctly, won't this code sleep for a total of 36 seconds before giving up? That's quite a long time to wait for someone that just accidentally specified the wrong interface. I would rather prefer some form of exponential back-off (1,2,4,8s).

How much time does it generally take for a network bridge to be operational and the interface to be visible?

I think 10-15 seconds (in total) is a reasonable time to wait for something to come online without giving people that don't use this feature too much of an annoyance.

Can you try to alter your PR to take these wishes into account?

@flavio-fernandes
Copy link
Contributor Author

flavio-fernandes commented Dec 21, 2016

Yes, 8 is a bit high. In my usage, a few seconds is enough to get pipework to
add the interface into the container.

Let me make it 3 retries:
1 sleep(2)
2 sleep(3)
3 sleep(4)
Total: up to 9 seconds

@robinsmidsrod robinsmidsrod merged commit 8af1870 into networkboot:master Dec 21, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants