Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
The chef-solo binstubs need to use the Chef::Application::Client class #8366
We really need to look at inverting the way that we invoke the Chef::Application::Solo class and then trampoline out of that into Chef::Application::Client when we are in zolo mode and not legacy chef-solo. Instead we should invoke Chef::Application::Client and then only trampoline out when we are in legacy mode, making legacy-mode the special handling case.
This means that command line parsing will have to be made consistent between the classes (and is probably a good thing -- reducing code duplication and interface drift between the two classes). The Chef::Application::Solo class should also likely have its CLI arguments removed, and all the code duplication should really get removed as much as possible.
In the end it would be best to have only Chef::Application::Client exist with special-casing around the legacy mode operation of chef-solo (although its also legacy and at some point we should deprecate that behavior, but that requires fixing the perf issues in ChefFS).