Bug 1029885

Summary: cloud-init testcase does not work in engine 3.3.1
Product: [Retired] oVirt Reporter: Sven Kieske <s.kieske>
Component: ovirt-engine-coreAssignee: Omer Frenkel <ofrenkel>
Status: CLOSED CANTFIX QA Contact:
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 3.3CC: acathrow, iheim, michal.skrivanek, ofrenkel, sbonazzo, s.kieske, yeylon
Target Milestone: ---   
Target Release: 3.3.2   
Hardware: x86_64   
OS: Linux   
Whiteboard: virt
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-12-12 10:10:54 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
cloudinit logfile none

Description Sven Kieske 2013-11-13 13:14:47 UTC
Created attachment 823399 [details]
cloudinit logfile

Description of problem:
We can not reproduce the testcase mentioned in the ovirt-wiki
regarding the new cloud-init feature in 3.3.1

Version-Release number of selected component (if applicable):
ovirt-engine 3.3.1 from ovirt.org beta repo on centos 6.4 x64
compute node is centos 6.4 x64 with latest vdsm from stable ovirt.org repo
vm is a centOS minimal x64 on a local storage dc
How reproducible:


Steps to Reproduce:
1. Create new VM (via webadmin)
2.Install OS (CentOs 6.4)
3.Install cloud-init  (via yum from epel repo)
4. shutdown vm
5. "run once" vm -> configure cloud-init options e.g. set hostname, root pw, IP..


Actual results:
cloud-init makes a data-source lookup for ec2 (GET http://169.254.169.254/ )
which fails

Expected results:
ovirt-engine passes the options from webadmin to the vm, cloud init reads
these and uses them, as described in the test case.

Additional info:
See the attached log from cloud-init for more details.

if you need further logs from management or vdsm, let me know.

Comment 1 Sven Kieske 2013-11-13 13:26:00 UTC
PS: installed cloud-init version from epel is 0.6.3-0.12.bzr532
Is this to old?
If the answer is yes, is there any chance of getting a newer version in epel?
Maybe utilizing this build-script: https://github.com/jamiesonbecker/cloudinit-rhel/blob/master/cloud-init-build.sh

Comment 2 Sven Kieske 2013-11-13 13:41:04 UTC
addtional debugging revealed, that ovirt pushes the metadata via a cdrom-device.
here is the virsh dumpxml:
..
<disk type='file' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <source file='/var/run/vdsm/payload/00977c31-2076-4b38-bdbc-5066ca1f3c89.da80bf145a28800bec9293d23b4bac8b.img' startupPolicy='optional'/>
      <target dev='hdd' bus='ide'/>
      <readonly/>
      <serial></serial>
      <boot order='2'/>
      <alias name='ide0-1-1'/>
      <address type='drive' controller='0' bus='1' target='0' unit='1'/>
    </disk>
..
but cloud-init supports cdrom-based data-sources just since version 0.7.2:
https://bugs.launchpad.net/cloud-init/+bug/1100545

So I guess it should work with 0.7.2.
I will try to build or get the appropriate rpm and report back.

Comment 3 Sven Kieske 2013-11-13 15:44:28 UTC
Well we tried to build cloud-init from source following this buildscript for
rhel: https://github.com/jamiesonbecker/cloudinit-rhel/blob/master/cloud-init-build.sh

after several tweaks to it we have given up so far, as we are in package
dependency hell.
cloud-init 0.7.4. requires pyhton-jsonpatch and pyserial, both not available via
rpm, but the buildscripts requires them as rpm packages, so it isn't satisfied
with installation through pip..

So if upstream could build a new cloud-init version for epel or any rpm
or backport the ability to open cd-rom as data-source this would be great.

So far this feature can't work with this version of cloud-init.

Comment 4 Itamar Heim 2013-11-15 06:09:00 UTC
0.7.2 slated to be in 6.5

Comment 5 Sven Kieske 2013-11-15 07:59:13 UTC
So this feature will not work in any RHEL based distro ≤ 6.5 ?
That are not very good news for provisioning RHEL based distros.

Comment 6 Itamar Heim 2013-11-15 17:08:19 UTC
have you tried building 0.7.2 rather than 0.7.4?

Comment 7 Sven Kieske 2013-11-19 16:57:30 UTC
I have not tried it, but will, maybe tomorrow.

Comment 8 Sven Kieske 2013-11-28 07:43:23 UTC
I have no time atm to test the manual build of 0.7.2. on CentOS 6.4

What does it mean, if you say this will be fixed in 3.3.2?

For the CD-ROM it's not a matter of ovirt, but of the cloud-init version inside
the vm, so do you plan to backport / release appropriate versions for Enterprise Linux < 6.5 ? Or do you just advise to upgrade to RHEL/CentOS 6.5 (which is not always possible)?

Or do you switch the method, how you pass the data to the vm?

If the latter is the case, are there any links to code changes?

ATM I'm writing a helper script to take the metadata, parse it, and make some
changes to the vm, so if you change how data gets passed to the vm, you should
make this as transparent as possible, because you may have users who rely on the
current mechanism.

Maybe this should be discussed on the Users ML or via IRC?

Comment 9 Sandro Bonazzola 2013-12-11 08:17:51 UTC
Is this solved by fix introduced for bug 1039009 ?
Or is this fixed by upgrading CentOS / RHEL to 6.5?

Comment 10 Omer Frenkel 2013-12-11 10:02:01 UTC
(In reply to Sandro Bonazzola from comment #9)
> Is this solved by fix introduced for bug 1039009 ?
> Or is this fixed by upgrading CentOS / RHEL to 6.5?

upgrade is needed, or somehow get cloud-init 0.7.2 built on older versions, which im not sure is possible or not

Comment 11 Itamar Heim 2013-12-11 10:37:23 UTC
Sven - is this still an issue with these rpms released for .el6 now?

Comment 12 Sven Kieske 2013-12-11 12:08:43 UTC
If this works in 6.5 this is fixed for me, but I did not test it yet if
it works in CentOS 6.5.

Comment 13 Sandro Bonazzola 2013-12-12 10:10:54 UTC
Removing from 3.3.2 blockers, closing as cantfix as discussed in
http://resources.ovirt.org/meetings/ovirt/2013/ovirt.2013-12-11-15.01.log.html

EL >= 6.5 or cloud-init >= 0.7.2 are needed for having this working.