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

[Shanil S]

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 at redhat.com> 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 at redhat.com
> > <mailto:jhernand at 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/users/attachments/20140910/3118b872/attachment-0001.html>