Description of problem: common argument used in hammer commands --unlimited-hosts in some cases requires a value in other cases it is passed without a value. We should be consistent across the CLI. Allow the user to pass 1|0 true|false yes|no AND insist on a value OR Allow the user to pass without a value OR Allow the user to do either NOT have a mix of requirements Version-Release number of selected component (if applicable): [root@sat6 ~]# hammer --version hammer (0.17.1) * hammer_cli_foreman (0.17.0.8) * hammer_cli_foreman_admin (0.0.8) * hammer_cli_foreman_ansible (0.3.2) * hammer_cli_foreman_bootdisk (0.1.3.3) * hammer_cli_foreman_discovery (1.0.1) * hammer_cli_foreman_docker (unknown version) * hammer_cli_foreman_openscap (0.1.7) * hammer_cli_foreman_remote_execution (unknown version) * hammer_cli_foreman_tasks (unknown version) * hammer_cli_foreman_templates (0.1.2) * hammer_cli_foreman_virt_who_configure (unknown version) * hammer_cli_katello (0.18.0.6) How reproducible: always Steps to Reproduce: 1. run two commands 2. hammer host-collection create <args> --unlimited-hosts 3. hammer activation-key create <args> --unlimited-hosts Actual results: hammer host-collection create generates an error **unless** you pass true|false 1|0 yes|no hammer activation-key create generates an error ** if ** you pass true|false 1|0 yes|no Expected results: both commands should have the same behaviour for a similar argument and meaning. Additional info: my vote is to be ansible-ish and allow the user either pass a value or not and default true yes 1 if a value is not provided. My $0.02CAD
Created redmine issue https://projects.theforeman.org/issues/32868 from this bug
Upstream bug assigned to jlenz
Moving this bug to POST for triage into Satellite since the upstream issue https://projects.theforeman.org/issues/32868 has been resolved.
Thank you for your interest in Satellite 6. We have evaluated this request, and while we recognize that it is a valid request, we do not expect this to be implemented in the product in the foreseeable future. This is due to other priorities for the product, and not a reflection on the request itself. We are therefore closing this out as WONTFIX. If you have any concerns about this feel free to contact your Red Hat Account Team. Thank you.
we actually did decide to fix this, moving back to POST
Hi Jeremy Re this suggestion: > > Additional info: > my vote is to be ansible-ish and allow the user either pass a value or not > and default true yes 1 if a value is not provided. My $0.02CAD that sounds good to me, but what is the default behaviour for most flags at the moment? see also: Bug 2082241 - hammer host-collection create fails with "Too many arguments" when setting unlimited-hosts
I think @paji will be more qualified to answer this.. Partha, recall the discussion at https://github.com/Katello/hammer-cli-katello/pull/809 It seemed like a good solution to me. But you're more familiar with hammer and consistency of different commands..
Stephen, Ideally all the boolean values in the API Doc translate to flags. For example `--composite` or `--import-only` in content views. Unfortunately its not consistent across the board. But as Jeremy mentioned I 'd argue `--unlimited-hosts` as a flag is consistent with what `hammer activation-key create --unlimited-hosts`.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Moderate: Satellite 6.11 Release), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2022:5498