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.



-- 
Regards
Shanil

On Wed, Sep 10, 2014 at 2:07 PM, Juan Hernandez <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>> 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>> 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>>> 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.