This is server-side issue which I believe is fixed in newer versions of candlepin. With (a bit older) candlepin master, I get:

[virtwho.main ERROR] MainProcess(16323):MainThread @virtwho.py:send:202 - Unable to send data: Communication with subscription manager failed with code 404: Organization with id xxxxxxxx could not be found.

Can you please check with latest candlepin?

hi Radek, 
I remember this issue is only for stage candlepin, but now I can duplicate it for satellite server

As I said, this is server side issue, virt-who can't tell if the owner and env is correct. It just sends it to the server and then the server has to tell if it's correct.

So I'm moving this bug to candlepin.

Tested with all pertinent versions of candlepin for satellite. I could not reproduce the failure as originally described.

Reproduce it on candlepin-0.9.49.11-1.el7.noarch(Satellite-6.1.0-RHEL-7-20160209.1/), Therefore, reopen it. 

Reproduced version:
Satellite-6.1.0-RHEL-7-20160209.1
candlepin-0.9.49.11-1.el7.noarch
katello-2.2.0.18-1.el7sat.noarch
foreman-1.7.2.53-1.el7sat.noarch

Reproduced process:
1. Register system to satellite
[root@sgi-xe270-01 ~]# subscription-manager  identity
system identity: 2998a4bc-1b79-43d9-8580-dd26a404e33c
name: sgi-xe270-01.rhts.eng.bos.redhat.com
org name: Default Organization
org ID: Default_Organization
environment name: Library

2. run virt-who with an wrong owner and env and check virt-who's log.
[root@sgi-xe270-01 ~]# virt-who --hyperv --hyperv-owner=xxxxxx --hyperv-env=xxxxx --hyperv-server=10.73.5.227 --hyperv-username=administrator --hyperv-password=Welcome1 -d
2016-03-03 02:34:26,933 [virtwho.init INFO] MainProcess(11414):MainThread @virtwho.py:parseOptions:630 - Using reporter_id='sgi-xe270-01.rhts.eng.bos.redhat.com'
2016-03-03 02:34:26,937 [virtwho.init INFO] MainProcess(11414):MainThread @virtwho.py:main:722 - Using configuration "env/cmdline" ("hyperv" mode)
2016-03-03 02:34:26,940 [virtwho.main DEBUG] MainProcess(11414):MainThread @virtwho.py:run:229 - Starting infinite loop with 60 seconds interval
2016-03-03 02:34:27,088 [virtwho.env_cmdline DEBUG] MainProcess(11414):MainThread @hyperv.py:__init__:473 - Hyper-V url: http://10.73.5.227:5985/wsman
2016-03-03 02:34:27,091 [virtwho.env_cmdline DEBUG] HyperV-1(11421):MainThread @virt.py:run:358 - Virt backend 'env/cmdline' started
2016-03-03 02:34:28,410 [virtwho.env_cmdline DEBUG] HyperV-1(11421):MainThread @hyperv.py:retry_ntlm_negotitate:67 - Using NTLM authentication
2016-03-03 02:34:29,766 [virtwho.env_cmdline DEBUG] HyperV-1(11421):MainThread @hyperv.py:retry_ntlm_authenticate:80 - Sending NTLM authentication data
2016-03-03 02:34:30,482 [virtwho.env_cmdline DEBUG] HyperV-1(11421):MainThread @hyperv.py:retry_ntlm_authenticate:103 - NTLM authentication successful
2016-03-03 02:34:30,493 [virtwho.env_cmdline DEBUG] HyperV-1(11421):MainThread @hyperv.py:getHostGuestMapping:521 - Unable to enumerate using root/virtualization namespace, trying root/virtualization/v2 namespace
2016-03-03 02:34:42,289 [virtwho.env_cmdline DEBUG] HyperV-1(11421):MainThread @virt.py:enqueue:351 - Report gathered, putting to queue for sending
2016-03-03 02:34:42,312 [virtwho.main DEBUG] MainProcess(11414):MainThread @subscriptionmanager.py:_connect:121 - Authenticating with certificate: /etc/pki/consumer/cert.pem
2016-03-03 02:34:42,901 [virtwho.main DEBUG] MainProcess(11414):MainThread @subscriptionmanager.py:hypervisorCheckIn:162 - Checking if server has capability 'hypervisor_async'
2016-03-03 02:34:43,513 [virtwho.main DEBUG] MainProcess(11414):MainThread @subscriptionmanager.py:hypervisorCheckIn:174 - Server does not have 'hypervisors_async' capability
2016-03-03 02:34:43,513 [virtwho.main INFO] MainProcess(11414):MainThread @subscriptionmanager.py:hypervisorCheckIn:185 - Sending update in hosts-to-guests mapping for config "env/cmdline": 1 hypervisors and 1 guests found
2016-03-03 02:34:43,513 [virtwho.main DEBUG] MainProcess(11414):MainThread @subscriptionmanager.py:hypervisorCheckIn:186 - Host-to-guest mapping: {
    "564D4704-757E-A977-F67F-5402B8860710": [
        {
            "guestId": "32710A7E-94A9-A445-944E-16C01BFA63B3", 
            "state": 1, 
            "attributes": {
                "active": 1, 
                "hypervisorVersion": "6.3.9600.16404", 
                "virtWhoType": "hyperv", 
                "hypervisorType": "hyperv"
            }
        }
    ]
}
2016-03-03 02:34:44,751 [virtwho.main DEBUG] MainProcess(11414):MainThread @virtwho.py:send_current_report:159 - Report for config "env/cmdline" sent

