[ovirt-devel] REST api and template creation

Juan Hernández jhernand at redhat.com
Mon May 11 09:48:49 UTC 2015


On 05/09/2015 09:08 AM, Christopher Pereira wrote:
> Template creation is failing, because Engine is not receiving the alias
> which apparently is required since 3.5.
> This is the XML sent to engine. Alias is there.
> API bug?
> 

Yes, this is a bug in the API. It is fixed already in 3.6:

  SDK and REST ignore template's disk attributes
  https://bugzilla.redhat.com/1110798

It didn't happen before 3.5 because the backend didn't check the content
of the alias. That changed in 3.5 as part of the fix for a different bug:

  Create template from vm with empty disk alias should block with
canDoAction
  https://bugzilla.redhat.com/1110304

As far as I know there is no workaround, so you will have to wait for a
release containing the fix. Currently it is targeted for 3.6, but we
could retarget for 3.5.

Allon, Amit, can we retarget bug 1110798 to the next 3.5.z?

> <template>
>     <name>UDSP_ovirt-22</name>
>     <description>UDS pub for ovirt at 2015-05-09 08:36:58</description>
>     <vm id="3774dcd0-9e1a-47af-9560-fde85f46bfa1">
>         <disks>
>             <disk id="f96b3718-3ccf-42f4-8537-e20dc5dd7bc3">
>                 <name>test</name>
> *                <alias>test</alias> *
>                 <storage_domains>
>                     <storage_domain
> id="07326302-2c80-4d55-a7a2-ea79c55855e3"/>
>                 </storage_domains>
>             </disk>
>         </disks>
>     </vm>
>     <cluster id="00000001-0001-0001-0001-00000000019d"/>
> </template>
> 
> On 09-05-2015 3:34, Adolfo wrote:
>> 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
>>
>> _______________________________________________
>> Devel mailing list
>> Devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
> 
> 
> -- 
> 
> *J. Christopher Pereira*
> Gerente General
> IMATRONIX S.A.
> www.imatronix.com
> 
> Móvil : (09) 72 188 630
> 
> Santiago: (+56) (02) 28 99 44 60 + anexo 800
> Valparaíso: (+56) (32) 2 76 80 77 + anexo 800
> 
> 
> 
> _______________________________________________
> Devel mailing list
> Devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
> 


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



More information about the Devel mailing list