On 09/05/2014 12:55 PM, Shanil S wrote:
Hi Juan,
Thanks for your reply.
I tried with the above but i was unable to find the 'iwashere.txt' after
executing the above xml.
I repeated the test, this time with 3.4, and it worked fine for me. As
the formatting of the XML is very important I'd suggest that you take
the attached script (instead of copy & paste from the mail), change the
password and VM id and run it.
There are two kind of things that can go wrong here. One is that the
engine/VDSM combination may not be generating the right file. To verify
this start the VM with the attached script, and once it is started go to
the hypervisor where it is running and find the corresponding qemu process:
# ps -ef | grep -- '-name myvm'
This will give you a very long command line. That command line should
include a "-drive" option containing the full path of the disk image
generated by the engine/VDSM, something like this:
-drive
file=/var/run/vdsm/payload/b5f087d4-022d-4d5f-8a1e-268c562c7bb1.b6fcddff571bb8c2028c61b623d172a6.img
To inspect its content make a copy (just in case) and mount it:
# cp -drive
file=/var/run/vdsm/payload/b5f087d4-022d-4d5f-8a1e-268c562c7bb1.b6fcddff571bb8c2028c61b623d172a6.img
/root/my.img
# mount -o loop,ro /root/my.img /mnt
Inspect the content:
# find /mnt
/mnt/openstack
/mnt/openstack/content
/mnt/openstack/content/0000
/mnt/openstack/latest
/mnt/openstack/latest/meta_data.json
/mnt/openstack/latest/user_data
The content of the custom-script should be at the end of the "user_data"
file, so take a look at that:
# cat /mnt/openstack/latest/user_data
#cloud-config
ssh_pwauth: true
disable_root: 0
output:
all: '>> /var/log/cloud-init-output.log'
user: root
password: mypassword
chpasswd:
expire: false
runcmd:
- 'sed -i ''/^datasource_list: /d'' /etc/cloud/cloud.cfg; echo
''datasource_list:
["NoCloud", "ConfigDrive"]'' >>
/etc/cloud/cloud.cfg'
runcmd:
- echo "I was here!" > /iwashere.txt
If your custom script isn't there then there is some problem in the
engine/VDSM side, otherwise the problem is probably in cloud-init
itself, and we will need someone with more knowledge of cloud-init to
debug it.
Don't forget to umount the file when finished:
# umount /mnt
On Fri, Sep 5, 2014 at 3:00 PM, Juan Hernandez <jhernand(a)redhat.com
<mailto:jhernand@redhat.com>> wrote:
On 09/05/2014 10:46 AM, Sven Kieske wrote:
>
>
> Am 05.09.2014 10:27, schrieb Juan Hernandez:
>> Trying to make an example for this I discovered that the
"custom_script"
>> element is currently ignored if the "cloud_init" element is
present.
>> Instead we are taking the content of the first "file" element from
the
>> "cloud_init" element and appending it to the cloud-init
configuration
>> file. I believe that this is a bug, as it breaks backwards compatibility:
>>
>>
https://bugzilla.redhat.com/1138564
>
> Thanks for the report, I just proposed this as a blocker for the 3.4.4
> release as it is a clear regression.
> Also I rely on this functionality in my 3.3. setup and I want to upgrade
> to 3.4 so I can't upgrade until this is fixed and released.
Agree, I set the bug as a blocker for 3.4.4.
>>
>> However, you can exploit this bug to do what you want. This is an example:
>
> Well I guess this is a pretty bad idea, because it will just work
> until the bug is fixed?
>
No, what I proposed in the example is to put the custom script in both
the first "file" inside "clud_init" and in the
"custom_script" element.
That should work with the current status and also if/when we fix the
bug.
--
Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
3ºD, 28016 Madrid, Spain
Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.