[ovirt-devel] REST api and template creation
Allon Mureinik
amureini at redhat.com
Wed May 13 16:08:13 UTC 2015
The fix looks simple enough.
Amit - can you backport it please?
----- Original Message -----
> From: "Juan Hernández" <jhernand at redhat.com>
> To: "Christopher Pereira" <kripper at imatronix.cl>, devel at ovirt.org, "Allon Mureinik" <amureini at redhat.com>,
> aaviram at redhat.com
> Sent: Monday, May 11, 2015 12:48:49 PM
> Subject: Re: [ovirt-devel] REST api and template creation
>
> 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.
> _______________________________________________
> Devel mailing list
> Devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
>
>
More information about the Devel
mailing list