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