Result:
Virt-who still can send host/guest mapping info to satellite.

I am not able to reproduce using an invalid organization against candlepin-0.9.49.11-1


----------------------

2016-03-03 17:08:55,834 [virtwho.init DEBUG] MainProcess(21433):MainThread @virtwho.py:__init__:125 - Using config named 'fake'
2016-03-03 17:08:55,834 [virtwho.init INFO] MainProcess(21433):MainThread @virtwho.py:main:736 - Using configuration "fake" ("fake" mode)
2016-03-03 17:08:55,884 [virtwho.fake DEBUG] FakeVirt-1(21437):MainThread @virt.py:run:359 - Virt backend 'fake' started
2016-03-03 17:08:55,885 [virtwho.fake DEBUG] FakeVirt-1(21437):MainThread @virt.py:enqueue:352 - Report gathered, putting to queue for sending
2016-03-03 17:08:55,895 [virtwho.main DEBUG] MainProcess(21433):MainThread @subscriptionmanager.py:_connect:121 - Authenticating with certificate: /etc/pki/consumer/cert.pem
2016-03-03 17:08:55,906 [virtwho.main DEBUG] MainProcess(21433):MainThread @subscriptionmanager.py:hypervisorCheckIn:162 - Checking if server has capability 'hypervisor_async'
2016-03-03 17:08:55,915 [virtwho.main DEBUG] MainProcess(21433):MainThread @subscriptionmanager.py:hypervisorCheckIn:174 - Server does not have 'hypervisors_async' capability
2016-03-03 17:08:55,915 [virtwho.main INFO] MainProcess(21433):MainThread @subscriptionmanager.py:hypervisorCheckIn:185 - Sending update in hosts-to-guests mapping for config "fake": 2 hypervisors and 4 guests found
2016-03-03 17:08:55,915 [virtwho.main DEBUG] MainProcess(21433):MainThread @subscriptionmanager.py:hypervisorCheckIn:186 - Host-to-guest mapping: {
    "ec071dd1-9059-4a36-ad8e-7a1a46734c72": [
        {
            "guestId": "2968925c-8603-4192-b6fc-783d114110de", 
            "state": 1, 
            "attributes": {
                "active": 1, 
                "hypervisorVersion": "", 
                "virtWhoType": "fake", 
                "hypervisorType": "fake"
            }
        }, 
        {
            "guestId": "eb46dc1f-05aa-48f1-95b0-82c95007329a", 
            "state": 5, 
            "attributes": {
                "active": 0, 
                "virtWhoType": "fake"
            }
        }
    ], 
    "d965733b-1908-4579-a11c-381243138d32": [
        {
            "guestId": "3a9bf950-55ad-4480-b985-bd5e503609f0", 
            "state": 1, 
            "attributes": {
                "active": 1, 
                "hypervisorVersion": "", 
                "virtWhoType": "fake", 
                "hypervisorType": "fake"
            }
        }, 
        {
            "guestId": "eb46dc1f-05aa-48f1-95b0-82c95007329a", 
            "state": 5, 
            "attributes": {
                "active": 0, 
                "virtWhoType": "fake"
            }
        }
    ]
}
2016-03-03 17:08:55,947 [virtwho.main ERROR] MainProcess(21433):MainThread @virtwho.py:send:201 - Unable to send data: Communication with subscription manager failed with code 404: Organization with id lolfake could not be found.
2016-03-03 17:08:55,947 [virtwho.main DEBUG] MainProcess(21433):MainThread @virtwho.py:send_current_report:166 - Report from "fake" failed to sent
2016-03-03 17:08:55,948 [virtwho.main DEBUG] MainProcess(21433):MainThread @virtwho.py:<module>:828 - virt-who terminated
2016-03-03 17:08:55,948 [virtwho.main DEBUG] MainProcess(21433):MainThread @virtwho.py:terminate:352 - virt-who is shutting down


