Bug 1253475 - [Spacewalk 2.3] [CentOS7] Koan cannot use the current virt-install
[Spacewalk 2.3] [CentOS7] Koan cannot use the current virt-install
Product: Spacewalk
Classification: Community
Component: Server (Show other bugs)
x86_64 Linux
unspecified Severity medium
: ---
: ---
Assigned To: Jan Dobes
Red Hat Satellite QA List
: 1320136 (view as bug list)
Depends On:
Blocks: spacewalk-review space27
  Show dependency treegraph
Reported: 2015-08-13 14:57 EDT by mriswithe
Modified: 2017-09-28 14:09 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2017-07-19 17:02:00 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description mriswithe 2015-08-13 14:57:38 EDT
Description of problem:
Attempting to provision a VM from Spacewalk 2.3 (on CentOS7) to a registered KVM host on CentOS7 from the spacewalk GUI will fail if you are running virt-install-1.1.0-12.el7.noarch. You have to revert to the virt-install and virt-manager-common version that came with the base CentOS7 release, virt-install-0.10.0-20.el7.noarch. 

Version-Release number of selected component (if applicable):
Installed Koan versions:

Working versions of virt-install:

Non-working versions of virt-install
[root@node1 kvm]# rpm -q virt-install virt-manager-common 

How reproducible:
100% of the time

Steps to Reproduce:
1. Install/configure Spacewalk 2.3 (CentOS7 may or may not be necessary)
2. Register KVM host (CentOS7 would be necessary) also add provisioning/provisioning platform entitlement
3. Update KVM host to current Virt-install version, 1.1.0-12.el7
4. Configure kickstart
5. Attempt to provision a VM from spacewalk GUI using kickstart
6. Run rhn_check -vv from KVM host, you will get the error in the "Actual Results" section

Actual results:
Kickstart shows failed in spacewalk once rhn_check is run or OSAD runs the check. You get the following error. The important part is towards the end, raise Exception("expected version format differs"), and seems to be this section of code: 


[root@node2 virt-rpms]# rhn_check -v
- looking for Cobbler at http://spacewalk.internal.mriswithe.com:443/cobbler_api
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/koan/utils.py", line 570, in __try_connect
  File "/usr/lib64/python2.7/xmlrpclib.py", line 1224, in __call__
    return self.__send(self.__name, args)
  File "/usr/lib64/python2.7/xmlrpclib.py", line 1578, in __request
  File "/usr/lib64/python2.7/xmlrpclib.py", line 1264, in request
    return self.single_request(host, handler, request_body, verbose)
  File "/usr/lib64/python2.7/xmlrpclib.py", line 1312, in single_request
ProtocolError: <ProtocolError for spacewalk.internal.mriswithe.com:443/cobbler_api: 400 Bad Request>
- looking for Cobbler at https://spacewalk.internal.mriswithe.com:443/cobbler_api
- reading URL: http://spacewalk.internal.mriswithe.com/cblr/svc/op/ks/system/node2.internal.mriswithe.com:1:herewego
install_tree: http://spacewalk.internal.mriswithe.com/ty/0KNo9KGD
- ['/usr/bin/virt-install', '--version']
<type 'exceptions.Exception'>
expected version format differs
  File "/usr/share/rhn/spacewalkkoan/spacewalkkoan.py", line 257, in initiate_guest
   File "/usr/lib/python2.7/site-packages/koan/app.py", line 424, in run
   File "/usr/lib/python2.7/site-packages/koan/app.py", line 844, in virt
    return self.net_install(after_download)
   File "/usr/lib/python2.7/site-packages/koan/app.py", line 636, in net_install
    if len(version_str) == 0 and not utils.check_version_greater_or_equal(version_str.strip(), "0.2.0"):
   File "/usr/lib/python2.7/site-packages/koan/utils.py", line 591, in check_version_greater_or_equal
    raise Exception("expected version format differs")

Expected results:
Install completes normally as virt-install is installed. 

Additional info:
It may be resolved in one of the last 3 commits to app.py here: https://github.com/cobbler/koan/commits/master/koan/app.py
Comment 1 T. Loehnert 2015-09-14 07:01:01 EDT
Same problem here with cobbler and koan on CentOS 7.1

Software installed:

CentOS Linux release 7.1.1503

