Hi All, From the ovirt admin panel, there is an option to give the custom script in the cloud init ( Run Once-> cloud init- > Custom script ). Is there any ways to pass the custom script to cloud init using the rest api ?

Hi Juan, Thanks for the solution. -- Regards Shanil On Tue, Sep 2, 2014 at 2:59 PM, Juan Hernandez <jhernand(a)redhat.com&gt; wrote: > On 09/02/2014 05:46 AM, Shanil S wrote: > > Hi All, > > > > From the ovirt admin panel, there is an option to give the custom script > > in the cloud init ( Run Once-> cloud init- > Custom script ). Is there > > any ways to pass the custom script to cloud init using the rest api ? > > > > The custom script should go inside the "custom_script" element inside > the "initialization" element: > > <action> > ... > <initialization> > <cloud_init>...</cloud_init> > <custom_script>your custom script</custom_script> > </initialization> > </action> > > -- > 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. >

On 09/04/2014 06:29 AM, Shanil S wrote: > Hi Juan, > > Is there anyways to specify the custom script from a file in the xml ? > ie, i have a script in a file called script.sh and i would like to > include this script in the xml with the api call. Is there any methods > for this ? > You can deploy files using cloud-init, and the run them using the custom script. Something like this: <action> ... <initialization> <cloud-init> <files> <file name="/root/myscript.sh"/> <content><![CDATA[#!/bin/sh the content of your script]]></content> </file> </files> </cloud-init> <custom_script><![CDATA[runcmd: - sh /root/myscript.sh ]]></custom_script> </initialization> </action> But I'm not a cloud-init expert, and I didn't test this, so I don't really know if the custom_script will run before or after the files are deployed. It makes more sense to run the scripts after deploying the files, but you will have to test it yourself. The content of the files and the scripts has to be embedded in the XML document that you send to the RESTAPI server, there is no way to send an XML document and a separate file. Building this kind of XML document shouldn't be complicated if you use the CDATA syntax like in the example above. Another thing that you may consider, if you have to run a complicated script or set of scripts, is to have them pre-installed in the template that you use to create the VM, then you just need to run them. > -- > Regards > Shanil > > > On Tue, Sep 2, 2014 at 3:02 PM, Shanil S <xielesshanil(a)gmail.com > <mailto:xielesshanil@gmail.com>> wrote: > > Hi Juan, > > Thanks for the solution. > > -- > Regards > Shanil > > > On Tue, Sep 2, 2014 at 2:59 PM, Juan Hernandez <jhernand(a)redhat.com > <mailto:jhernand@redhat.com>> wrote: > > On 09/02/2014 05:46 AM, Shanil S wrote: > > Hi All, > > > > From the ovirt admin panel, there is an option to give the > custom script > > in the cloud init ( Run Once-> cloud init- > Custom script ). > Is there > > any ways to pass the custom script to cloud init using the > rest api ? > > > > The custom script should go inside the "custom_script" element > inside > the "initialization" element: > > <action> > ... > <initialization> > <cloud_init>...</cloud_init> > <custom_script>your custom script</custom_script> > </initialization> > </action> > > -- > 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. > > > > > > _______________________________________________ > Users mailing list > Users(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/users > -- 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.

On 09/04/2014 10:58 AM, Shanil S wrote: > Hi Juan, > > Okay.. Thanks for your update. Also i found some sample cloud init > scripts from here > https://github.com/number5/cloud-init/tree/master/doc/examples and i > tried the following scripts > > - type: foo/wark > filename: bar > content: | > This is my payload > hello > - this is also payload > - | > multi line payload > here > - > type: text/upstart-job > filename: my-upstart.conf > content: | > Test file contents > > And run the start vm using the above script using cloud init and api, > Could you please tell me where i can find the result of the above script ? > I think the above script will create a file like my-upstart.conf > As I said I am not a cloud-init expert, so I don't really know what is the meaning or effect of this script. But I think that you need to use the "runcmd" option. For example: <action> ... <initialization> <cloud-init>...</cloud-init> <custom-script><![CDATA[runcmd: - touch /iwashere ]]></custom-script> </initialization> </action> If you use this it should run the "touch /iwashere" command, and you can check that it did verifying that the "/iwashere" file exists. As I said I didn't test this, so I may not work. I'd appreciate if you can test it, and once it works update the wiki with the correct instructions: http://www.ovirt.org/REST-Api#How_can_I_run_a_custom_script_using_cloud-i... > > On Thu, Sep 4, 2014 at 1:56 PM, Juan Hernandez <jhernand(a)redhat.com > <mailto:jhernand@redhat.com>> wrote: > > On 09/04/2014 06:29 AM, Shanil S wrote: > > Hi Juan, > > > > Is there anyways to specify the custom script from a file in the xml ? > > ie, i have a script in a file called script.sh and i would like to > > include this script in the xml with the api call. Is there any methods > > for this ? > > > > You can deploy files using cloud-init, and the run them using the custom > script. Something like this: > > <action> > ... > <initialization> > <cloud-init> > <files> > <file name="/root/myscript.sh"/> > <content><![CDATA[#!/bin/sh the content of your > script]]></content> > </file> > </files> > </cloud-init> > <custom_script><![CDATA[runcmd: > - sh /root/myscript.sh > ]]></custom_script> > </initialization> > </action> > > But I'm not a cloud-init expert, and I didn't test this, so I don't > really know if the custom_script will run before or after the files are > deployed. It makes more sense to run the scripts after deploying the > files, but you will have to test it yourself. > > The content of the files and the scripts has to be embedded in the XML > document that you send to the RESTAPI server, there is no way to send an > XML document and a separate file. Building this kind of XML document > shouldn't be complicated if you use the CDATA syntax like in the example > above. > > Another thing that you may consider, if you have to run a complicated > script or set of scripts, is to have them pre-installed in the template > that you use to create the VM, then you just need to run them. > > > -- > > Regards > > Shanil > > > > > > On Tue, Sep 2, 2014 at 3:02 PM, Shanil S <xielesshanil(a)gmail.com > <mailto:xielesshanil@gmail.com> > > <mailto:xielesshanil@gmail.com <mailto:xielesshanil@gmail.com>>> > wrote: > > > > Hi Juan, > > > > Thanks for the solution. > > > > -- > > Regards > > Shanil > > > > > > On Tue, Sep 2, 2014 at 2:59 PM, Juan Hernandez > <jhernand(a)redhat.com <mailto:jhernand@redhat.com> > > <mailto:jhernand@redhat.com <mailto:jhernand@redhat.com>>> wrote: > > > > On 09/02/2014 05:46 AM, Shanil S wrote: > > > Hi All, > > > > > > From the ovirt admin panel, there is an option to give the > > custom script > > > in the cloud init ( Run Once-> cloud init- > Custom > script ). > > Is there > > > any ways to pass the custom script to cloud init using the > > rest api ? > > > > > > > The custom script should go inside the "custom_script" element > > inside > > the "initialization" element: > > > > <action> > > ... > > <initialization> > > <cloud_init>...</cloud_init> > > <custom_script>your custom script</custom_script> > > </initialization> > > </action> > > -- 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.

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

However, you can exploit this bug to do what you want. This is an example:

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. _______________________________________________ Users mailing list Users(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/users

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.

Hi Juan, What i am planning to do is to make work the following script #cloud-config # phone_home: if this dictionary is present, then the phone_home # cloud-config module will post specified data back to the given # url # default: none # phone_home: # url: http://my.foo.bar/$INSTANCE/ # post: all # tries: 10 # phone_home: url: http://my.example.com/$INSTANCE_ID/ post: [ pub_key_dsa, pub_key_rsa, pub_key_ecdsa, instance_id ] (http://cloudinit.readthedocs.org/en/latest/topics/examples.html#run-comma...) but it wasn't working when i tried, i hope to post the above values to the specific url and get the posted details.

On Wed, Sep 10, 2014 at 10:02 AM, Shanil S <xielesshanil(a)gmail.com <mailto:xielesshanil@gmail.com>> wrote: 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 <mailto:jhernand@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(a)redhat.com <mailto:jhernand@redhat.com> > <mailto:jhernand@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. >

Hi Juan, It seems the it doesn't contains the "phone_home " section in the cat /mnt/openstack/latest/user_data the following is the output #cloud-config ssh_pwauth: true disable_root: 0 output: all: '>> /var/log/cloud-init-output.log' user: root password: admin123 chpasswd: expire: false runcmd: - 'sed -i ''/^datasource_list: /d'' /etc/cloud/cloud.cfg; echo ''datasource_list: ["NoCloud", "ConfigDrive"]'' >> /etc/cloud/cloud.cfg' but if i try with the <files> <file> <name>ignored</name> <content><![CDATA[runcmd: - echo 'Test script !' > /iwashere_test.txt ]]></content> <type>plaintext</type> </file> </files> then it will create the /iwashere_test.txt and write the contents and in that time the cat /mnt/openstack/latest/user_data is 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: admin123 chpasswd: expire: false runcmd: - 'sed -i ''/^datasource_list: /d'' /etc/cloud/cloud.cfg; echo ''datasource_list: ["NoCloud", "ConfigDrive"]'' >> /etc/cloud/cloud.cfg' runcmd: - echo 'Test script !' > /iwashere_test.txt so, i think the custom script section is not working, i am attaching the vm log as a screenshot.

On Wed, Sep 10, 2014 at 2:07 PM, Juan Hernandez <jhernand(a)redhat.com <mailto:jhernand@redhat.com>> wrote: On 09/10/2014 06:44 AM, Shanil S wrote: > Hi Juan, > > What i am planning to do is to make work the following script > > #cloud-config > > # phone_home: if this dictionary is present, then the phone_home > # cloud-config module will post specified data back to the given > # url > # default: none > # phone_home: > # url: http://my.foo.bar/$INSTANCE/ > # post: all > # tries: 10 > # > phone_home: > url: http://my.example.com/$INSTANCE_ID/ > post: [ pub_key_dsa, pub_key_rsa, pub_key_ecdsa, instance_id ] > > (http://cloudinit.readthedocs.org/en/latest/topics/examples.html#run-comma...) > > but it wasn't working when i tried, i hope to post the above values to > the specific url and get the posted details. > I think it should work, but it depends completely on cloud-init itself. I'd suggest you check the content of the generated cloud-init configuration file (as described in a previous mail). If it contains the "phone_home" section then you can discard a problem with oVirt, and focus on clud-init. > > On Wed, Sep 10, 2014 at 10:02 AM, Shanil S <xielesshanil(a)gmail.com <mailto:xielesshanil@gmail.com> > <mailto:xielesshanil@gmail.com <mailto:xielesshanil@gmail.com>>> wrote: > > 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 <mailto:jhernand@redhat.com> > <mailto:jhernand@redhat.com <mailto:jhernand@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(a)redhat.com <mailto:jhernand@redhat.com> <mailto:jhernand@redhat.com <mailto:jhernand@redhat.com>> > > <mailto:jhernand@redhat.com <mailto:jhernand@redhat.com> <mailto:jhernand@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. > > >

Hi Juan, Okay sure.. The following xml i used <action> <vm> <os> <boot dev='cdrom'/> </os> <initialization> <cloud_init> <host> <address>test2</address> </host> <users> <user> <user_name>root</user_name> <password>test</password> </user> </users> <network_configuration> <nics> <nic> <interface>virtio</interface> <name>eth0</name> <boot_protocol>none</boot_protocol> <on_boot>true</on_boot> </nic> </nics> <dns> <servers> <host> <address>x.x.x.x</address> </host> </servers> </dns> </network_configuration> </cloud_init> <custom_script> #cloud-config phone_home: url: http://x.x.com/api/xx/api_receive.php </custom_script> </initialization> </vm> </action> -- Regards Shanil On Thu, Sep 11, 2014 at 1:48 PM, Juan Hernandez <jhernand(a)redhat.com&gt; wrote: > On 09/11/2014 06:54 AM, Shanil S wrote: > > Hi Juan, > > > > It seems the it doesn't contains the "phone_home " section in the cat > > /mnt/openstack/latest/user_data > > > > the following is the output > > > > #cloud-config > > ssh_pwauth: true > > disable_root: 0 > > output: > > all: '>> /var/log/cloud-init-output.log' > > user: root > > password: admin123 > > chpasswd: > > expire: false > > runcmd: > > - 'sed -i ''/^datasource_list: /d'' /etc/cloud/cloud.cfg; echo > > ''datasource_list: > > ["NoCloud", "ConfigDrive"]'' >> /etc/cloud/cloud.cfg' > > > > > > but if i try with the > > > > <files> > > <file> > > <name>ignored</name> > > <content><![CDATA[runcmd: > > - echo 'Test script !' > /iwashere_test.txt > > ]]></content> > > <type>plaintext</type> > > </file> > > </files> > > > > then it will create the /iwashere_test.txt and write the contents and in > > that time the cat /mnt/openstack/latest/user_data is > > > > 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: admin123 > > chpasswd: > > expire: false > > runcmd: > > - 'sed -i ''/^datasource_list: /d'' /etc/cloud/cloud.cfg; echo > > ''datasource_list: > > ["NoCloud", "ConfigDrive"]'' >> /etc/cloud/cloud.cfg' > > runcmd: > > - echo 'Test script !' > /iwashere_test.txt > > > > so, i think the custom script section is not working, i am attaching the > > vm log as a screenshot. > > > > Can you share the XML document that you sent to the RESTAPI in order to > populate the "phone_home" section? > > > On Wed, Sep 10, 2014 at 2:07 PM, Juan Hernandez <jhernand(a)redhat.com > > <mailto:jhernand@redhat.com>> wrote: > > > > On 09/10/2014 06:44 AM, Shanil S wrote: > > > Hi Juan, > > > > > > What i am planning to do is to make work the following script > > > > > > #cloud-config > > > > > > # phone_home: if this dictionary is present, then the phone_home > > > # cloud-config module will post specified data back to the given > > > # url > > > # default: none > > > # phone_home: > > > # url: http://my.foo.bar/$INSTANCE/ > > > # post: all > > > # tries: 10 > > > # > > > phone_home: > > > url: http://my.example.com/$INSTANCE_ID/ > > > post: [ pub_key_dsa, pub_key_rsa, pub_key_ecdsa, instance_id ] > > > > > > ( > http://cloudinit.readthedocs.org/en/latest/topics/examples.html#run-comma... > ) > > > > > > but it wasn't working when i tried, i hope to post the above > values to > > > the specific url and get the posted details. > > > > > > > I think it should work, but it depends completely on cloud-init > itself. > > I'd suggest you check the content of the generated cloud-init > > configuration file (as described in a previous mail). If it > contains the > > "phone_home" section then you can discard a problem with oVirt, and > > focus on clud-init. > > > > > > > > On Wed, Sep 10, 2014 at 10:02 AM, Shanil S < > xielesshanil(a)gmail.com <mailto:xielesshanil@gmail.com> > > > <mailto:xielesshanil@gmail.com <mailto:xielesshanil@gmail.com>>> > wrote: > > > > > > 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 <mailto:jhernand@redhat.com> > > > <mailto:jhernand@redhat.com <mailto:jhernand@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(a)redhat.com <mailto:jhernand@redhat.com> > > <mailto:jhernand@redhat.com <mailto:jhernand@redhat.com>> > > > > <mailto:jhernand@redhat.com <mailto:jhernand@redhat.com > > > > <mailto:jhernand@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. >

On 09/11/2014 12:51 PM, Shanil S wrote: > Hi Juan, > > Also, i tried the following custom script from the ovirt panel and its > working > > #cloud-config > write_files: > -content: | > # THIS IS MY TEXT FILE > Some Content for my file > path: /tmp/myfile > permissions: '0644' > > > but the same content script i tried from the ovir api call like > > <custom_script>#cloud-config > write_files: > -content: | > # THIS IS MY TEXT FILE > Some Content for my file > path: /tmp/myfile > permissions: '0644' </custom_script> > </initialization> > > But its not working, may be this is a bug in the ovirt api function call ? > Currently the "custom_script" element doesn't work in combination with "cloud-init". To make it work you will have to use the "files" element: <action> <vm> <initialization> <cloud_init> ... <files> <file> <name>this is ignored</name> <content><![CDATA[your script]]></content> <type>plaintext</type> </file> </files> </cloud_init> </initialization> </vm> </action> As I wrote before there is a bug related to this: https://bugzilla.redhat.com/1138564 If that bug is fixed (unlikely according to the last comments) then the "custom_script" element will start working, but for know I suggest you include your custom script in both places: <action> <vm> <initialization> <cloud_init> ... <files> <file> <name>this is ignored</name> <content><![CDATA[your script]]></content> <type>plaintext</type> </file> </files> </cloud_init> <custom_script><![CDATA[your script]]></custom_script> </initialization> </vm> </action> > > -- > Regards > Shanil > > On Thu, Sep 11, 2014 at 3:36 PM, Shanil S <xielesshanil(a)gmail.com > <mailto:xielesshanil@gmail.com>> wrote: > > Hi Juan, > > Okay sure.. > The following xml i used > > <action> > <vm> > <os> > <boot dev='cdrom'/> > </os> > <initialization> > <cloud_init> > <host> > <address>test2</address> > </host> > > <users> > <user> > <user_name>root</user_name> > <password>test</password> > </user> > </users> > <network_configuration> > <nics> > > <nic> > <interface>virtio</interface> > <name>eth0</name> > <boot_protocol>none</boot_protocol> > <on_boot>true</on_boot> > </nic> > </nics> > <dns> > <servers> > <host> > <address>x.x.x.x</address> > </host> > </servers> > </dns> > </network_configuration> > </cloud_init> > <custom_script> #cloud-config > > phone_home: > url: http://x.x.com/api/xx/api_receive.php > > </custom_script> > </initialization> > </vm> > </action> > > > > -- > Regards > Shanil > > On Thu, Sep 11, 2014 at 1:48 PM, Juan Hernandez <jhernand(a)redhat.com > <mailto:jhernand@redhat.com>> wrote: > > On 09/11/2014 06:54 AM, Shanil S wrote: > > Hi Juan, > > > > It seems the it doesn't contains the "phone_home " section in > the cat > > /mnt/openstack/latest/user_data > > > > the following is the output > > > > #cloud-config > > ssh_pwauth: true > > disable_root: 0 > > output: > > all: '>> /var/log/cloud-init-output.log' > > user: root > > password: admin123 > > chpasswd: > > expire: false > > runcmd: > > - 'sed -i ''/^datasource_list: /d'' /etc/cloud/cloud.cfg; echo > > ''datasource_list: > > ["NoCloud", "ConfigDrive"]'' >> /etc/cloud/cloud.cfg' > > > > > > but if i try with the > > > > <files> > > <file> > > <name>ignored</name> > > <content><![CDATA[runcmd: > > - echo 'Test script !' > /iwashere_test.txt > > ]]></content> > > <type>plaintext</type> > > </file> > > </files> > > > > then it will create the /iwashere_test.txt and write the > contents and in > > that time the cat /mnt/openstack/latest/user_data is > > > > 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: admin123 > > chpasswd: > > expire: false > > runcmd: > > - 'sed -i ''/^datasource_list: /d'' /etc/cloud/cloud.cfg; echo > > ''datasource_list: > > ["NoCloud", "ConfigDrive"]'' >> /etc/cloud/cloud.cfg' > > runcmd: > > - echo 'Test script !' > /iwashere_test.txt > > > > so, i think the custom script section is not working, i am > attaching the > > vm log as a screenshot. > > > > Can you share the XML document that you sent to the RESTAPI in > order to > populate the "phone_home" section? > > > On Wed, Sep 10, 2014 at 2:07 PM, Juan Hernandez < jhernand(a)redhat.com <mailto:jhernand@redhat.com> > > <mailto:jhernand@redhat.com <mailto:jhernand@redhat.com>>> wrote: > > > > On 09/10/2014 06:44 AM, Shanil S wrote: > > > Hi Juan, > > > > > > What i am planning to do is to make work the following > script > > > > > > #cloud-config > > > > > > # phone_home: if this dictionary is present, then the > phone_home > > > # cloud-config module will post specified data back to > the given > > > # url > > > # default: none > > > # phone_home: > > > # url: http://my.foo.bar/$INSTANCE/ > > > # post: all > > > # tries: 10 > > > # > > > phone_home: > > > url: http://my.example.com/$INSTANCE_ID/ > > > post: [ pub_key_dsa, pub_key_rsa, pub_key_ecdsa, > instance_id ] > > > > > > > ( http://cloudinit.readthedocs.org/en/latest/topics/examples.html#run-comma... ) > > > > > > but it wasn't working when i tried, i hope to post the > above values to > > > the specific url and get the posted details. > > > > > > > I think it should work, but it depends completely on > cloud-init itself. > > I'd suggest you check the content of the generated cloud-init > > configuration file (as described in a previous mail). If > it contains the > > "phone_home" section then you can discard a problem with > oVirt, and > > focus on clud-init. > > > > > > > > On Wed, Sep 10, 2014 at 10:02 AM, Shanil S > <xielesshanil(a)gmail.com <mailto:xielesshanil@gmail.com> > <mailto:xielesshanil@gmail.com <mailto:xielesshanil@gmail.com>> > > > <mailto:xielesshanil@gmail.com <mailto: xielesshanil(a)gmail.com&gt; > <mailto:xielesshanil@gmail.com > <mailto:xielesshanil@gmail.com>>>> wrote: > > > > > > 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 <mailto:jhernand@redhat.com> > <mailto:jhernand@redhat.com <mailto:jhernand@redhat.com>> > > > <mailto:jhernand@redhat.com > <mailto:jhernand@redhat.com> <mailto:jhernand@redhat.com > <mailto:jhernand@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(a)redhat.com <mailto:jhernand@redhat.com> > <mailto:jhernand@redhat.com <mailto:jhernand@redhat.com>> > > <mailto:jhernand@redhat.com <mailto:jhernand@redhat.com> > <mailto:jhernand@redhat.com <mailto:jhernand@redhat.com>>> > > > > <mailto:jhernand@redhat.com > <mailto:jhernand@redhat.com> <mailto:jhernand@redhat.com > <mailto:jhernand@redhat.com>> > > <mailto:jhernand@redhat.com <mailto:jhernand@redhat.com> > <mailto:jhernand@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.

On 09/12/2014 07:04 AM, Shanil S wrote: > Hi Juan, > > I tried the following > > <action> > <vm> > <initialization> > <cloud_init> > ... > <files> > <file> > <name>ignored</name> > <content><![CDATA[write_files: > -content: | > Some Content for my file > path: /tmp/myfile > permissions: '0644']]></content> > <type>plaintext</type> > </file> > </files> > </cloud_init> > <custom_script><![CDATA[ > write_files: > -content: | > Some Content for my file > path: /tmp/myfile > permissions: '0644']]</custom_script> > > > But in that time i go the following errors from the api > Request syntactically incorrect. See the link description below for the > correct usage:start a virtual machine in the system identified by the > given idPOST > Content-Typeapplication/xml|json > > > If i change the xml format like > > <action> > <vm> > <initialization> > <cloud_init> > ... > <files> > <file> > <name>ignored</name> > <content><![CDATA[write_files: > -content: | > Some Content for my file > path: /tmp/myfile > permissions: '0644']]></content> > <type>plaintext</type> > </file> > </files> > </cloud_init> > <custom_script> > write_files: > -content: | > Some Content for my file > path: /tmp/myfile > permissions: '0644'</custom_script> > > the cloud init part won't work even though we didn't get any errors from > the api. Could you please check it ? > The attached example script worked correctly for me. Be careful with the indentation of the "write_files" section, as it the format is YAML and it is sensitive to indentation. Also putting the file in /tmp may be bad idea, specially if you want it to persist after rebooting the machine. > > On Thu, Sep 11, 2014 at 6:16 PM, Juan Hernandez <jhernand(a)redhat.com > <mailto:jhernand@redhat.com>> wrote: > > On 09/11/2014 12:51 PM, Shanil S wrote: > > Hi Juan, > > > > Also, i tried the following custom script from the ovirt panel and its > > working > > > > #cloud-config > > write_files: > > -content: | > > # THIS IS MY TEXT FILE > > Some Content for my file > > path: /tmp/myfile > > permissions: '0644' > > > > > > but the same content script i tried from the ovir api call like > > > > <custom_script>#cloud-config > > write_files: > > -content: | > > # THIS IS MY TEXT FILE > > Some Content for my file > > path: /tmp/myfile > > permissions: '0644' </custom_script> > > </initialization> > > > > But its not working, may be this is a bug in the ovirt api function call ? > > > > Currently the "custom_script" element doesn't work in combination with > "cloud-init". To make it work you will have to use the "files" element: > > <action> > <vm> > <initialization> > <cloud_init> > ... > <files> > <file> > <name>this is ignored</name> > <content><![CDATA[your script]]></content> > <type>plaintext</type> > </file> > </files> > </cloud_init> > </initialization> > </vm> > </action> > > As I wrote before there is a bug related to this: > > https://bugzilla.redhat.com/1138564 > > If that bug is fixed (unlikely according to the last comments) then the > "custom_script" element will start working, but for know I suggest you > include your custom script in both places: > > <action> > <vm> > <initialization> > <cloud_init> > ... > <files> > <file> > <name>this is ignored</name> > <content><![CDATA[your script]]></content> > <type>plaintext</type> > </file> > </files> > </cloud_init> > <custom_script><![CDATA[your script]]></custom_script> > </initialization> > </vm> > </action> > > > > > -- > > Regards > > Shanil > > > > On Thu, Sep 11, 2014 at 3:36 PM, Shanil S <xielesshanil(a)gmail.com <mailto:xielesshanil@gmail.com> > > <mailto:xielesshanil@gmail.com <mailto:xielesshanil@gmail.com>>> wrote: > > > > Hi Juan, > > > > Okay sure.. > > The following xml i used > > > > <action> > > <vm> > > <os> > > <boot dev='cdrom'/> > > </os> > > <initialization> > > <cloud_init> > > <host> > > <address>test2</address> > > </host> > > > > <users> > > <user> > > <user_name>root</user_name> > > <password>test</password> > > </user> > > </users> > > <network_configuration> > > <nics> > > > > <nic> > > <interface>virtio</interface> > > <name>eth0</name> > > <boot_protocol>none</boot_protocol> > > <on_boot>true</on_boot> > > </nic> > > </nics> > > <dns> > > <servers> > > <host> > > <address>x.x.x.x</address> > > </host> > > </servers> > > </dns> > > </network_configuration> > > </cloud_init> > > <custom_script> #cloud-config > > > > phone_home: > > url: http://x.x.com/api/xx/api_receive.php > > > > </custom_script> > > </initialization> > > </vm> > > </action> > > > > > > > > -- > > Regards > > Shanil > > > > On Thu, Sep 11, 2014 at 1:48 PM, Juan Hernandez > <jhernand(a)redhat.com <mailto:jhernand@redhat.com> > > <mailto:jhernand@redhat.com <mailto:jhernand@redhat.com>>> wrote: > > > > On 09/11/2014 06:54 AM, Shanil S wrote: > > > Hi Juan, > > > > > > It seems the it doesn't contains the "phone_home " > section in > > the cat > > > /mnt/openstack/latest/user_data > > > > > > the following is the output > > > > > > #cloud-config > > > ssh_pwauth: true > > > disable_root: 0 > > > output: > > > all: '>> /var/log/cloud-init-output.log' > > > user: root > > > password: admin123 > > > chpasswd: > > > expire: false > > > runcmd: > > > - 'sed -i ''/^datasource_list: /d'' > /etc/cloud/cloud.cfg; echo > > > ''datasource_list: > > > ["NoCloud", "ConfigDrive"]'' >> /etc/cloud/cloud.cfg' > > > > > > > > > but if i try with the > > > > > > <files> > > > <file> > > > <name>ignored</name> > > > <content><![CDATA[runcmd: > > > - echo 'Test script !' > /iwashere_test.txt > > > ]]></content> > > > <type>plaintext</type> > > > </file> > > > </files> > > > > > > then it will create the /iwashere_test.txt and write the > > contents and in > > > that time the cat /mnt/openstack/latest/user_data is > > > > > > 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: admin123 > > > chpasswd: > > > expire: false > > > runcmd: > > > - 'sed -i ''/^datasource_list: /d'' > /etc/cloud/cloud.cfg; echo > > > ''datasource_list: > > > ["NoCloud", "ConfigDrive"]'' >> /etc/cloud/cloud.cfg' > > > runcmd: > > > - echo 'Test script !' > /iwashere_test.txt > > > > > > so, i think the custom script section is not working, i am > > attaching the > > > vm log as a screenshot. > > > > > > > Can you share the XML document that you sent to the RESTAPI in > > order to > > populate the "phone_home" section? > > > > > On Wed, Sep 10, 2014 at 2:07 PM, Juan Hernandez > <jhernand(a)redhat.com <mailto:jhernand@redhat.com> > <mailto:jhernand@redhat.com <mailto:jhernand@redhat.com>> > > > <mailto:jhernand@redhat.com <mailto:jhernand@redhat.com> > <mailto:jhernand@redhat.com <mailto:jhernand@redhat.com>>>> wrote: > > > > > > On 09/10/2014 06:44 AM, Shanil S wrote: > > > > Hi Juan, > > > > > > > > What i am planning to do is to make work the following > > script > > > > > > > > #cloud-config > > > > > > > > # phone_home: if this dictionary is present, then the > > phone_home > > > > # cloud-config module will post specified data back to > > the given > > > > # url > > > > # default: none > > > > # phone_home: > > > > # url: http://my.foo.bar/$INSTANCE/ > > > > # post: all > > > > # tries: 10 > > > > # > > > > phone_home: > > > > url: http://my.example.com/$INSTANCE_ID/ > > > > post: [ pub_key_dsa, pub_key_rsa, pub_key_ecdsa, > > instance_id ] > > > > > > > > > > > ( http://cloudinit.readthedocs.org/en/latest/topics/examples.html#run-comma... ) > > > > > > > > but it wasn't working when i tried, i hope to post the > > above values to > > > > the specific url and get the posted details. > > > > > > > > > > I think it should work, but it depends completely on > > cloud-init itself. > > > I'd suggest you check the content of the generated > cloud-init > > > configuration file (as described in a previous mail). If > > it contains the > > > "phone_home" section then you can discard a problem with > > oVirt, and > > > focus on clud-init. > > > > > > > > > > > On Wed, Sep 10, 2014 at 10:02 AM, Shanil S > > <xielesshanil(a)gmail.com <mailto:xielesshanil@gmail.com> > <mailto:xielesshanil@gmail.com <mailto:xielesshanil@gmail.com>> > > <mailto:xielesshanil@gmail.com > <mailto:xielesshanil@gmail.com> <mailto:xielesshanil@gmail.com > <mailto:xielesshanil@gmail.com>>> > > > > <mailto:xielesshanil@gmail.com > <mailto:xielesshanil@gmail.com> <mailto:xielesshanil@gmail.com > <mailto:xielesshanil@gmail.com>> > > <mailto:xielesshanil@gmail.com <mailto: xielesshanil(a)gmail.com&gt; > > <mailto:xielesshanil@gmail.com > <mailto:xielesshanil@gmail.com>>>>> wrote: > > > > > > > > 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 <mailto:jhernand@redhat.com> > <mailto:jhernand@redhat.com <mailto:jhernand@redhat.com>> > > <mailto:jhernand@redhat.com <mailto:jhernand@redhat.com> > <mailto:jhernand@redhat.com <mailto:jhernand@redhat.com>>> > > > > <mailto:jhernand@redhat.com > <mailto:jhernand@redhat.com> > > <mailto:jhernand@redhat.com <mailto:jhernand@redhat.com>> > <mailto:jhernand@redhat.com <mailto:jhernand@redhat.com> > > <mailto:jhernand@redhat.com > <mailto:jhernand@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(a)redhat.com <mailto:jhernand@redhat.com> > <mailto:jhernand@redhat.com <mailto:jhernand@redhat.com>> > > <mailto:jhernand@redhat.com <mailto:jhernand@redhat.com> > <mailto:jhernand@redhat.com <mailto:jhernand@redhat.com>>> > > > <mailto:jhernand@redhat.com > <mailto:jhernand@redhat.com> <mailto:jhernand@redhat.com > <mailto:jhernand@redhat.com>> > > <mailto:jhernand@redhat.com <mailto:jhernand@redhat.com> > <mailto:jhernand@redhat.com <mailto:jhernand@redhat.com>>>> > > > > > <mailto:jhernand@redhat.com > <mailto:jhernand@redhat.com> > > <mailto:jhernand@redhat.com <mailto:jhernand@redhat.com>> > <mailto:jhernand@redhat.com <mailto:jhernand@redhat.com> > > <mailto:jhernand@redhat.com <mailto:jhernand@redhat.com>>> > > > <mailto:jhernand@redhat.com > <mailto:jhernand@redhat.com> <mailto:jhernand@redhat.com > <mailto:jhernand@redhat.com>> > > <mailto:jhernand@redhat.com <mailto:jhernand@redhat.com> > <mailto:jhernand@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.