Description of problem: Notes from BZ where this originated: --synchronize, --wait, and --no-async don't take arguments (alas), they're either specified, or not-specified. You don't, for example, say "--wait=true" or "--wait=false" - you either say "--wait", or nothing. There *are* use-cases where you want to maximize hammer-import's ability to parallelize - but they're only useful if you're an expert who knows exactly what you're doing, and whose Sat6 instance isn't going to fall over when it is asked to do manymany things at once. We should almost certainly say "you should always use this flag". If I could go back and do it over again, I would probably just do the equivalent of --wait --no-async --synchronize, and and not even give the user the option to do otherwise. You could open an RFE and ask for those three options to a) default to true, and b) have a way to turn them *off* for the expert user. Version-Release number of selected component (if applicable): * hammer_cli_foreman (0.5.1) * hammer_cli_foreman_bootdisk (0.1.3) * hammer_cli_foreman_docker (unknown version) * hammer_cli_foreman_tasks (unknown version) * hammer_cli_gutterball (1.0.1) * hammer_cli_import (0.10.22) * hammer_cli_katello (0.0.20) How reproducible: Always Actual results: Default values for various hammer import all arguments are those *not* recommended for non-expert users. Expected results: Default values should be "safe" and not lead to possible issues if you are not very familiar with the command and its processes. Additional info:
Moving 6.2 bugs out to sat-backlog.
I do not believe this will be addressed int he next few releases, so I am closing this out. If you feel this was incorrect, please feel free to re-open with additional information.