1) For now shell permits to work in several ways. For example: [RHEVM shell (connected)]# list clusters --max=-1 id : 99408929-82cf-4dc7-a532-9d998063fa95 name : Default description: The default server cluster id : ede9d0a4-41e2-11e2-ac7c-001a4a169715 name : RestCluster1 id : 04d8a894-41e3-11e2-9924-001a4a169715 name : RestCluster4 id : 11480660-41e3-11e2-b574-001a4a169715 name : RestCluster5 id : 13cefa24-41e3-11e2-b864-001a4a169715 name : RestCluster6 id : 158d3a6a-41e3-11e2-a754-001a4a169715 name : RestCluster7 [RHEVM shell (connected)]# list clusters --max -1 id : 99408929-82cf-4dc7-a532-9d998063fa95 name : Default description: The default server cluster id : ede9d0a4-41e2-11e2-ac7c-001a4a169715 name : RestCluster1 id : 04d8a894-41e3-11e2-9924-001a4a169715 name : RestCluster4 id : 11480660-41e3-11e2-b574-001a4a169715 name : RestCluster5 id : 13cefa24-41e3-11e2-b864-001a4a169715 name : RestCluster6 id : 158d3a6a-41e3-11e2-a754-001a4a169715 name : RestCluster7 [RHEVM shell (connected)]# list clusters --max id : 99408929-82cf-4dc7-a532-9d998063fa95 name : Default description: The default server cluster id : ede9d0a4-41e2-11e2-ac7c-001a4a169715 name : RestCluster1 id : 04d8a894-41e3-11e2-9924-001a4a169715 name : RestCluster4 id : 11480660-41e3-11e2-b574-001a4a169715 name : RestCluster5 id : 13cefa24-41e3-11e2-b864-001a4a169715 name : RestCluster6 id : 158d3a6a-41e3-11e2-a754-001a4a169715 name : RestCluster7 [RHEVM shell (connected)]# 2) Parameters validation issues: [RHEVM shell (connected)]# list clusters --max000 id : 99408929-82cf-4dc7-a532-9d998063fa95 name : Default description: The default server cluster id : ede9d0a4-41e2-11e2-ac7c-001a4a169715 name : RestCluster1 id : 04d8a894-41e3-11e2-9924-001a4a169715 name : RestCluster4 id : 11480660-41e3-11e2-b574-001a4a169715 name : RestCluster5 id : 13cefa24-41e3-11e2-b864-001a4a169715 name : RestCluster6 id : 158d3a6a-41e3-11e2-a754-001a4a169715 name : RestCluster7 [RHEVM shell (connected)]# list clusters --max000 --this_is_bug_or_feature id : 99408929-82cf-4dc7-a532-9d998063fa95 name : Default description: The default server cluster id : ede9d0a4-41e2-11e2-ac7c-001a4a169715 name : RestCluster1 id : 04d8a894-41e3-11e2-9924-001a4a169715 name : RestCluster4 id : 11480660-41e3-11e2-b574-001a4a169715 name : RestCluster5 id : 13cefa24-41e3-11e2-b864-001a4a169715 name : RestCluster6 id : 158d3a6a-41e3-11e2-a754-001a4a169715 name : RestCluster7 it will confuse end user
as all options in cli available via auto-completion, i'd say this is minor issue, but indeed has to be addressed at some point.
Michael please take a look at this issue and see that auto completion is bogus too: https://bugzilla.redhat.com/show_bug.cgi?id=885635
(In reply to comment #2) > Michael please take a look at this issue and see that auto completion is > bogus too: > https://bugzilla.redhat.com/show_bug.cgi?id=885635 ilia, 1. mentioned BZ is NOT-A-BUG 2. even if it was, private issue on a single use-case doesn't make Comment 1 irrelevant.
what is worse, since multiple ways are available, we will have to support all of them, if we don't want to break users' scripts. Better to cut down on the options and maintain a small set IMO
(In reply to comment #4) > what is worse, since multiple ways are available, we will have to support > all of them, if we don't want to break users' scripts. Better to cut down on > the options and maintain a small set IMO Dan, no multiple ways are available, only non-existent options get ignored silently and this is an issue reported in this BZ, e.g: [RHEVM shell (connected)]# list clusters --max=-1 --max=-1 ignored as no such parameter 'max=-1' in sdk [RHEVM shell (connected)]# list clusters --max -1 valid '--max -1' option only ignored by the engine as -1 is a default there [RHEVM shell (connected)]# list clusters --max ignored by the api as value for 'max' wasn't specified [RHEVM shell (connected)]# list clusters --max000 --max000 ignored as no such parameter 'max000' in sdk [RHEVM shell (connected)]# list clusters --max000 --this_is_bug_or_feature --max000 ignored as no such parameter 'max000' in sdk --this_is_bug_or_feature ignored as no such parameter 'this_is_bug_or_feature' in sdk
currently SHELL runtime is agnostic to option types,
currently SHELL runtime is agnostic to option types, basically the reason for that is not strongly typed nature of python it is written on, however there is a way to overcome this limitation by documenting arguments types in the sdk
*** Bug 959740 has been marked as a duplicate of this bug. ***