Bug 2167464

Summary: node-labeller init container in virt-handler pod is named virt-launcher
Product: Container Native Virtualization (CNV) Reporter: Ahmad <ahafe>
Component: VirtualizationAssignee: sgott
Status: CLOSED MIGRATED QA Contact: Kedar Bidarkar <kbidarka>
Severity: low Docs Contact:
Priority: low    
Version: 4.12.1CC: acardace, ahafe, stirabos
Target Milestone: ---   
Target Release: 4.15.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2023-12-14 16:09:46 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:
Attachments:
Description Flags
must gather report none

Description Ahmad 2023-02-06 17:15:51 UTC 
Description of problem:

following verifying bug https://bugzilla.redhat.com/show_bug.cgi?id=2152627 
virt-launcher logs are being collected under virt-handler dir


Version-Release number of selected component (4.12.1-3):


How reproducible:

1. rum must_gather under default namespace
oc adm must-gather --image=[must gather image from your clister] -- gather_vms_details

2.check:
must-gather.local.[generic number]/registry-redhat-io-container-native-virtualization-cnv-must-gather-[image sah1]/namespaces/openshift-cnv/pods/virt-handler-b6bmg/virt-launcher/




Actual results:
virt-launcher logs are being collected under virt-handler dir:

ls -ltR must-gather.local.3705485383590099656/registry-redhat-io-container-native-virtualization-cnv-must-gather-rhel8-sha256-8b470d844b63cb367b463d4574815f1593a65827b3f8c1f61479bd7929c01a33/namespaces/openshift-cnv/pods/virt-handler-b6bmg/virt-launcher/virt-launcher/logs/
must-gather.local.3705485383590099656/registry-redhat-io-container-native-virtualization-cnv-must-gather-rhel8-sha256-8b470d844b63cb367b463d4574815f1593a65827b3f8c1f61479bd7929c01a33/namespaces/openshift-cnv/pods/virt-handler-b6bmg/virt-launcher/virt-launcher/logs/:
total 0
-rwxr-xr-x. 1 centos centos 0 Feb  5 14:34 previous.insecure.log
-rwxr-xr-x. 1 centos centos 0 Feb  5 14:34 current.log
-rwxr-xr-x. 1 centos centos 0 Feb  5 14:34 previous.log
[centos@ci-vm-10-0-96-58 ahmad]$ 





virt-handler  should not be collected under virt-handler dir in must_gather report


see attached must-gather output
Comment 1 Ahmad 2023-02-06 17:23:28 UTC 
Created attachment 1942560 [details]
must gather report
Comment 2 Simone Tiraboschi 2023-02-07 11:22:05 UTC 
This is actually consistent (although maybe confusing):

as for:
https://github.com/openshift/enhancements/blob/master/enhancements/oc/inspect.md#output-format

the expected struct is:
└── namespaces
    ├── <NAMESPACE>
...
    │   └── pods
    │       └── <POD_NAME>
...
    │           └── <CONTAINER_NAME>
    │               └── <CONTAINER_NAME>
...
    │                   ├── logs


so for this folder we should expect:
namespaces/<NAMESPACE>/pods/<POD_NAME>/<CONTAINER_NAME>/<CONTAINER_NAME>/logs/
and indeed here we have:
namespaces/openshift-cnv/pods/virt-handler-b6bmg/virt-launcher/virt-launcher/logs/

having:
NAMESPACE=openshift-cnv
POD_NAME=virt-handler-b6bmg
CONTAINER_NAME=virt-launcher

Now the whole point is that when node-labeller got moved from SSP to virt, it got moved to virt-launcher image and not to the virt-handler one.
Although it's executed on an initContainer on the pods created by virt-handler deamonset.
And this is init container is named virt-launcher although is node-labeller, running from virt-launcher image as an initContainer in virt-handler pods.
See:
https://github.com/kubevirt/kubevirt/blob/02da9762963d93673d5a6d1dbc792947a51f8d65/pkg/virt-operator/resource/generate/components/daemonsets.go#L96

So on must-gather side everything is behaving as expected.

Moving to virt team to eventually consider about renaming that init container to make it less confusing.
Comment 3 Kedar Bidarkar 2023-02-08 13:27:28 UTC 
Targeting this bug tp 4.14 depending upon capacity and severity.
Comment 4 Antonio Cardace 2023-09-22 09:36:35 UTC 
Deferring to 4.15 due to capacity and severity.