Created attachment 166162 [details] Enhancements for qjail I've been using qjail to create many jails (2k per machine) on some load test hosts, during this we hit a few issues which we've fixed so wanted to pass on the fixes. The fixes where: * Significantly improve performance of IP verification. This check gets exponentially slower the more jails are added due to the load of every previous jail config to validate it. We've changed this to a simple grep which achieves the same thing in a fraction of the time. * Refactor IP check to a single method. With the above changes it was trivial to make a single method replace the existing two. * Increase the jail limit from 100 => 254 (max per subnet). There didn't seem to be any reason for this limit so increased it such that an entire subject of jails can be created. * Fix output message typo. * Ignore missing definitions in some situations. When running parallel qjail creates we we're seeing random failures due to temporary definition files, which then disappeared. Deal with this by allowing read-definition to fail. The patch is attached, hope its helpful.
Thank you Steven Hartland for taking the time and effort to submit your patch. I am currently out of the country on a government contract which ends March 30 2016. I will not be able to address this until after then. My original plans are to wait until Release 11.0 is published because it's suppose to included an updated VIMAGE that is included as part of the base system. This will require testing of the qjail VIMAGE function that may result in some changes. Change # 1. Previously assigned IP verification routine for ipv4 & ipv6. In general I approval of what your trying to do. Change # 2. Increase the max duplication limit from 100 to 254. This value has nothing to do with the max value in the last octal in ipv4 ip addresses. It just controls the loop for automatically creating jails with the same jail name prefix. The user must be aware of the starting ipv4 address stays valid when bumped by 1 for each iteration of the duplication loop. The logic behind the 100 max value is to prevent the user from entering an erroneous value. In your case of creating thousands of jails is unique. In general I see no problem of increasing the max limit to 254. Change # 3. "Ignore missing definitions in some situations. When running parallel qjail creates we we're seeing random failures due to temporary definition files, which then disappeared. We deal with this by allowing read-definition to fail." With out further testing research I can not accept your solution. To me, The symptoms you are experiencing indicates that the same jail name is being created by error during parallel creates. A review of the qjail create commands being run through different terminal sessions need further inspection. Please describe in greater detail just what your doing giving the qjail commands issued that recreate the problem.
(In reply to Joe Barbish from comment #1) The temporary definition files where actually related to the IP check. Previously it wrote the current state of the creating jail to disk while it read in the jail being checked, once it completed the check the state of the creating jail was read back in and the definition file deleted. If a second create found the temporary definition file in its ls but it was deleted by the time it was read for check, the second process would error out without the ignore_missing option. Now the IP verify doesn't do this, that change isn't needed, so can safely be removed; sorry forgot about that. No worries about the time, there's no rush, I just always like to capture things once they're done and in production here ;-)
PR 206935 applies the patch provided by this PR. When pr 206935 gets committed this pr 206654 can be closed.
Correctly annotate/classify/assign issue post-resolution