The fix looks simple enough. Amit - can you backport it please?
----- Original Message ----- > From: "Juan Hernández" <jhern...@redhat.com> > To: "Christopher Pereira" <krip...@imatronix.cl>, devel@ovirt.org, "Allon > Mureinik" <amure...@redhat.com>, > aavi...@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@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@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@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@ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel > > > _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel