Re: [ovirt-users] Passing custom script to cloud init using api

Hi Juan, Okay.. Thanks.. its working. 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 ? -- Regards Shanil On Fri, Sep 5, 2014 at 10:08 PM, Juan Hernandez <jhernand(a)redhat.com&gt; wrote: > 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. >