[ovirt-users] Passing custom script to cloud init using api
Shanil S
xielesshanil at gmail.com
Thu Sep 11 10:51:10 UTC 2014
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 ?
--
Regards
Shanil
On Thu, Sep 11, 2014 at 3:36 PM, Shanil S <xielesshanil at 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 at 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 at redhat.com
>> > <mailto:jhernand at 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-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.
>> > >
>> >
>> > 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 at gmail.com <mailto:xielesshanil at gmail.com>
>> > > <mailto:xielesshanil at gmail.com <mailto: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 <mailto:jhernand at redhat.com>
>> > > <mailto:jhernand at redhat.com <mailto: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>
>> > <mailto:jhernand at redhat.com <mailto:jhernand at redhat.com>>
>> > > > <mailto:jhernand at redhat.com <mailto:jhernand at redhat.com
>> >
>> > <mailto: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/20140911/431f098e/attachment-0001.html>
More information about the Users
mailing list