Description of problem: If I set an wrong env option, the virt-who still can update the mapping info to stage candlepin, no any error message output.... Version-Release number of selected component (if applicable): - RHEL6.7-20150617.0-Client-x86_64(KVM) against Stage Candlepin - subscription-manager-1.14.10-1.el6.x86_64 - virt-who-0.12-10.el6.noarch - libvirt-0.10.2-54.el6.x86_64 - python-rhsm-1.14.3-1.el6.x86_64 How reproducible: always Steps to Reproduce: 1. stop virt-who service # /etc/init.d/virt-who stop # ps -ef |grep virt-who 2. start virt-who with the right libvirt-env value [--libvirt-env=7616313] # virt-who --libvirt --libvirt-owner=7616313 --libvirt-env=7616313 --libvirt-server=10.66.128.11 --libvirt-username=root --libvirt-password=redhat -o -d 2015-06-26 17:09:17,557 INFO: Using configuration "env/cmdline" ("libvirt" mode) 2015-06-26 17:09:17,694 INFO: Protocol is not specified in libvirt url, using qemu+ssh:// 2015-06-26 17:09:17,695 INFO: Libvirt path is not specified in the url, using /system 2015-06-26 17:09:17,695 INFO: Using libvirt url: qemu+ssh://root.128.11/system?no_tty=1 2015-06-26 17:09:18,105 DEBUG: Virtual machine found: rhel-7.1: 02ac41dc-a755-e14d-e09d-0c2fb476b26f 2015-06-26 17:09:18,110 DEBUG: Virtual machine found: 128-11-rhel-7.1: 34aa5936-b297-34ec-0525-022ad4c06927 2015-06-26 17:09:18,111 DEBUG: Libvirt domains found: [{'guestId': '02ac41dc-a755-e14d-e09d-0c2fb476b26f', 'attributes': {'active': 1, 'virtWhoType': 'libvirt', 'hypervisorType': 'QEMU'}, 'state': 1}, {'guestId': '34aa5936-b297-34ec-0525-022ad4c06927', 'attributes': {'active': 1, 'virtWhoType': 'libvirt', 'hypervisorType': 'QEMU'}, 'state': 1}] 2015-06-26 17:09:18,150 INFO: Sending update in hosts-to-guests mapping: {'a84038db-b8f6-de11-ab4f-34cfc47eebf6': [{'guestId': '02ac41dc-a755-e14d-e09d-0c2fb476b26f', 'attributes': {'active': 1, 'virtWhoType': 'libvirt', 'hypervisorType': 'QEMU'}, 'state': 1}, {'guestId': '34aa5936-b297-34ec-0525-022ad4c06927', 'attributes': {'active': 1, 'virtWhoType': 'libvirt', 'hypervisorType': 'QEMU'}, 'state': 1}]} 2015-06-26 17:09:18,150 DEBUG: Authenticating with certificate: /etc/pki/consumer/cert.pem 2015-06-26 17:09:24,147 INFO: virt-who host/guest association update successful 2015-06-26 17:09:24,147 DEBUG: Association for config env/cmdline gathered 2015-06-26 17:09:24,148 DEBUG: virt-who shut down started 3. start virt-who with the right libvirt-env value [--libvirt-env=xxxxxxxx] # virt-who --libvirt --libvirt-owner=7616313 --libvirt-env=xxxxxxxx --libvirt-server=10.66.128.11 --libvirt-username=root --libvirt-password=redhat -o -d 2015-06-26 17:10:52,389 INFO: Using configuration "env/cmdline" ("libvirt" mode) 2015-06-26 17:10:52,501 INFO: Protocol is not specified in libvirt url, using qemu+ssh:// 2015-06-26 17:10:52,502 INFO: Libvirt path is not specified in the url, using /system 2015-06-26 17:10:52,502 INFO: Using libvirt url: qemu+ssh://root.128.11/system?no_tty=1 2015-06-26 17:10:52,880 DEBUG: Virtual machine found: rhel-7.1: 02ac41dc-a755-e14d-e09d-0c2fb476b26f 2015-06-26 17:10:52,886 DEBUG: Virtual machine found: 128-11-rhel-7.1: 34aa5936-b297-34ec-0525-022ad4c06927 2015-06-26 17:10:52,887 DEBUG: Libvirt domains found: [{'guestId': '02ac41dc-a755-e14d-e09d-0c2fb476b26f', 'attributes': {'active': 1, 'virtWhoType': 'libvirt', 'hypervisorType': 'QEMU'}, 'state': 1}, {'guestId': '34aa5936-b297-34ec-0525-022ad4c06927', 'attributes': {'active': 1, 'virtWhoType': 'libvirt', 'hypervisorType': 'QEMU'}, 'state': 1}] 2015-06-26 17:10:52,928 INFO: Sending update in hosts-to-guests mapping: {'a84038db-b8f6-de11-ab4f-34cfc47eebf6': [{'guestId': '02ac41dc-a755-e14d-e09d-0c2fb476b26f', 'attributes': {'active': 1, 'virtWhoType': 'libvirt', 'hypervisorType': 'QEMU'}, 'state': 1}, {'guestId': '34aa5936-b297-34ec-0525-022ad4c06927', 'attributes': {'active': 1, 'virtWhoType': 'libvirt', 'hypervisorType': 'QEMU'}, 'state': 1}]} 2015-06-26 17:10:52,929 DEBUG: Authenticating with certificate: /etc/pki/consumer/cert.pem 2015-06-26 17:10:59,495 INFO: virt-who host/guest association update successful 2015-06-26 17:10:59,495 DEBUG: Association for config env/cmdline gathered 2015-06-26 17:10:59,496 DEBUG: virt-who shut down started Actual results: with an wrong libvirt-env value, virt-who also can send the mapping info normally. Expected results: with an wrong libvirt-env value, virt-who should show the error or warning message, and don't send the mapping info to stage candlepin Additional info:
Closing after unsuccessfully trying to modify product/component of the bug *** This bug has been marked as a duplicate of bug 1231308 ***
*** This bug has been marked as a duplicate of bug 1269723 ***
*** Bug 1269723 has been marked as a duplicate of this bug. ***
I can see similar behavior and I confirm that this is a Candlepin Server issue. I have had trouble understanding what exactly should --libvirt-env=7616313 do - from user perspective. I understand there should be an error message if non-existent environment for that owner is used. But what is the positive use case here? What if the environment does exist? Current code seems to do nothing with --libvirt-env vaulue... My current thoughts are: 1) when -libvirt-env=7616313 is used the created GUEST consumers on the server are created inside of the 7616313 environment 2) Do we require that 1) only happens when the host (hypervisor) is also in that environment already? What if the hypervisor consumer has been already created and is in different environment?
Hi Filip, we can configure virt-who by following 3 methods: 1). /etc/sysconfig/virt-who, such as: VIRTWHO_LIBVIRT=1 VIRTWHO_LIBVIRT_OWNER=7661967 VIRTWHO_LIBVIRT_ENV=7661967 VIRTWHO_LIBVIRT_SERVER=10.66.129.60 VIRTWHO_LIBVIRT_USERNAME=root VIRTWHO_LIBVIRT_PASSWORD=redhat 2). /etc/virt-who.d/, create a /etc/virt-who.d/libvirt.conf as example: [test-libvirt] type=libvirt server=10.66.129.60 username=root password=redhat owner=7661967 env=7661967 3). virt-who CLI, such as: # virt-who --libvirt --libvirt-owner=7661967 --libvirt-env=7661967 --libvirt-server=10.66.129.60 --libvirt-username=root --libvirt-password=redhat -o -d From our QE side, we need to make sure the above three configuration's options work as expected, take env option as example: 1). config a right env value, virt-who should run normally and send the mapping info to server 2). config an wrong env value, virt-who should feedback some error or warning message and can't send the mapping info to server 3). config a none env value, virt-who should feedback as step_2 I don't know candlepin code how to check the env value, but according our testing, if we provide an wrong env value, virt-who still can send the mapping info to server, it's not expected result.
Thanks for detailed info I think I understand what you mean.
Looking at this again I think I still don't understand. What is correct and incorrect value for the env option? A consumer may be in many environments. I still don't understand what is the use of env value here. Why would a user specify it?
hi Filip, our test process as following: for Stage Candlepin: 1). check the org id by identity # subscription-manager identity system identity: 72b3f55e-f6ea-469c-b346-e867ed0e3a5b name: hp-z220-12.qe.lab.eng.nay.redhat.com org name: 7661967 org ID: 7661967 2). set owner and env with org id VIRTWHO_LIBVIRT_OWNER=7661967 VIRTWHO_LIBVIRT_ENV=7661967 VIRTWHO_LIBVIRT_SERVER=10.66.129.60 VIRTWHO_LIBVIRT_USERNAME=root VIRTWHO_LIBVIRT_PASSWORD=redhat we also don't know what env value is correct, it seems there is no default and unique env value supported from stage candlepin, because any value is ok. I run "subscription-manager environments" to check the env for stage candlepin, it shows the server does not support environments. # subscription-manager environments Username: virt-who-perf Password: Error: Server does not support environments. so I think if the customers can register or subscribe to stage candlepin without env, virt-who should remove the env option from config files.
Eko, thank you for detailed reasoning about this, I appreciate it. I will try to pull more information about environments and business background of this. It seems to me it's not entirely clear yet.
See Rich Jerrido's response [1]. The thing is that *env switches are not handled by Candlepin itself. The env swiches are used to do authentication against other Sat 6 products (e.g. Katello). In short - I think this shouldn't be tested with hosted. [1] The various *ENV switches are used by platforms that support environments (such as Satellite 6) to denote which lifecycle environment (e.g. Library, Dev, Prod, etc) that a consumer is associated with. In the hosted setup, environments don't exist. In the on-premise products they do.