[ovirt-devel] REST api and template creation

[Adolfo]

Hello all,

My name is Adolfo, i'm in charge of developing of UDS (you can see 
something about it on ovirt home page, the case study 
http://www.ovirt.org/Universidad_de_Sevilla_Case_Study. ).

Recently (a couple of days ago), i started to test UDS against ovirt 
3.5, and sudenlty Template creation as was supported previously does not 
works. :(

The idea is allow to create the template in the storage that the 
administrator of UDS selects.

The process is simple and was working perfectly before to 3.5 release 
(on 3.4, 3.3, 3.2 as long as i can remember). After getting all the data 
we need, we do the following (code follows):

vm is the origin vm:

             # Create disks description to be created in specified 
storage domain, one for each disk
             sd = 
params.StorageDomains(storage_domain=[params.StorageDomain(id=storageId)])

             dsks = []
             for dsk in vm.disks.list():
                 dks.append(params.Disk(id=dsk.get_id(), 
storage_domains=sd, name='test', alias='test'))

             disks = params.Disks(disk=dsks)

             template = params.Template(
                 name=name,
                 vm=params.VM(id=vm.get_id(), disks=disks),
                 cluster=params.Cluster(id=cluster.get_id()),
                 description=comments
             )

             return api.templates.add(template).get_id()

This is the debug output of the request:

POST /api/templates HTTP/1.1
Host: ovirt.dkmon.com
Accept-Encoding: identity
Content-Length: 2656
Filter: False
cookie: JSESSIONID=2Ihu3uUWFhvl2xbsi5i7yBip.undefined
Prefer: persistent-auth
Content-type: application/xml
Accept: application/xml

<template>
     <name>UDSP_ovirt-21</name>
     <description>UDS pub for ovirt at 2015-05-09 08:27:06</description>
     <vm id="3774dcd0-9e1a-47af-9560-fde85f46bfa1">
         <disks>
             <disk 
href="/api/vms/3774dcd0-9e1a-47af-9560-fde85f46bfa1/disks/f96b3718-3ccf-42f4-8537-e20dc5dd7bc3" 
id="f96b3718-3ccf-42f4-8537-e20dc5dd7bc3">
                 <actions>
                     <link 
href="/api/vms/3774dcd0-9e1a-47af-9560-fde85f46bfa1/disks/f96b3718-3ccf-42f4-8537-e20dc5dd7bc3/deactivate" 
rel="deactivate"/>
                     <link 
href="/api/vms/3774dcd0-9e1a-47af-9560-fde85f46bfa1/disks/f96b3718-3ccf-42f4-8537-e20dc5dd7bc3/activate" 
rel="activate"/>
                     <link 
href="/api/vms/3774dcd0-9e1a-47af-9560-fde85f46bfa1/disks/f96b3718-3ccf-42f4-8537-e20dc5dd7bc3/export" 
rel="export"/>
                     <link 
href="/api/vms/3774dcd0-9e1a-47af-9560-fde85f46bfa1/disks/f96b3718-3ccf-42f4-8537-e20dc5dd7bc3/move" 
rel="move"/>
                 </actions>
                 <name>no-os_Dsk1</name>
                 <description>Small empty disk</description>
                 <link 
href="/api/vms/3774dcd0-9e1a-47af-9560-fde85f46bfa1/disks/f96b3718-3ccf-42f4-8537-e20dc5dd7bc3/permissions" 
rel="permissions"/>
                 <link 
href="/api/vms/3774dcd0-9e1a-47af-9560-fde85f46bfa1/disks/f96b3718-3ccf-42f4-8537-e20dc5dd7bc3/statistics" 
rel="statistics"/>
                 <vm 
href="/api/vms/3774dcd0-9e1a-47af-9560-fde85f46bfa1" 
id="3774dcd0-9e1a-47af-9560-fde85f46bfa1"/>
                 <alias>no-os_Dsk1</alias>
<image_id>a79f7fe7-bcae-4cc3-8b11-d60702a46147</image_id>
                 <storage_domains>
                     <storage_domain 
id="a893809b-2ba9-4910-a7f3-9bfdde2efbb8"/>
                 </storage_domains>
                 <size>1073741824</size>
<provisioned_size>1073741824</provisioned_size>
                 <actual_size>0</actual_size>
                 <status>
                     <state>ok</state>
                 </status>
                 <interface>virtio</interface>
                 <format>raw</format>
                 <sparse>true</sparse>
                 <bootable>true</bootable>
                 <shareable>false</shareable>
<wipe_after_delete>false</wipe_after_delete>
<propagate_errors>false</propagate_errors>
                 <active>true</active>
                 <read_only>false</read_only>
                 <disk_profile 
href="/api/diskprofiles/40def02e-3802-4122-a768-cb6b9518896e" 
id="40def02e-3802-4122-a768-cb6b9518896e"/>
             </disk>
         </disks>
     </vm>
     <cluster id="00000001-0001-0001-0001-00000000019d"/>
</template>

reply: 'HTTP/1.1 400 Bad Request\r\n'
header: Date: Sat, 09 May 2015 06:27:13 GMT
header: Server: Apache/2.4.6 (CentOS) OpenSSL/1.0.1e-fips
header: JSESSIONID: 2Ihu3uUWFhvl2xbsi5i7yBip.undefined
header: Content-Type: application/xml
header: Content-Length: 180
header: Connection: close

The response : Cannot add Template with an empty disk alias

On server, i got this on ovirt log:

2015-05-09 08:14:16,940 WARN 
[org.ovirt.engine.core.bll.AddVmTemplateCommand] (ajp--127.0.0.1-8702-8) 
CanDoAction of action AddVmTemplate failed for user admin at internal. 
Reasons: 
VAR__ACTION__ADD,VAR__TYPE__VM_TEMPLATE,ACTION_TYPE_FAILED_TEMPLATE_CANNOT_BE_CREATED_WITH_EMPTY_DISK_ALIAS

After a lot of tests, i have no idea how to resolve this, and if this is 
related to the change that was made to admin interface that alias is 
required when creating a template (googling have found something related 
to that change). The case is that even sending an "alias" (the alias is 
unique anyway, but is hardcoded in the example because of tests... :) )

I don't know where to ask for help on this, if this is my own fault of 
is something that was missing on ovirt engine. We need to be able to 
create machines templates on whatever storage is decided... :(

Thank you very much

Adolfo Gómez