----------------------------------------------------------------------------

➜  virt-who git:(master) ✗ subscription-manager version
server type: Red Hat Subscription Management
subscription management server: 0.9.49.11-1
subscription management rules: 5.16
subscription-manager: 1.16.8-3-2-gea726d1
python-rhsm: 1.16.5-1-2-gbdcfee3



-------------------------------------------


The above is when I register directly to candlepin.

It seems that candlepin does not do anything and has not done anything with the environment sent as a query parameter by virt-who.


Radek,

What is the historical significance of virt-who sending an environment along with a report?

What is expected of candlepin?

Please see comment 7 above

The python-rhsm API function `hypervisorCheckIn` requires env argument: https://github.com/candlepin/python-rhsm/blob/master/src/rhsm/connection.py#L915

It was there when the first version of virt-who was being implemented. So I thought it's something important and added commandline and config option for that.

If it is not needed, we can remove it from required config and commandline options and silently ignore it for compatibility.

Per 6.3 planning, moving out non acked bugs to the backlog

Chris, did you test this integrated with Satellite or with Candlepin only?

Barnaby,

With candlepin directly only.
I can try again with an older version of satellite. My guess is the problem was fixed in newer versions of satellite. At any rate I do not believe this to be a candlepin.

Leaving a needinfo on bcourt to move this to the right component as I am unsure where this needs to go.

Chris,

If we know that the owner is being validated on the Candlepin side, please validate with a newer version of Satellite to ensure that the environment is being validated as well. The validation can be happening either in Candlepin (if we know about it) or in Katello but one of the two needs to be checking to provide a good customer experience. If Candlepin knows about all the environments for an owner when the call comes in, and we receive the parameter that specifies an environment, then why wouldn't we validate it?

Barnaby,

Running a similar test against the sat-ga-rhel7 vagrant box in forklift/sat-deploy results in a failure in virt-who (which is the proper expected behaviour).

Setting either or both of the owner or env to a bad value returns a 403 Access Denied when virt-who attempts the hypervisor checkin.


I believe this is fixed in virt-who/satellite latest as such I'm closing this as CURRENT_RELEASE. If anyone believes this is in error, please re-open the bug.


Thanks!