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

Wed Sep 10 00:44:40 EDT 2014

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 <xielesshanil at 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 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/03fafb30/attachment-0001.html>