RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1684499 - [kubevirt] virt-who fails with APIException error
Summary: [kubevirt] virt-who fails with APIException error
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: virt-who
Version: 7.6
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Piotr Kliczewski
QA Contact: Eko
URL:
Whiteboard:
Depends On:
Blocks: 1656265
TreeView+ depends on / blocked
 
Reported: 2019-03-01 11:44 UTC by Vatsal Parekh
Modified: 2019-10-28 07:22 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-08-06 12:41:17 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github candlepin virt-who pull 196 0 None closed kubevirt: drop kubernetes and kubevirt dependencies 2020-09-17 08:53:27 UTC
Github candlepin virt-who pull 197 0 None closed kubevirt: provide user authentication 2020-09-17 08:53:27 UTC
Red Hat Product Errata RHBA-2019:2070 0 None None None 2019-08-06 12:41:27 UTC

Description Vatsal Parekh 2019-03-01 11:44:50 UTC 
Description of problem:
Running virt-who against CNV1.4 on OCP3.11 showed below error in the logs
```
2019-03-01 11:48:20,721 [INFO] subscription-manager:26552:MainThread @managercli.py:457 - X-Correlation-ID: ea110eb1635444699fcff1a8ac3614fd
2019-03-01 11:48:20,721 [INFO] subscription-manager:26552:MainThread @managercli.py:346 - Client Versions: {'subscription-manager': '1.21.10-3.el7.centos'}
2019-03-01 11:55:35,915 [virtwho.destination_-7094184665230902061 DEBUG] MainProcess(18989):Thread-3 @virt.py:_send_data:649 - ErrorReport received for source: virt-who-config-4
2019-03-01 11:55:40,021 [virtwho.main ERROR] MainProcess(18989):Thread-2 @virt.py:run:421 - Thread 'virt-who-config-4' fails with exception:
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/virtwho/virt/virt.py", line 412, in run
    self._run()
  File "/usr/lib/python2.7/site-packages/virtwho/virt/virt.py", line 367, in _run
    data_to_send = self._get_data()
  File "/usr/lib/python2.7/site-packages/virtwho/virt/virt.py", line 963, in _get_data
    return self._get_report()
  File "/usr/lib/python2.7/site-packages/virtwho/virt/virt.py", line 951, in _get_report
    return HostGuestAssociationReport(self.config, self.getHostGuestMapping())
  File "/usr/lib/python2.7/site-packages/virtwho/virt/kubevirt/kubevirt.py", line 109, in getHostGuestMapping
    vms = self.get_vms()
  File "/usr/lib/python2.7/site-packages/virtwho/virt/kubevirt/kubevirt.py", line 95, in get_vms
    return self.kubevirt_api.list_virtual_machine_instance_for_all_namespaces()
  File "/usr/lib/python2.7/site-packages/kubevirt/apis/default_api.py", line 2884, in list_virtual_machine_instance_for_all_namespaces
    (data) = self.list_virtual_machine_instance_for_all_namespaces_with_http_info(**kwargs)
  File "/usr/lib/python2.7/site-packages/kubevirt/apis/default_api.py", line 2978, in list_virtual_machine_instance_for_all_namespaces_with_http_info
    collection_formats=collection_formats)
  File "/usr/lib/python2.7/site-packages/kubevirt/api_client.py", line 326, in call_api
    _return_http_data_only, collection_formats, _preload_content, _request_timeout)
  File "/usr/lib/python2.7/site-packages/kubevirt/api_client.py", line 153, in __call_api
    _request_timeout=_request_timeout)
  File "/usr/lib/python2.7/site-packages/kubevirt/api_client.py", line 349, in request
    headers=headers)
  File "/usr/lib/python2.7/site-packages/kubevirt/rest.py", line 228, in GET
    query_params=query_params)
  File "/usr/lib/python2.7/site-packages/kubevirt/rest.py", line 219, in request
    raise ApiException(http_resp=r)
ApiException: (404)
Reason: Not Found
HTTP response headers: HTTPHeaderDict({'date': 'Fri, 01 Mar 2019 10:55:38 GMT', 'content-length': '19', 'content-type': 'text/plain; charset=utf-8', 'x-content-type-options': 'nosniff', 'cache-control': 'no-store'})
HTTP response body: 404 page not found
```

Version-Release number of selected component (if applicable):
virt-who-0.24.2-1.el7.noarch

How reproducible:


Steps to Reproduce:
1.Add virt-who profile for CNV 
2.check rhsm logs
3.

Actual results:


Expected results:


Additional info:
Comment 2 Piotr Kliczewski 2019-03-01 12:40:49 UTC 
This could be related to api structure after versioning change. This should be fixed by implementing BZ #1656265
Comment 3 Vatsal Parekh 2019-03-07 12:19:20 UTC 
Tested it against the upstream master, seems that we are not passing the auth headers, so hit the 403 error again.

Also, on_qa should be put when we've the new rpm to consume.
Comment 4 Piotr Kliczewski 2019-03-13 09:03:12 UTC 
Actually d/s is not ready for verification so moving to modified.
Comment 9 errata-xmlrpc 2019-08-06 12:41:17 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/RHBA-2019:2070
Note You need to log in before you can comment on or make changes to this bug.