Hi Juan,

I tried the following

<action>
  <vm>
    <initialization>
      <cloud_init>
        ...
       <files>
          <file>
            <name>ignored</name>
            <content><![CDATA[write_files:
    -content: |
        Some Content for my file
    path: /tmp/myfile
    permissions: '0644']]></content>
            <type>plaintext</type>
          </file>
        </files>
      </cloud_init>
  <custom_script><![CDATA[
write_files:
    -content: |
        Some Content for my file
    path: /tmp/myfile
    permissions: '0644']]</custom_script>

   
But in that time i go the following errors from the api
Request syntactically incorrect. See the link description below for the correct usage:start a virtual machine in the system identified by the given idPOST
Content-Typeapplication/xml|json


If i change the xml format like

<action>
  <vm>
    <initialization>
      <cloud_init>
        ...
       <files>
          <file>
            <name>ignored</name>
            <content><![CDATA[write_files:
    -content: |
        Some Content for my file
    path: /tmp/myfile
    permissions: '0644']]></content>
            <type>plaintext</type>
          </file>
        </files>
      </cloud_init>
  <custom_script>
write_files:
    -content: |
        Some Content for my file
    path: /tmp/myfile
    permissions: '0644'</custom_script>

the cloud init part won't work even though we didn't get any errors from the api. Could you please check it ?



-- 
Regards
Shanil

On Thu, Sep 11, 2014 at 6:16 PM, Juan Hernandez <jhernand@redhat.com> wrote:
On 09/11/2014 12:51 PM, Shanil S wrote:
> 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 ?
>

Currently the "custom_script" element doesn't work in combination with
"cloud-init". To make it work you will have to use the "files" element:

<action>
  <vm>
    <initialization>
      <cloud_init>
        ...
        <files>
          <file>
            <name>this is ignored</name>
            <content><![CDATA[your script]]></content>
            <type>plaintext</type>
          </file>
        </files>
      </cloud_init>
    </initialization>
  </vm>
</action>

As I wrote before there is a bug related to this:

https://bugzilla.redhat.com/1138564

If that bug is fixed (unlikely according to the last comments) then the
"custom_script" element will start working, but for know I suggest you
include your custom script in both places:

<action>
  <vm>
    <initialization>
      <cloud_init>
        ...
        <files>
          <file>
            <name>this is ignored</name>
            <content><![CDATA[your script]]></content>
            <type>plaintext</type>
          </file>
        </files>
      </cloud_init>
      <custom_script><![CDATA[your script]]></custom_script>
    </initialization>
  </vm>
</action>

>
> --
> Regards
> Shanil
>
> On Thu, Sep 11, 2014 at 3:36 PM, Shanil S <xielesshanil@gmail.com
> <mailto:xielesshanil@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@redhat.com
>     <mailto:jhernand@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@redhat.com <mailto:jhernand@redhat.com>
>         > <mailto:jhernand@redhat.com <mailto:jhernand@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@gmail.com <mailto:xielesshanil@gmail.com>
>         <mailto:xielesshanil@gmail.com <mailto:xielesshanil@gmail.com>>
>         >     > <mailto:xielesshanil@gmail.com <mailto:xielesshanil@gmail.com>
>         <mailto:xielesshanil@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@redhat.com <mailto:jhernand@redhat.com>
>         <mailto:jhernand@redhat.com <mailto:jhernand@redhat.com>>
>         >     >     <mailto:jhernand@redhat.com
>         <mailto:jhernand@redhat.com> <mailto:jhernand@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@redhat.com <mailto:jhernand@redhat.com>
>         <mailto:jhernand@redhat.com <mailto:jhernand@redhat.com>>
>         >     <mailto:jhernand@redhat.com <mailto:jhernand@redhat.com>
>         <mailto:jhernand@redhat.com <mailto:jhernand@redhat.com>>>
>         >     >         > <mailto:jhernand@redhat.com
>         <mailto:jhernand@redhat.com> <mailto:jhernand@redhat.com
>         <mailto:jhernand@redhat.com>>
>         >     <mailto:jhernand@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.
>         >     >         >
>         >     >
>         >
>

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