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