[libvirt] [PATCH] virsh: Remove --flags from nodesuspend
We always expose individual bits from flags as separate options rather than exposing a raw flags options. Since virNodeSuspendForDuration does not currently support any flags, the only way of using this --flags options that would not fail is "--flags 0", which is equivalent to omitting the option. Thus it is highly unlikely anyone would actually be using it and removing it should be safe. --- tools/virsh-host.c | 10 +--------- tools/virsh.pod | 2 +- 2 files changed, 2 insertions(+), 10 deletions(-) diff --git a/tools/virsh-host.c b/tools/virsh-host.c index 0f9b3f3..2ea24ac 100644 --- a/tools/virsh-host.c +++ b/tools/virsh-host.c @@ -506,7 +506,6 @@ static const vshCmdOptDef opts_node_suspend[] = { {"target", VSH_OT_DATA, VSH_OFLAG_REQ, N_("mem(Suspend-to-RAM), " "disk(Suspend-to-Disk), hybrid(Hybrid-Suspend)")}, {"duration", VSH_OT_INT, VSH_OFLAG_REQ, N_("Suspend duration in seconds, at least 60")}, - {"flags", VSH_OT_INT, VSH_OFLAG_NONE, N_("Suspend flags, 0 for default")}, {NULL, 0, 0, NULL} }; @@ -516,7 +515,6 @@ cmdNodeSuspend(vshControl *ctl, const vshCmd *cmd) const char *target = NULL; unsigned int suspendTarget; long long duration; - unsigned int flags = 0; if (vshCommandOptString(cmd, "target", &target) < 0) { vshError(ctl, _("Invalid target argument")); @@ -528,11 +526,6 @@ cmdNodeSuspend(vshControl *ctl, const vshCmd *cmd) return false; } - if (vshCommandOptUInt(cmd, "flags", &flags) < 0) { - vshError(ctl, _("Invalid flags argument")); - return false; - } - if (STREQ(target, "mem")) suspendTarget = VIR_NODE_SUSPEND_TARGET_MEM; else if (STREQ(target, "disk")) @@ -549,8 +542,7 @@ cmdNodeSuspend(vshControl *ctl, const vshCmd *cmd) return false; } - if (virNodeSuspendForDuration(ctl->conn, suspendTarget, duration, - flags) < 0) { + if (virNodeSuspendForDuration(ctl->conn, suspendTarget, duration, 0) < 0) { vshError(ctl, "%s", _("The host was not suspended")); return false; } diff --git a/tools/virsh.pod b/tools/virsh.pod index 76f32c2..321dbe3 100644 --- a/tools/virsh.pod +++ b/tools/virsh.pod @@ -294,7 +294,7 @@ statistics during 1 second. Returns memory stats of the node. If I<cell> is specified, this will prints specified cell statistics only. -=item B<nodesuspend> [I<target>] [I<duration>] [I<flags>] +=item B<nodesuspend> [I<target>] [I<duration>] Puts the node (host machine) into a system-wide sleep state such as Suspend-to-RAM, Suspend-to-Disk or Hybrid-Suspend and sets up a -- 1.7.12.4
On 10/25/2012 04:22 PM, Jiri Denemark wrote:
We always expose individual bits from flags as separate options rather than exposing a raw flags options. Since virNodeSuspendForDuration does not currently support any flags, the only way of using this --flags options that would not fail is "--flags 0", which is equivalent to omitting the option. Thus it is highly unlikely anyone would actually be using it and removing it should be safe. --- tools/virsh-host.c | 10 +--------- tools/virsh.pod | 2 +- 2 files changed, 2 insertions(+), 10 deletions(-)
diff --git a/tools/virsh-host.c b/tools/virsh-host.c index 0f9b3f3..2ea24ac 100644 --- a/tools/virsh-host.c +++ b/tools/virsh-host.c @@ -506,7 +506,6 @@ static const vshCmdOptDef opts_node_suspend[] = { {"target", VSH_OT_DATA, VSH_OFLAG_REQ, N_("mem(Suspend-to-RAM), " "disk(Suspend-to-Disk), hybrid(Hybrid-Suspend)")}, {"duration", VSH_OT_INT, VSH_OFLAG_REQ, N_("Suspend duration in seconds, at least 60")}, - {"flags", VSH_OT_INT, VSH_OFLAG_NONE, N_("Suspend flags, 0 for default")}, {NULL, 0, 0, NULL} };
@@ -516,7 +515,6 @@ cmdNodeSuspend(vshControl *ctl, const vshCmd *cmd) const char *target = NULL; unsigned int suspendTarget; long long duration; - unsigned int flags = 0;
if (vshCommandOptString(cmd, "target", &target) < 0) { vshError(ctl, _("Invalid target argument")); @@ -528,11 +526,6 @@ cmdNodeSuspend(vshControl *ctl, const vshCmd *cmd) return false; }
- if (vshCommandOptUInt(cmd, "flags", &flags) < 0) { - vshError(ctl, _("Invalid flags argument")); - return false; - } - if (STREQ(target, "mem")) suspendTarget = VIR_NODE_SUSPEND_TARGET_MEM; else if (STREQ(target, "disk")) @@ -549,8 +542,7 @@ cmdNodeSuspend(vshControl *ctl, const vshCmd *cmd) return false; }
- if (virNodeSuspendForDuration(ctl->conn, suspendTarget, duration, - flags) < 0) { + if (virNodeSuspendForDuration(ctl->conn, suspendTarget, duration, 0) < 0) { vshError(ctl, "%s", _("The host was not suspended")); return false; } diff --git a/tools/virsh.pod b/tools/virsh.pod index 76f32c2..321dbe3 100644 --- a/tools/virsh.pod +++ b/tools/virsh.pod @@ -294,7 +294,7 @@ statistics during 1 second. Returns memory stats of the node. If I<cell> is specified, this will prints specified cell statistics only.
-=item B<nodesuspend> [I<target>] [I<duration>] [I<flags>] +=item B<nodesuspend> [I<target>] [I<duration>]
Puts the node (host machine) into a system-wide sleep state such as Suspend-to-RAM, Suspend-to-Disk or Hybrid-Suspend and sets up a
ACK. Guannan
On 25.10.2012 10:22, Jiri Denemark wrote:
We always expose individual bits from flags as separate options rather than exposing a raw flags options. Since virNodeSuspendForDuration does not currently support any flags, the only way of using this --flags options that would not fail is "--flags 0", which is equivalent to omitting the option. Thus it is highly unlikely anyone would actually be using it and removing it should be safe. --- tools/virsh-host.c | 10 +--------- tools/virsh.pod | 2 +- 2 files changed, 2 insertions(+), 10 deletions(-)
diff --git a/tools/virsh-host.c b/tools/virsh-host.c index 0f9b3f3..2ea24ac 100644 --- a/tools/virsh-host.c +++ b/tools/virsh-host.c @@ -506,7 +506,6 @@ static const vshCmdOptDef opts_node_suspend[] = { {"target", VSH_OT_DATA, VSH_OFLAG_REQ, N_("mem(Suspend-to-RAM), " "disk(Suspend-to-Disk), hybrid(Hybrid-Suspend)")}, {"duration", VSH_OT_INT, VSH_OFLAG_REQ, N_("Suspend duration in seconds, at least 60")}, - {"flags", VSH_OT_INT, VSH_OFLAG_NONE, N_("Suspend flags, 0 for default")}, {NULL, 0, 0, NULL} };
While I agree that this design is broken I don't think we can do this. Okay, for now we only support 0; but what if in the future we invent a new flag? With current virsh one is able to use it however with your patch he isn't. Therefore I'd rather see slightly different approach. Like we do for other broken options/arguments in virsh - hide it, don't mention it anywhere but keep the code. Michal
On 10/25/12 11:03, Michal Privoznik wrote:
On 25.10.2012 10:22, Jiri Denemark wrote:
We always expose individual bits from flags as separate options rather than exposing a raw flags options. Since virNodeSuspendForDuration does not currently support any flags, the only way of using this --flags options that would not fail is "--flags 0", which is equivalent to omitting the option. Thus it is highly unlikely anyone would actually be using it and removing it should be safe. --- tools/virsh-host.c | 10 +--------- tools/virsh.pod | 2 +- 2 files changed, 2 insertions(+), 10 deletions(-)
diff --git a/tools/virsh-host.c b/tools/virsh-host.c index 0f9b3f3..2ea24ac 100644 --- a/tools/virsh-host.c +++ b/tools/virsh-host.c @@ -506,7 +506,6 @@ static const vshCmdOptDef opts_node_suspend[] = { {"target", VSH_OT_DATA, VSH_OFLAG_REQ, N_("mem(Suspend-to-RAM), " "disk(Suspend-to-Disk), hybrid(Hybrid-Suspend)")}, {"duration", VSH_OT_INT, VSH_OFLAG_REQ, N_("Suspend duration in seconds, at least 60")}, - {"flags", VSH_OT_INT, VSH_OFLAG_NONE, N_("Suspend flags, 0 for default")}, {NULL, 0, 0, NULL} };
While I agree that this design is broken I don't think we can do this. Okay, for now we only support 0; but what if in the future we invent a new flag? With current virsh one is able to use it however with your patch he isn't.
Therefore I'd rather see slightly different approach. Like we do for other broken options/arguments in virsh - hide it, don't mention it anywhere but keep the code.
I agree with this approach. Peter
On 10/25/2012 03:03 AM, Michal Privoznik wrote:
While I agree that this design is broken I don't think we can do this. Okay, for now we only support 0; but what if in the future we invent a new flag? With current virsh one is able to use it however with your patch he isn't.
But you could apply that argument to any number of other interfaces that take a flags argument. virsh simply does not know how to export arbitrary flags that were only added to newer servers - you HAVE to upgrade your virsh to match.
Therefore I'd rather see slightly different approach. Like we do for other broken options/arguments in virsh - hide it, don't mention it anywhere but keep the code.
I disagree - there's no point in keeping a hidden argument. It is a disservice to users to make them have to pass a numeric flags value - if they know they are talking to a new enough server that supports a new flag, then they should be able to upgrade to a new enough virsh that exposes that new flag as a human-readable option name, or directly code their task using C or python bindings instead of bothering with virsh. I think the patch is fine as-is. -- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
On Thu, Oct 25, 2012 at 07:16:35AM -0600, Eric Blake wrote:
On 10/25/2012 03:03 AM, Michal Privoznik wrote:
While I agree that this design is broken I don't think we can do this. Okay, for now we only support 0; but what if in the future we invent a new flag? With current virsh one is able to use it however with your patch he isn't.
But you could apply that argument to any number of other interfaces that take a flags argument. virsh simply does not know how to export arbitrary flags that were only added to newer servers - you HAVE to upgrade your virsh to match.
Therefore I'd rather see slightly different approach. Like we do for other broken options/arguments in virsh - hide it, don't mention it anywhere but keep the code.
I disagree - there's no point in keeping a hidden argument. It is a disservice to users to make them have to pass a numeric flags value - if they know they are talking to a new enough server that supports a new flag, then they should be able to upgrade to a new enough virsh that exposes that new flag as a human-readable option name, or directly code their task using C or python bindings instead of bothering with virsh.
I think the patch is fine as-is.
+1 Dave
-- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On Thu, Oct 25, 2012 at 09:43:28 -0400, Dave Allan wrote:
On Thu, Oct 25, 2012 at 07:16:35AM -0600, Eric Blake wrote:
I disagree - there's no point in keeping a hidden argument. It is a disservice to users to make them have to pass a numeric flags value - if they know they are talking to a new enough server that supports a new flag, then they should be able to upgrade to a new enough virsh that exposes that new flag as a human-readable option name, or directly code their task using C or python bindings instead of bothering with virsh.
I think the patch is fine as-is.
+1
Looks like the consensus is that it is safe to remove --flags. I pushed this patch. Jirka
participants (6)
-
Dave Allan -
Eric Blake -
Guannan Ren -
Jiri Denemark -
Michal Privoznik -
Peter Krempa