Bug 1656258 - virtctl start/stop vm prints successful message to stderr
Summary: virtctl start/stop vm prints successful message to stderr
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Container Native Virtualization (CNV)
Classification: Red Hat
Component: Virtualization
Version: 1.4
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
: 1.4
Assignee: Petr Kotas
QA Contact: zhe peng
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-12-05 04:26 UTC by Guohua Ouyang
Modified: 2019-02-26 10:28 UTC (History)
5 users (show)

Fixed In Version: kubevirt-0.13.2-1.ge1ce9da.6d86849 virt-api-container-v1.4.0-15 virt-controller-container-v1.4.0-15 virt-handler-container-v1.4.0-15 virt-launcher-container-v1.4.0-15 virt-operator-container-v1.4.0-7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-02-26 10:28:24 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2019:0418 0 None None None 2019-02-26 10:28:26 UTC

Description Guohua Ouyang 2018-12-05 04:26:00 UTC
Description of problem:
Start/stop a vm will print "VM vm-cirros was scheduled to start" to stderr.
It's introduced by https://github.com/kubevirt/kubevirt/blob/9aa96a0ae7dabe5c509e85940addf27d82a1962d/pkg/virtctl/vm/vm.go#L152.

I hit this while I write a test to check the status of this command, it returns fail even it's successful.

Version-Release number of selected component (if applicable):


How reproducible:
100%

Steps to Reproduce:
1. virtctl start vm-cirros
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 Petr Kotas 2019-01-16 14:45:38 UTC
I was able to reproduce and fix. The fix is in the PR https://github.com/kubevirt/kubevirt/pull/1944

Comment 2 Petr Kotas 2019-01-22 13:51:56 UTC
The PR has been merged.

Comment 3 sgott 2019-01-22 23:03:42 UTC
Moving this issue to POST until the fix is merged downstream.

Comment 4 sgott 2019-01-24 21:44:32 UTC
To verify this, use vmctl to start/stop a VM, and ensure no output such as "VM vm-cirros was scheduled to start" appears on stderr.

Comment 5 Israel Pinto 2019-01-30 07:20:18 UTC
I check it and i still see the output: 

$ virtctl stop vm-cirros-datavolume
VM vm-cirros-datavolume was scheduled to stop

$ virtctl start vm-cirros-datavolume
VM vm-cirros-datavolume was scheduled to start

$ virtctl version
Client Version: version.Info{GitVersion:"v0.13.2", GitCommit:"6d86849015c1f504268ba6d30a2c95bd5ccda88c", GitTreeState:"clean", BuildDate:"2019-01-24T20:10:27Z", GoVersion:"go1.10.3", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{GitVersion:"v0.13.2", GitCommit:"6d86849015c1f504268ba6d30a2c95bd5ccda88c", GitTreeState:"clean", BuildDate:"2019-01-24T20:53:33Z", GoVersion:"go1.10.3", Compiler:"gc", Platform:"linux/amd64"}

Comment 6 Petr Kotas 2019-01-30 10:41:42 UTC
That is correct. The text has not been removed. The change is in the output channel.
The text is output to Stdout not to Stderr.

Original issue was that the text was output to Stderr. Which was an issue.

Comment 7 sgott 2019-01-30 18:49:49 UTC
To verify this issue, you could pipe the stdout to /dev/null and ensure no output appears, then repeat by piping stderr to /dev/null


No output would be expected from these commands:

$ virtctl stop vm-cirros-datavolume >/dev/null

$ virtctl start vm-cirros-datavolume >/dev/null


But these commands should have output:

$ virtctl stop vm-cirros-datavolume 2>/dev/null
VM vm-cirros-datavolume was scheduled to stop

$ virtctl start vm-cirros-datavolume 2>/dev/null
VM vm-cirros-datavolume was scheduled to start

Comment 8 Israel Pinto 2019-01-30 18:55:23 UTC
According to https://bugzilla.redhat.com/show_bug.cgi?id=1656258#c7 
we can see the output as expected - PASS

Comment 11 errata-xmlrpc 2019-02-26 10:28:24 UTC
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, 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/RHEA-2019:0418


Note You need to log in before you can comment on or make changes to this bug.