Backlog #1143
Improved ONE CLI Range Commands
Status: | Closed | Start date: | 02/26/2012 | |
---|---|---|---|---|
Priority: | High | Due date: | ||
Assignee: | - | % Done: | 0% | |
Category: | CLI | Estimated time: | 1.00 hour | |
Target version: | - |
Description
Currently, the "onevm" CLI tool's range behavior is less than idea for handling spare ID numbers.
ISSUE:
When executing a range command, say the following command:
oneadmin@opennebula-server:/home/hbetts$ onevm stop 73..137
It attempts to execute "stop" on each VM starting with VMID 73 and progressing to VMID 137.
However, if there are any VMIDs not used within that range, or are in the wrong state, the following error is shown:
[VirtualMachineAction] Wrong state to perform action
EXAMPLE:
oneadmin@opennebula-server:/home/hbetts$ onevm stop 73..137
[VirtualMachineAction] Wrong state to perform action
[VirtualMachineAction] Wrong state to perform action
[VirtualMachineAction] Wrong state to perform action
[VirtualMachineAction] Wrong state to perform action
[VirtualMachineAction] Wrong state to perform action
IDs that were skipped:
ID STATE
73 stop
76 stop
79 stop
135 stop
137 stop
IMPROVEMENT
Either of the two options would be nice:
(1) There should be a flag that is set for range commands such that VMs that are not in the proper state are skipped over, with no error messages printed.
(2) A command line flag should be available, instructing the tool to not print warnings for VMs which are within the range but are already in the proper state.
For large ID ranges, those warnings could be extensive. Also, I don't know how ranges react to VMIDs which are not under the control of the user executing the range command. All my tests were conducted with the "oneadmin" user.
Related issues
History
#1 Updated by Ruben S. Montero over 7 years ago
- Tracker changed from Feature to Backlog
- Status changed from New to Pending
- Priority changed from Low to High
#2 Updated by Ruben S. Montero over 6 years ago
- Status changed from Pending to Closed
The ID is now printed in the message, and stderr would be redirected. We believe the current, is the standard error behavior...