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

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. >