Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1353864 - when 429 code received, virt-who can't refresh the json info by trigger event
Summary: when 429 code received, virt-who can't refresh the json info by trigger event
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: virt-who
Version: 7.3
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Radek Novacek
QA Contact: Eko
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-07-08 09:11 UTC by Eko
Modified: 2016-12-01 00:35 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-07-18 01:44:52 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Eko 2016-07-08 09:11:00 UTC
Description of problem:
register virt-who to stage candlepin, if received the 429 code, try to change the guest status such as suspend/poweroff,  and then check rhsm.log, you will find the guest state is still not changed. 

Version-Release number of selected component (if applicable):
virt-who-0.17-5.el7.noarch
subscription-manager-1.17.8-1.el7.x86_64
python-rhsm-1.17.5-1.el7.x86_64

How reproducible:
always

Steps to Reproduce:
1. register host to stage candleping

2. run virt-who until the 429 received
# virt-who --xen --xen-owner=7985933 --xen-env=7985933 --xen-server=10.73.5.232 --xen-username=root --xen-password=Welcome1 -d -i 120
2016-07-08 04:54:10,497 [virtwho.init INFO] MainProcess(14852):MainThread @main.py:main:160 - Using configuration "env/cmdline" ("xen" mode)
2016-07-08 04:54:10,497 [virtwho.init INFO] MainProcess(14852):MainThread @main.py:main:162 - Using reporter_id='hp-z220-10.qe.lab.eng.nay.redhat.com-3a7261821359436c9990b472c83d6be6'
2016-07-08 04:54:10,498 [virtwho.main DEBUG] MainProcess(14852):MainThread @executor.py:run:171 - Starting infinite loop with 120 seconds interval
2016-07-08 04:54:10,538 [virtwho.env_cmdline DEBUG] Xen-1(14859):MainThread @virt.py:run:364 - Virt backend 'env/cmdline' started
2016-07-08 04:54:10,539 [virtwho.env_cmdline DEBUG] Xen-1(14859):MainThread @xen.py:_prepare:42 - Logging into XEN pools https://10.73.5.232
2016-07-08 04:54:10,613 [virtwho.env_cmdline DEBUG] Xen-1(14859):MainThread @xen.py:login:52 - XEN pool login successful with user root
2016-07-08 04:54:11,067 [virtwho.env_cmdline DEBUG] Xen-1(14859):MainThread @xen.py:getHostGuestMapping:80 - Control Domain 4d0c2b83-db73-454b-885f-7acfe4530a3c is ignored
2016-07-08 04:54:11,128 [virtwho.env_cmdline DEBUG] Xen-1(14859):MainThread @xen.py:getHostGuestMapping:80 - Control Domain 08e0ada5-04f6-49ab-b703-0eed24587ba8 is ignored
2016-07-08 04:54:11,129 [virtwho.env_cmdline DEBUG] Xen-1(14859):MainThread @virt.py:enqueue:357 - Report for config "env/cmdline" gathered, putting to queue for sending
2016-07-08 04:54:11,139 [virtwho.main DEBUG] MainProcess(14852):MainThread @subscriptionmanager.py:_connect:123 - Authenticating with certificate: /etc/pki/consumer/cert.pem
2016-07-08 04:54:12,293 [virtwho.main DEBUG] MainProcess(14852):MainThread @subscriptionmanager.py:hypervisorCheckIn:171 - Checking if server has capability 'hypervisor_async'
2016-07-08 04:54:13,444 [virtwho.main DEBUG] MainProcess(14852):MainThread @subscriptionmanager.py:hypervisorCheckIn:183 - Server does not have 'hypervisors_async' capability
2016-07-08 04:54:13,444 [virtwho.main INFO] MainProcess(14852):MainThread @subscriptionmanager.py:hypervisorCheckIn:194 - Sending update in hosts-to-guests mapping for config "env/cmdline": 2 hypervisors and 2 guests found
2016-07-08 04:54:13,444 [virtwho.main DEBUG] MainProcess(14852):MainThread @subscriptionmanager.py:hypervisorCheckIn:195 - Host-to-guest mapping: {
    "82060dac-669f-4ec2-8d01-f1dff5c73d2e": [
        {
            "guestId": "0f2fe6a0-26a8-3957-2b47-fa092205d2b7", 
            "state": 1, 
            "attributes": {
                "active": 1, 
                "virtWhoType": "xen"
            }
        }, 
        {
            "guestId": "03dc7c18-1473-4011-5f85-484702653b89", 
            "state": 1, 
            "attributes": {
                "active": 1, 
                "virtWhoType": "xen"
            }
        }
    ], 
    "3ab09fa8-e3cb-4e1c-874c-97105b556dc8": []
}
2016-07-08 04:54:14,564 [virtwho.main DEBUG] MainProcess(14852):MainThread @executor.py:send_report:115 - 429 received, waiting 60 seconds until sending again
===================== above 429 received, waiting 60 seconds  ===============

