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-commands-on-first-boot ) but it wasn't working when i tried, i hope to post the above values to the specific url and get the posted details. -- Regards Shanil On Wed, Sep 10, 2014 at 10:02 AM, Shanil S <[email protected]> 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 <[email protected]> > 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 <[email protected] >> > <mailto:[email protected]>> 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. >> > >
_______________________________________________ Users mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/users
