Bug 1269534

In general the RESTAPI doesn't need to behave like the the GUI.

In this particular case the decision to use or not cloud-init (or sysprep) is made by the user, not by the system. In the GUI you have a check box, in the RESTAPI you need to explicitly use the "use_cloud_init" or "use_sysprep" elements:

  POST /vms/{vm:id}/start
  <action>
    <use_cloud_init>true|false</use_cloud_init>
  </action>

In the absence of this parameter cloud-init (or sysprep) isn't triggered at all.

Is this a new behaviour? because in my test I do not pass this parameter and automation was successful until recently (September).
If it is a new tag then I would say close this bug, if not then it's quite strange I hadn't experienced this sooner.

The "user_cloud_init" element was introduced in order to fix bug 1190663.

Tried to add the use_cloud_init tag to the action body message:

<action>
    <async>false</async>
    <grace_period>
        <expiry>10</expiry>
    </grace_period>
    <use_cloud_init>true</use_cloud_init>
</action>

response is 200 so no syntax problem.
VM still fails to initialize with cloud-init.
Is the fix in bz - 1190663 for 3.5 as well?
Let me know if this should be re-named as cloud-init bug instead of REST bug.

Yes, the fix should be included included in 3.5.5, see bug 1240900. I'm trying to reproduce it, don't change anything yet.

I have tested this again with 3.5.5 and it works correctly, at least it triggers the creation of the cloud-init ISO image, which is then attached to the VM. Can you verify that? Start the VM using the "use_cloud_init" element, as you did, and then go to the hypervisor and check if the "qemu-kvm" process is running:

  # ps -ef | grep qemu-kvm | grep the_name_of_the_vm

That process, if it exists, should have an option like this:

  --drive file=/var/run/vdsm/payload/....img

That .img file is the ISO image generated by VDSM. You can mount and inspect its content:

   # cp /var/run/vdsm/payload/....img /tmp/cloud-init.img
   # mount -o loop,ro cloud-init.img /mnt
   # find /mnt
   # cat /mnt/openstack/latest/user_data

If the image is generated correctly, and the content is also correct, then there may be an issue with cloud-init itself.

The issue is with creation of cloud-init image via API on 3.5.5.
When created via API the image doesn't include the input of cloud init parameters (in my case username and password), whereas using webadmin the image does include the extra parameters.
This doesn't re produce on 3.6.

BTW,
As a workaround one can use run-once to run the cloud-init by adding <vm/> tag to the action, ie:
<action>
    <use_cloud_init>true</use_cloud_init>
    <vm/>
</action>

adding z-stream keyworkd to make bot happy

Verify with:
Engine:rhevm-3.5.6.1-0.1.el6ev
Hosts:
OS: RHEL - 7.2 - 9.el7
Kernal: 3.10.0 - 327.el7.x86_64
KVM: 2.3.0 - 31.el7
VDSM:vdsm-4.16.28-1.el7ev
libvirt: libvirt-1.2.17-13.el7
rhel-guest-image:rhel-guest-image-7.2-20151102.0.x86_64

Scenario:
1. Upload rhel-guest-image to rhevm and import it as template.
2. Create vm from the template.
3. Edit vm and set cloud-init initialization with some username and password.
4. Start vm: Via GUI and REST API
5. Connect to VM via spice: check the user/pass as configure in clould-init
REST request:
 POST /vms/{vm:id}/start
  <action>
    <use_cloud_init>true|false</use_cloud_init>
  </action>

Results:
GUI: Pass
REST API: PASS

Do I understand correctly that even when passing <use_cloud_init>true</use_cloud_init> to the start command, this will not work on RHEVM 3.5.5?  When I try to test this on RHEVM 3.5.5, the generated payload does not contain any of the initialization data that I set.

Can you help with: https://bugzilla.redhat.com/show_bug.cgi?id=1269534#c14

(In reply to Brandon Dunne from comment #16)
> Can you help with: https://bugzilla.redhat.com/show_bug.cgi?id=1269534#c14

sorry, only 3.5.6 has the complete fix

Shahar,

My process is:
1. Create VM via REST API
2. Update Initialization via REST API
3. Start VM via REST API (for the first time) with <use_cloud_init>true</use_cloud_init>

Result:
Initialization information is not included in the payload attached to the VM.

This leads me to believe that it is not that same issue as mentioned in Comment 20 above, since that sounds like the VM has been booted once, then initialization information set, then booted a second time.  My VM is only booted once.

(In reply to Brandon Dunne from comment #22)
The bug that Israel open was regarding running vm with run once didn't include the username and password in cloud-init.
We close the bug because its description was not clear.
Israel will open a new bug regarding that and I will send it to you.

This bug is related that the <use_cloud_init> tag was not working at all.

Shahar,

I see that starting the VM with <use_cloud_init> is working since a payload is generated and attached, however the payload does not contain any of the initialization data.  Also, I am not using "run once" mode when starting the machine.

(In reply to Brandon Dunne from comment #24)
I know this is the issue that I talked about.
We are opening a bug regarding that,
Israel will post you the bug #

I know this is the issue that I talked about.
We are opening a bug regarding that,
Israel will post you the bug #

Brandon,
is bz 1287122 the same as you reported?

Shahar,

No, 1287122 is not the same issue.  I set the initialization data on the vm, then boot the VM (not Run Once) with <use_cloud_init> and none of the initialization data appears in the payload.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-2531.html

(In reply to Brandon Dunne from comment #28)
> Shahar,
> 
> No, 1287122 is not the same issue.  I set the initialization data on the vm,
> then boot the VM (not Run Once) with <use_cloud_init> and none of the
> initialization data appears in the payload.
if its not the first run of the VM you have to use run-once

I am starting the VM for the first time, but not using "Run Once" mode, just "Run" with <use_cloud_init>.  Is there something more that I can do to debug why the payload doesn't contain the initialization data?

I think that you put the use_cloud_init inside the vm and not inside the action.

this should work:

<action>
    <use_cloud_init>true</use_cloud_init>
  <vm>
    <initialization>

    </initialization>
  </vm>
</action>

I originally tested with <use_cloud_init> inside <vm> and saw that the payload does not get generated at all.

So, I put the <use_cloud_init> in the <action> and see that a payload is generated but does not contain the initialization data that I already have set on the VM.

Israel,

Are you able to reproduce this problem?

Retesting with the released RHEVM 3.5.6 packages was successful.  Clearing my NEEDINFOs