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

Shanil S xielesshanil at gmail.com
Thu Sep 11 06:06:08 EDT 2014


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/53f57bc0/attachment-0001.html>


More information about the Users mailing list