cobbler 2.6.9-1.el7
koan 2.6.9-1.el7
virt-install 1.1.0-12.el7
Comment 2 Yuri Arabadji 2015-12-21 15:08:50 EST
+1 and we've got a RHEL subscription.
Comment 3 Tomas Lestach 2016-02-19 03:53:55 EST
Resetting the assignee to the default owner ...
Comment 4 Tim Coote 2016-03-10 07:16:37 EST
Isn't this the same underlying issue as Bug 1276896?

The upstream version of koan fixed this in December, although it's not very clear that that's in a comparable version: setup.py in koan reports a version of 2.9.0, but then again that version's dated as 2015-3-16.
Comment 5 Jan Dobes 2016-03-11 11:54:52 EST
Is the problem still there in current koan-2.6.11-1 version in EPEL?
Comment 6 T. Loehnert 2016-03-15 08:14:58 EDT
still same problem:

CentOS Linux release 7.2.1511 (Core)

installed at the moment:

koan.noarch     2.6.11-1.el7
virt-install    1.2.1-8.el7
virt-manager    1.2.1-8.el7
Comment 7 Jan Dobes 2016-03-16 07:03:54 EDT
(In reply to T. Loehnert from comment #1)
> cobbler 2.6.9-1.el7

I think this is the problem. Spacewalk is not currently working properly with newer cobbler from EPEL. You should install cobbler20 package from spacewalk repository.

I've just tried to kickstart CentOS 7 on spacewalk nigthly, it was installed succesfully. The only problems there were:

- exception when running rhn_check
- kickstart was not marked as finished in Web interface
- system was not registered to Spacewalk
Comment 8 Jan Dobes 2016-03-16 07:06:06 EDT
Exception mentioned in previous comment:

[root@localhost ~]# rhn_check
Preserve files! : []
- looking for Cobbler at http://smqa-r210-02.lab.eng.brq.redhat.com:443/cobbler_api
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/koan/utils.py", line 570, in __try_connect
  File "/usr/lib64/python2.7/xmlrpclib.py", line 1233, in __call__
    return self.__send(self.__name, args)
  File "/usr/lib64/python2.7/xmlrpclib.py", line 1587, in __request
  File "/usr/lib64/python2.7/xmlrpclib.py", line 1273, in request
    return self.single_request(host, handler, request_body, verbose)
  File "/usr/lib64/python2.7/xmlrpclib.py", line 1306, in single_request
    return self.parse_response(response)
  File "/usr/lib64/python2.7/xmlrpclib.py", line 1476, in parse_response
  File "/usr/lib64/python2.7/xmlrpclib.py", line 558, in feed
    self._parser.Parse(data, 0)
ExpatError: syntax error: line 1, column 49
Comment 9 Jan Dobes 2016-03-21 11:56:32 EDT
Note for myself: The exception is caused by trying to connect with http and 443 combination. Koan then retries it with correct parameters. In koan git is this code slightly different and it's possible the exception will disappear in future koan release.
Comment 10 Jan Dobes 2016-03-24 10:20:12 EDT
Forget about Comment #7, it's irrelevant in this bugzilla.
Comment 11 Jan Dobes 2016-03-24 11:12:36 EDT
I investigated the issue, koan is calling '/usr/bin/virt-install --version', virt-install writes it to stderr since some version and koan does not expect it. In koan git it's apparently fixed, however it was not released yet for some reason.
Comment 12 Jan Dobes 2016-03-24 11:13:44 EDT
*** Bug 1320136 has been marked as a duplicate of this bug. ***
Comment 13 Tim Coote 2016-03-25 07:59:45 EDT
Does that diagnosis support the view in comment 4?
Comment 14 Jan Dobes 2016-03-29 02:23:23 EDT
(In reply to Tim Coote from comment #13)
> Does that diagnosis support the view in comment 4?

Yes, you are right.
Comment 15 Tomáš Kašpárek 2016-05-18 08:08:16 EDT
I am afraid that this issue can not be fixed by spacewalk, as we do not own upstream koan and we ship our koan in cobbler20 package.
Comment 16 Eric Herget 2017-07-20 08:53:31 EDT
Closing this BZ because the issue is outside of our perview.  This will be resolved when the existing fix is released.
Comment 17 Eric Herget 2017-09-28 14:09:49 EDT
This BZ closed some time during 2.5, 2.6 or 2.7.  Adding to 2.7 tracking bug.

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