Passing custom script to cloud init using api
From the ovirt admin panel, there is an option to give the custom script in
Hi All, the cloud init ( Run Once-> cloud init- > Custom script ). Is there any ways to pass the custom script to cloud init using the rest api ? -- Regards Shanil
On 09/02/2014 05:46 AM, Shanil S wrote:
Hi All,
From the ovirt admin panel, there is an option to give the custom script in the cloud init ( Run Once-> cloud init- > Custom script ). Is there any ways to pass the custom script to cloud init using the rest api ?
The custom script should go inside the "custom_script" element inside the "initialization" element: <action> ... <initialization> <cloud_init>...</cloud_init> <custom_script>your custom script</custom_script> </initialization> </action> -- 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.
Hi Juan, Thanks for the solution. -- Regards Shanil On Tue, Sep 2, 2014 at 2:59 PM, Juan Hernandez <jhernand@redhat.com> wrote:
On 09/02/2014 05:46 AM, Shanil S wrote:
Hi All,
From the ovirt admin panel, there is an option to give the custom script in the cloud init ( Run Once-> cloud init- > Custom script ). Is there any ways to pass the custom script to cloud init using the rest api ?
The custom script should go inside the "custom_script" element inside the "initialization" element:
<action> ... <initialization> <cloud_init>...</cloud_init> <custom_script>your custom script</custom_script> </initialization> </action>
-- 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.
Hi Juan, Is there anyways to specify the custom script from a file in the xml ? ie, i have a script in a file called script.sh and i would like to include this script in the xml with the api call. Is there any methods for this ? -- Regards Shanil On Tue, Sep 2, 2014 at 3:02 PM, Shanil S <xielesshanil@gmail.com> wrote:
Hi Juan,
Thanks for the solution.
-- Regards Shanil
On Tue, Sep 2, 2014 at 2:59 PM, Juan Hernandez <jhernand@redhat.com> wrote:
On 09/02/2014 05:46 AM, Shanil S wrote:
Hi All,
From the ovirt admin panel, there is an option to give the custom script in the cloud init ( Run Once-> cloud init- > Custom script ). Is there any ways to pass the custom script to cloud init using the rest api ?
The custom script should go inside the "custom_script" element inside the "initialization" element:
<action> ... <initialization> <cloud_init>...</cloud_init> <custom_script>your custom script</custom_script> </initialization> </action>
-- 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.
On 09/04/2014 06:29 AM, Shanil S wrote:
Hi Juan,
Is there anyways to specify the custom script from a file in the xml ? ie, i have a script in a file called script.sh and i would like to include this script in the xml with the api call. Is there any methods for this ?
You can deploy files using cloud-init, and the run them using the custom script. Something like this: <action> ... <initialization> <cloud-init> <files> <file name="/root/myscript.sh"/> <content><![CDATA[#!/bin/sh the content of your script]]></content> </file> </files> </cloud-init> <custom_script><![CDATA[runcmd: - sh /root/myscript.sh ]]></custom_script> </initialization> </action> But I'm not a cloud-init expert, and I didn't test this, so I don't really know if the custom_script will run before or after the files are deployed. It makes more sense to run the scripts after deploying the files, but you will have to test it yourself. The content of the files and the scripts has to be embedded in the XML document that you send to the RESTAPI server, there is no way to send an XML document and a separate file. Building this kind of XML document shouldn't be complicated if you use the CDATA syntax like in the example above. Another thing that you may consider, if you have to run a complicated script or set of scripts, is to have them pre-installed in the template that you use to create the VM, then you just need to run them.
-- Regards Shanil
On Tue, Sep 2, 2014 at 3:02 PM, Shanil S <xielesshanil@gmail.com <mailto:xielesshanil@gmail.com>> wrote:
Hi Juan,
Thanks for the solution.
-- Regards Shanil
On Tue, Sep 2, 2014 at 2:59 PM, Juan Hernandez <jhernand@redhat.com <mailto:jhernand@redhat.com>> wrote:
On 09/02/2014 05:46 AM, Shanil S wrote: > Hi All, > > From the ovirt admin panel, there is an option to give the custom script > in the cloud init ( Run Once-> cloud init- > Custom script ). Is there > any ways to pass the custom script to cloud init using the rest api ? >
The custom script should go inside the "custom_script" element inside the "initialization" element:
<action> ... <initialization> <cloud_init>...</cloud_init> <custom_script>your custom script</custom_script> </initialization> </action>
-- 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.
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
-- 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.
Hi Juan, Okay.. Thanks for your update. Also i found some sample cloud init scripts from here https://github.com/number5/cloud-init/tree/master/doc/examples and i tried the following scripts - type: foo/wark filename: bar content: | This is my payload hello - this is also payload - | multi line payload here - type: text/upstart-job filename: my-upstart.conf content: | Test file contents And run the start vm using the above script using cloud init and api, Could you please tell me where i can find the result of the above script ? I think the above script will create a file like my-upstart.conf -- Regards Shanil On Thu, Sep 4, 2014 at 1:56 PM, Juan Hernandez <jhernand@redhat.com> wrote:
On 09/04/2014 06:29 AM, Shanil S wrote:
Hi Juan,
Is there anyways to specify the custom script from a file in the xml ? ie, i have a script in a file called script.sh and i would like to include this script in the xml with the api call. Is there any methods for this ?
You can deploy files using cloud-init, and the run them using the custom script. Something like this:
<action> ... <initialization> <cloud-init> <files> <file name="/root/myscript.sh"/> <content><![CDATA[#!/bin/sh the content of your script]]></content> </file> </files> </cloud-init> <custom_script><![CDATA[runcmd: - sh /root/myscript.sh ]]></custom_script> </initialization> </action>
But I'm not a cloud-init expert, and I didn't test this, so I don't really know if the custom_script will run before or after the files are deployed. It makes more sense to run the scripts after deploying the files, but you will have to test it yourself.
The content of the files and the scripts has to be embedded in the XML document that you send to the RESTAPI server, there is no way to send an XML document and a separate file. Building this kind of XML document shouldn't be complicated if you use the CDATA syntax like in the example above.
Another thing that you may consider, if you have to run a complicated script or set of scripts, is to have them pre-installed in the template that you use to create the VM, then you just need to run them.
-- Regards Shanil
On Tue, Sep 2, 2014 at 3:02 PM, Shanil S <xielesshanil@gmail.com <mailto:xielesshanil@gmail.com>> wrote:
Hi Juan,
Thanks for the solution.
-- Regards Shanil
On Tue, Sep 2, 2014 at 2:59 PM, Juan Hernandez <jhernand@redhat.com <mailto:jhernand@redhat.com>> wrote:
On 09/02/2014 05:46 AM, Shanil S wrote: > Hi All, > > From the ovirt admin panel, there is an option to give the custom script > in the cloud init ( Run Once-> cloud init- > Custom script ). Is there > any ways to pass the custom script to cloud init using the rest api ? >
The custom script should go inside the "custom_script" element inside the "initialization" element:
<action> ... <initialization> <cloud_init>...</cloud_init> <custom_script>your custom script</custom_script> </initialization> </action>
-- 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.
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
-- 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.
On 09/04/2014 10:58 AM, Shanil S wrote:
Hi Juan,
Okay.. Thanks for your update. Also i found some sample cloud init scripts from here https://github.com/number5/cloud-init/tree/master/doc/examples and i tried the following scripts
- type: foo/wark filename: bar content: | This is my payload hello - this is also payload - | multi line payload here - type: text/upstart-job filename: my-upstart.conf content: | Test file contents
And run the start vm using the above script using cloud init and api, Could you please tell me where i can find the result of the above script ? I think the above script will create a file like my-upstart.conf
As I said I am not a cloud-init expert, so I don't really know what is the meaning or effect of this script. But I think that you need to use the "runcmd" option. For example: <action> ... <initialization> <cloud-init>...</cloud-init> <custom-script><![CDATA[runcmd: - touch /iwashere ]]></custom-script> </initialization> </action> If you use this it should run the "touch /iwashere" command, and you can check that it did verifying that the "/iwashere" file exists. As I said I didn't test this, so I may not work. I'd appreciate if you can test it, and once it works update the wiki with the correct instructions: http://www.ovirt.org/REST-Api#How_can_I_run_a_custom_script_using_cloud-init...
On Thu, Sep 4, 2014 at 1:56 PM, Juan Hernandez <jhernand@redhat.com <mailto:jhernand@redhat.com>> wrote:
On 09/04/2014 06:29 AM, Shanil S wrote: > Hi Juan, > > Is there anyways to specify the custom script from a file in the xml ? > ie, i have a script in a file called script.sh and i would like to > include this script in the xml with the api call. Is there any methods > for this ? >
You can deploy files using cloud-init, and the run them using the custom script. Something like this:
<action> ... <initialization> <cloud-init> <files> <file name="/root/myscript.sh"/> <content><![CDATA[#!/bin/sh the content of your script]]></content> </file> </files> </cloud-init> <custom_script><![CDATA[runcmd: - sh /root/myscript.sh ]]></custom_script> </initialization> </action>
But I'm not a cloud-init expert, and I didn't test this, so I don't really know if the custom_script will run before or after the files are deployed. It makes more sense to run the scripts after deploying the files, but you will have to test it yourself.
The content of the files and the scripts has to be embedded in the XML document that you send to the RESTAPI server, there is no way to send an XML document and a separate file. Building this kind of XML document shouldn't be complicated if you use the CDATA syntax like in the example above.
Another thing that you may consider, if you have to run a complicated script or set of scripts, is to have them pre-installed in the template that you use to create the VM, then you just need to run them.
> -- > Regards > Shanil > > > On Tue, Sep 2, 2014 at 3:02 PM, Shanil S <xielesshanil@gmail.com <mailto:xielesshanil@gmail.com> > <mailto:xielesshanil@gmail.com <mailto:xielesshanil@gmail.com>>> wrote: > > Hi Juan, > > Thanks for the solution. > > -- > Regards > Shanil > > > On Tue, Sep 2, 2014 at 2:59 PM, Juan Hernandez <jhernand@redhat.com <mailto:jhernand@redhat.com> > <mailto:jhernand@redhat.com <mailto:jhernand@redhat.com>>> wrote: > > On 09/02/2014 05:46 AM, Shanil S wrote: > > Hi All, > > > > From the ovirt admin panel, there is an option to give the > custom script > > in the cloud init ( Run Once-> cloud init- > Custom script ). > Is there > > any ways to pass the custom script to cloud init using the > rest api ? > > > > The custom script should go inside the "custom_script" element > inside > the "initialization" element: > > <action> > ... > <initialization> > <cloud_init>...</cloud_init> > <custom_script>your custom script</custom_script> > </initialization> > </action> >
-- 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.
Hi Juan, I tried with the above touch command but it seems the 'iwashere' file isn't created after executing it the above command. -- Regards Shanil On Thu, Sep 4, 2014 at 3:02 PM, Juan Hernandez <jhernand@redhat.com> wrote:
On 09/04/2014 10:58 AM, Shanil S wrote:
Hi Juan,
Okay.. Thanks for your update. Also i found some sample cloud init scripts from here https://github.com/number5/cloud-init/tree/master/doc/examples and i tried the following scripts
- type: foo/wark filename: bar content: | This is my payload hello - this is also payload - | multi line payload here - type: text/upstart-job filename: my-upstart.conf content: | Test file contents
And run the start vm using the above script using cloud init and api, Could you please tell me where i can find the result of the above script ? I think the above script will create a file like my-upstart.conf
As I said I am not a cloud-init expert, so I don't really know what is the meaning or effect of this script. But I think that you need to use the "runcmd" option. For example:
<action> ... <initialization> <cloud-init>...</cloud-init> <custom-script><![CDATA[runcmd: - touch /iwashere ]]></custom-script> </initialization> </action>
If you use this it should run the "touch /iwashere" command, and you can check that it did verifying that the "/iwashere" file exists.
As I said I didn't test this, so I may not work. I'd appreciate if you can test it, and once it works update the wiki with the correct instructions:
http://www.ovirt.org/REST-Api#How_can_I_run_a_custom_script_using_cloud-init...
On Thu, Sep 4, 2014 at 1:56 PM, Juan Hernandez <jhernand@redhat.com <mailto:jhernand@redhat.com>> wrote:
On 09/04/2014 06:29 AM, Shanil S wrote: > Hi Juan, > > Is there anyways to specify the custom script from a file in the
xml ?
> ie, i have a script in a file called script.sh and i would like to > include this script in the xml with the api call. Is there any
methods
> for this ? >
You can deploy files using cloud-init, and the run them using the
custom
script. Something like this:
<action> ... <initialization> <cloud-init> <files> <file name="/root/myscript.sh"/> <content><![CDATA[#!/bin/sh the content of your script]]></content> </file> </files> </cloud-init> <custom_script><![CDATA[runcmd: - sh /root/myscript.sh ]]></custom_script> </initialization> </action>
But I'm not a cloud-init expert, and I didn't test this, so I don't really know if the custom_script will run before or after the files
are
deployed. It makes more sense to run the scripts after deploying the files, but you will have to test it yourself.
The content of the files and the scripts has to be embedded in the
XML
document that you send to the RESTAPI server, there is no way to
send an
XML document and a separate file. Building this kind of XML document shouldn't be complicated if you use the CDATA syntax like in the
example
above.
Another thing that you may consider, if you have to run a complicated script or set of scripts, is to have them pre-installed in the
template
that you use to create the VM, then you just need to run them.
> -- > Regards > Shanil > > > On Tue, Sep 2, 2014 at 3:02 PM, Shanil S <xielesshanil@gmail.com <mailto:xielesshanil@gmail.com> > <mailto:xielesshanil@gmail.com <mailto:xielesshanil@gmail.com>>> wrote: > > Hi Juan, > > Thanks for the solution. > > -- > Regards > Shanil > > > On Tue, Sep 2, 2014 at 2:59 PM, Juan Hernandez <jhernand@redhat.com <mailto:jhernand@redhat.com> > <mailto:jhernand@redhat.com <mailto:jhernand@redhat.com>>>
wrote:
> > On 09/02/2014 05:46 AM, Shanil S wrote: > > Hi All, > > > > From the ovirt admin panel, there is an option to give
the
> custom script > > in the cloud init ( Run Once-> cloud init- > Custom script ). > Is there > > any ways to pass the custom script to cloud init using
the
> rest api ? > > > > The custom script should go inside the "custom_script"
element
> inside > the "initialization" element: > > <action> > ... > <initialization> > <cloud_init>...</cloud_init> > <custom_script>your custom script</custom_script> > </initialization> > </action> >
-- 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.
On 09/04/2014 11:59 AM, Shanil S wrote:
Hi Juan,
I tried with the above touch command but it seems the 'iwashere' file isn't created after executing it the above command.
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 However, you can exploit this bug to do what you want. This is an example: #!/bin/sh -ex url="https://ovirt.example.com/ovirt-engine/api" user="admin@internal" password="******" curl \ --insecure \ --request POST \ --header "Accept: application/xml" \ --header "Content-Type: application/xml" \ --user "${user}:${password}" \ --data ' <action> <vm> <initialization> <cloud_init> <host> <address>myhost.mydomain.com</address> </host> <users> <user> <user_name>root</user_name> <password>mypassword</password> </user> </users> <network_configuration> <nics> <nic> <name>eth0</name> <boot_protocol>static</boot_protocol> <network> <ip address="192.168.122.31" netmask="255.255.255" gateway="192.168.122.1"/> </network> <on_boot>true</on_boot> </nic> </nics> <dns> <servers> <host> <address>192.168.122.1</address> </host> </servers> <search_domains> <host> <address>mydomain.com</address> </host> </search_domains> </dns> </network_configuration> <files> <file> <name>ignored</name> <content><![CDATA[runcmd: - echo "I was here!" > /iwashere.txt ]]></content> <type>plaintext</type> </file> </files> </cloud_init> <custom_script><![CDATA[runcmd: - echo "I was here!" > /iwashere.txt ]]></custom_script> </initialization> </vm> </action> ' \ "${url}/vms/480225cf-0cbd-4166-b9ca-3857b124618a/start" Note that in this example I am including the custom script both in the first "file" element inside "cloud_init" and in the "custom_script" element, this way it will work with the current version of the engine and also if/when we eventually fix the bug. Please remember to update the wiki with your feedback: http://www.ovirt.org/REST-Api#How_can_I_run_a_custom_script_using_cloud-init...
On Thu, Sep 4, 2014 at 3:02 PM, Juan Hernandez <jhernand@redhat.com <mailto:jhernand@redhat.com>> wrote:
On 09/04/2014 10:58 AM, Shanil S wrote: > Hi Juan, > > Okay.. Thanks for your update. Also i found some sample cloud init > scripts from here > https://github.com/number5/cloud-init/tree/master/doc/examples and i > tried the following scripts > > - type: foo/wark > filename: bar > content: | > This is my payload > hello > - this is also payload > - | > multi line payload > here > - > type: text/upstart-job > filename: my-upstart.conf > content: | > Test file contents > > And run the start vm using the above script using cloud init and api, > Could you please tell me where i can find the result of the above script ? > I think the above script will create a file like my-upstart.conf >
As I said I am not a cloud-init expert, so I don't really know what is the meaning or effect of this script. But I think that you need to use the "runcmd" option. For example:
<action> ... <initialization> <cloud-init>...</cloud-init> <custom-script><![CDATA[runcmd: - touch /iwashere ]]></custom-script> </initialization> </action>
If you use this it should run the "touch /iwashere" command, and you can check that it did verifying that the "/iwashere" file exists.
As I said I didn't test this, so I may not work. I'd appreciate if you can test it, and once it works update the wiki with the correct instructions:
http://www.ovirt.org/REST-Api#How_can_I_run_a_custom_script_using_cloud-init...
> > On Thu, Sep 4, 2014 at 1:56 PM, Juan Hernandez <jhernand@redhat.com <mailto:jhernand@redhat.com> > <mailto:jhernand@redhat.com <mailto:jhernand@redhat.com>>> wrote: > > On 09/04/2014 06:29 AM, Shanil S wrote: > > Hi Juan, > > > > Is there anyways to specify the custom script from a file in the xml ? > > ie, i have a script in a file called script.sh and i would like to > > include this script in the xml with the api call. Is there any methods > > for this ? > > > > You can deploy files using cloud-init, and the run them using the custom > script. Something like this: > > <action> > ... > <initialization> > <cloud-init> > <files> > <file name="/root/myscript.sh"/> > <content><![CDATA[#!/bin/sh the content of your > script]]></content> > </file> > </files> > </cloud-init> > <custom_script><![CDATA[runcmd: > - sh /root/myscript.sh > ]]></custom_script> > </initialization> > </action> > > But I'm not a cloud-init expert, and I didn't test this, so I don't > really know if the custom_script will run before or after the files are > deployed. It makes more sense to run the scripts after deploying the > files, but you will have to test it yourself. > > The content of the files and the scripts has to be embedded in the XML > document that you send to the RESTAPI server, there is no way to send an > XML document and a separate file. Building this kind of XML document > shouldn't be complicated if you use the CDATA syntax like in the example > above. > > Another thing that you may consider, if you have to run a complicated > script or set of scripts, is to have them pre-installed in the template > that you use to create the VM, then you just need to run them. > > > -- > > Regards > > Shanil > > > > > > On Tue, Sep 2, 2014 at 3:02 PM, 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, > > > > Thanks for the solution. > > > > -- > > Regards > > Shanil > > > > > > On Tue, Sep 2, 2014 at 2:59 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/02/2014 05:46 AM, Shanil S wrote: > > > Hi All, > > > > > > From the ovirt admin panel, there is an option to give the > > custom script > > > in the cloud init ( Run Once-> cloud init- > Custom > script ). > > Is there > > > any ways to pass the custom script to cloud init using the > > rest api ? > > > > > > > The custom script should go inside the "custom_script" element > > inside > > the "initialization" element: > > > > <action> > > ... > > <initialization> > > <cloud_init>...</cloud_init> > > <custom_script>your custom script</custom_script> > > </initialization> > > </action> > >
-- 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.
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:
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.
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? -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
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:
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.
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. -- Regards Shanil On Fri, Sep 5, 2014 at 3:00 PM, Juan Hernandez <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:
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. _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
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.
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.
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. -- 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.
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.
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.
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>> 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> > <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>>> 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>>>> 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.
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> 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>> 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> > <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>>> 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>>>> 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.
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 ? -- Regards Shanil On Thu, Sep 11, 2014 at 3:36 PM, Shanil S <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> 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>> 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> > <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>>> 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>>>> 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.
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...) > > > > 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.
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... )
> > > > 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.
On 09/12/2014 07:04 AM, Shanil S wrote:
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 ?
The attached example script worked correctly for me. Be careful with the indentation of the "write_files" section, as it the format is YAML and it is sensitive to indentation. Also putting the file in /tmp may be bad idea, specially if you want it to persist after rebooting the machine.
On Thu, Sep 11, 2014 at 6:16 PM, Juan Hernandez <jhernand@redhat.com <mailto: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> > <mailto: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> > <mailto: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>> > > <mailto: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...) > > > > > > 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>>> > > > <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 <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>>> > > > <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 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>>>> > > > > <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 <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.
Hi Juan, Yes, the above script is working fine. -- Regards Shanil On Tue, Sep 16, 2014 at 7:49 PM, Juan Hernandez <jhernand@redhat.com> wrote:
On 09/12/2014 07:04 AM, Shanil S wrote:
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 ?
The attached example script worked correctly for me. Be careful with the indentation of the "write_files" section, as it the format is YAML and it is sensitive to indentation.
Also putting the file in /tmp may be bad idea, specially if you want it to persist after rebooting the machine.
On Thu, Sep 11, 2014 at 6:16 PM, Juan Hernandez <jhernand@redhat.com <mailto: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>
> <mailto: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> > <mailto: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>> > > <mailto: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... )
> > > > > > 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>>> > > > <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 <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>>> > > > <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 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>>>> > > > > <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 <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.
participants (3)
-
Juan Hernandez -
Shanil S -
Sven Kieske