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