3. now change the guest state, such as suspend or poweroff

4. check the log message again, you will find the guest state is not changed:
2016-07-08 04:55:17,465 [virtwho.main INFO] MainProcess(14852):MainThread @subscriptionmanager.py:hypervisorCheckIn:194 - Sending update in hosts-to-guests mapping for config "env/cmdline": 2 hypervisors and 1 guests found
2016-07-08 04:55:17,465 [virtwho.main DEBUG] MainProcess(14852):MainThread @subscriptionmanager.py:hypervisorCheckIn:195 - Host-to-guest mapping: {
    "82060dac-669f-4ec2-8d01-f1dff5c73d2e": [
        {
            "guestId": "0f2fe6a0-26a8-3957-2b47-fa092205d2b7", 
            "state": 1, 
            "attributes": {
                "active": 1, 
                "virtWhoType": "xen"
            }
        }
    ], 
    "3ab09fa8-e3cb-4e1c-874c-97105b556dc8": []
}
2016-07-08 04:55:18,362 [virtwho.main DEBUG] MainProcess(14852):MainThread @executor.py:send_report:115 - 429 received, waiting 120 seconds until sending again

======= 429 received, waiting 120 seconds, state is not changed  =========== 

2016-07-08 04:57:20,679 [virtwho.main INFO] MainProcess(14852):MainThread @subscriptionmanager.py:hypervisorCheckIn:194 - Sending update in hosts-to-guests mapping for config "env/cmdline": 2 hypervisors and 1 guests found
2016-07-08 04:57:20,679 [virtwho.main DEBUG] MainProcess(14852):MainThread @subscriptionmanager.py:hypervisorCheckIn:195 - Host-to-guest mapping: {
    "82060dac-669f-4ec2-8d01-f1dff5c73d2e": [
        {
            "guestId": "0f2fe6a0-26a8-3957-2b47-fa092205d2b7", 
            "state": 1, 
            "attributes": {
                "active": 1, 
                "virtWhoType": "xen"
            }
        }
    ], 
    "3ab09fa8-e3cb-4e1c-874c-97105b556dc8": []
}
2016-07-08 04:57:21,787 [virtwho.main DEBUG] MainProcess(14852):MainThread @executor.py:send_report:115 - 429 received, waiting 180 seconds until sending again

======= 429 received, waiting 180 seconds, state is not changed  =========== 

2016-07-08 05:00:24,387 [virtwho.main DEBUG] MainProcess(14852):MainThread @subscriptionmanager.py:hypervisorCheckIn:195 - Host-to-guest mapping: {
    "82060dac-669f-4ec2-8d01-f1dff5c73d2e": [
        {
            "guestId": "0f2fe6a0-26a8-3957-2b47-fa092205d2b7", 
            "state": 1, 
            "attributes": {
                "active": 1, 
                "virtWhoType": "xen"
            }
        }
    ], 
    "3ab09fa8-e3cb-4e1c-874c-97105b556dc8": []
}
2016-07-08 05:00:25,573 [virtwho.main DEBUG] MainProcess(14852):MainThread @executor.py:send_report:101 - Report for config "env/cmdline" sent



Actual results:
the guest state will never be changed even waiting 180 seconds.

Expected results:
the guest state should be changed if has trigger event.

Additional info:

Comment 2 Radek Novacek 2016-07-12 15:00:51 UTC
The result seems to be fine.

In the step 2, there are two guests reported by virt-who.
You stop one of the guests in the step 3.
virt-who reports only one guest in the step 4.

virt-who doesn't report guests that are powered down, when they're not affiliated to any host (it depends on the data that given hypervisor reports - nothing we can do about it).

What am I missing here?

Comment 3 Eko 2016-07-18 01:44:52 UTC
Hi Radek,
I can't reproduce it any more, so close it as not a bug


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