running kubefwd multiple times in parallel

[kroonprins]

hi,

I was trying to run kubefwd multiple times in parallel because I am often switching between different developments that test against different clusters and it would be handy not to have to stop a running kubefwd to be able to start a second independent one. Currently that does not seem possible because it re-uses the default base ip 127.1.27.1 for each run, resulting in the second run trying to use an ip+port already in use by the first run. As a workaround I am using the cli option "--fwd-conf" to set a different "baseUnreservedIP" for each so that they don't overlap, but that it is a bit clunky because this "baseUnreservedIP" can only be given via a file. So I was wondering if you would consider adding "baseUnreservedIP" as a cli option to avoid having to go via a file? If interested, I could make a PR with this commit https://github.com/kroonprins/kubefwd/commit/88ae69bd512d92ab075ec8eb2c50ee586c45331f.

While looking a bit further in the code to see what is happening when running kubefwd 2 times in parallel, I noticed that currently in fwdnet.go the check if an interface is ready isn't detecting that something is already in use because the opts.Port value is empty, resulting in an error on net.Dial. I tried making a fix for that in this commit https://github.com/kroonprins/kubefwd/commit/f277da3538b61af00396805add74bfc51ec21e0e.

And I was wondering if the "ready interface"-check could perhaps be used to automatically deal with 2 runs in parallel of kubefwd, by moving it inside the process of allocating an IP. I did an attempt for this in this commit https://github.com/kroonprins/kubefwd/commit/ef60ce6238aeb76182f6f4f67103bd6a61dd9da2, which works for my use case, but might have impact on things I am not aware about.

[cjimti]

kubefwd is never intended to be run in parallel; you will also likely run into race conditions and unexpected behavior with reading and writing to /etc/hosts. There are a lot of issues that would have to be overcome, and they fall outside scope of this simple development utility.

[kroonprins]

Fair enough, @cjimti .

But do consider that the 3 commits also seem to be relevant in case of intended (non-parallel) usage:

• https://github.com/kroonprins/kubefwd/commit/88ae69bd512d92ab075ec8eb2c50ee586c45331f: considering we do have a cli opt for overriding reservations from a foward configuration file, it seems only consistent to also provide a cli opt to set the base unreserved ip from the same file?
• https://github.com/kroonprins/kubefwd/commit/f277da3538b61af00396805add74bfc51ec21e0e: this is an existing bug, no? The current code in the ReadyInterface function doesn't work, so if you won't consider fixing it, perhaps better to remove it then?
• https://github.com/kroonprins/kubefwd/commit/ef60ce6238aeb76182f6f4f67103bd6a61dd9da2: I am not fully understanding the purpose of the check on the ready interface if all it is doing is print a warning to then fail further on in the process because it can't re-use something that is already in use. If a local address is already in use, for whatever reason, on the machine, there is a reason for not just trying a next ip?