Bug 1656258

Summary: virtctl start/stop vm prints successful message to stderr
Product: Container Native Virtualization (CNV) Reporter: Guohua Ouyang <gouyang>
Component: VirtualizationAssignee: Petr Kotas <pkotas>
Status: CLOSED ERRATA QA Contact: zhe peng <zpeng>
Severity: medium Docs Contact:
Priority: medium    
Version: 1.4CC: cnv-qe-bugs, ipinto, pkotas, sgordon, sgott
Target Milestone: ---   
Target Release: 1.4   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
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:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-02-26 10:28:24 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

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