- Devel - oVirt List Archives

UI Plugin to Upload ISO Files
by Tony James 04 Jan '15

04 Jan '15

This message is in response to an earlier thread regarding a UI plugin to upload ISO files. Like the original poster, Lucas, I began work on a UI plugin to allow uploading ISO files through a UI plugin. After reading the previous thread I'm re-thinking the architecture. It was suggested that the recommended approach to upload files to a storage domain is through the VDSM API [1]. I'm pretty familiar with the oVirt REST API but have been unable to find documentation regarding accessing the VDSM API. Should the VDSM API be accessible by a UI plugin? If so, is there documentation available to do so? [1] http://lists.ovirt.org/pipermail/devel/2014-December/009497.html -Tony

4 8

SubnodeConfiguration, HierarchicalConfiguration and Checkstyle
by Yedidyah Bar David 01 Jan '15

01 Jan '15

Hi all, I started looking at building the engine using xmvn [1], see also [2] [3] if interested. The core of this project is to stop bundling modules we get from maven during build, and instead use ones packaged by the distribution (fedora or rhel for now). This will require, among other things, to adapt our existing code that uses such modules, to their versions as packaged by the distro. On first attempt I failed, due to currently using commons-configuration 1.6 where fedora 20 (where I do this) ships 1.9. If I change the pom to use 1.9, the build fails on the line: List<SubnodeConfiguration> configurationsAt = config.configurationsAt("/*/" + ALTERNATE_KEY); in backend/manager/tools/src/main/java/org/ovirt/engine/core/config/EngineConfigLogic.java, saying they are of incompatible types. I tried a bit changing stuff there, and current status is that Checkstyle fails, with my current draft patch [4]. I'd appreciate some experienced Java developer to give this a look and advice on how to proceed. Thanks! I guess the other option is to Conflict (in the spec file) with the package shipped in fedora, and either bundle 1.6 as we do now or package it on the ovirt repo. I'd rather not go that route for now. [1] https://mizdebsk.fedorapeople.org/xmvn/site/ [2] http://fedoraproject.org/wiki/Packaging:Java [3] https://fedorahosted.org/released/javapackages/doc/ [4] http://gerrit.ovirt.org/36528 -- Didi

1 0

Bump to 3.6 default cluster version
by Lior Vernia 01 Jan '15

01 Jan '15

Hello, Could we add the 3.6 version on master and change that to the default DC/cluster version? Some features are already merged, so they could be used and bugs could be found earlier by people working on master (mostly us developers I guess) once the version is bumped. I saw 6199b29506253eeae9712afea71a3641727de71b for 3.5 - however, I'm not sure I understand the logic behind what config values need to be added for old features to work, so I'd prefer not to be the one sending the patch. Yours, Lior.

2 2

Vdsm 4.16.10 build - oVirt-3.5
by ybronhei 29 Dec '14

29 Dec '14

Hey, Enjoy the new updates of vdsm 4.16.10. epel7 - http://koji.fedoraproject.org/koji/taskinfo?taskID=8479594 f20 - http://koji.fedoraproject.org/koji/taskinfo?taskID=8495492 f21 - http://koji.fedoraproject.org/koji/taskinfo?taskID=8494079 f22 - http://koji.fedoraproject.org/koji/taskinfo?taskID=8494059 for el6 I still have few problems to set it up (https://kojipkgs.fedoraproject.org//work/tasks/5530/8495530/mock_output.log) I'll update about it Please give karama if works properly Regards, -- Yaniv Bronhaim.

1 0

ovirt ssd local cache
by yxu 25 Dec '14

25 Dec '14

This is a multipart message in MIME format. ------=_NextPart_000_0001_01D02070.75A22150 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Everyone ! Recently I am reading some documents about vmeare virtual flash <http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=di splayKC&externalId=2058983> and citrix IntelliCache <http://support.citrix.com/article/CTX129052> . I am wondering if we can add some feature like that into ovirt . Then I found something like bcache and flash cache. After changing some code , I tried bcache in an old version of ovirt node . It works for just one node . But when I add another node to the data center, the problem occurred . When I write some data into node A, the data will be stored in node A's cache and iscsi server. But the cache of node B does not know the change . the data in node B's cache still the old one. In vmware's solution and citrix's solution , it seemed they have some way to solve this problem . Do you have any idea ? Thanks ------=_NextPart_000_0001_01D02070.75A22150 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" = xmlns:o=3D"urn:schemas-microsoft-com:office:office" = xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" = xmlns=3D"http://www.w3.org/TR/REC-html40"><head><META = HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Dus-ascii"><meta name=3DGenerator content=3D"Microsoft Word 15 = (filtered medium)"><style></style></head><body lang=3DZH-CN = link=3D"#0563C1" vlink=3D"#954F72" = style=3D'text-justify-trim:punctuation'><div class=3DWordSection1>Hi Everyone = !<o:p></o:p>     Recently  I am reading some = documents about <a = href=3D"http://kb.vmware.com/selfservice/microsites/search.do?language=3D= en_US&cmd=3DdisplayKC&externalId=3D2058983">vmeare virtual = flash</a> and <a = href=3D"http://support.citrix.com/article/CTX129052">citrix = IntelliCache</a> . I am wondering if we can add some feature like that = into ovirt .<o:p></o:p><o:p> </o:p>Then I found something = like bcache and flash cache. <o:p></o:p><o:p> </o:p>After changing some code = , I tried bcache in an old version of ovirt node . It works for just one = node . <o:p></o:p><o:p> </o:p>But when I add another = node to the data center, the problem occurred . <o:p></o:p><o:p> </o:p>When I write some data = into node A, the data will be stored in node A’s cache and iscsi = server.<o:p></o:p><o:p> </o:p>But the cache of node B = does not know the change . the data in node B’s cache still the = old one.<o:p></o:p><o:p> </o:p>In vmware’s = solution and citrix’s solution , it seemed they have some way to = solve this problem .<o:p></o:p><o:p> </o:p>Do you have any idea = ?<o:p></o:p><o:p> </o:p>Thanks = <o:p></o:p><o:p> </o:p><o:p> </o:p></div></body></html> ------=_NextPart_000_0001_01D02070.75A22150--

1 0

Help with patch reviews!
by Sahina Bose 24 Dec '14

24 Dec '14

Hi all, Could any of you help with these patch reviews - these are related to the gluster geo-replication management feature [1] http://gerrit.ovirt.org/#/c/34552/ http://gerrit.ovirt.org/#/c/34630/ http://gerrit.ovirt.org/#/c/34216 http://gerrit.ovirt.org/#/c/33845/ thanks sahina [1] - http://www.ovirt.org/Features/Gluster_Geo_Replication

2 1

Failed to Initiate Removal of Template
by Tang Jackson 24 Dec '14

24 Dec '14

--_000_HK2PR03MB08201EA7FCCECDBF94D27A309C540HK2PR03MB0820apcp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have a template which I no longer need but I cannot remove it. The templ= ate is not attached to any VMs and is still fully functional, I can create = new VMs with this template. The logs during removal: 2014-12-24 11:44:19,002 INFO [org.ovirt.engine.core.bll.RemoveVmTemplateCo= mmand] (ajp--127.0.0.1-8702-4) [704a05dd] Lock Acquired to object EngineLoc= k [exclusiveLocks=3D key: b0968117-4932-47af-a4da-c3c5c9b2b2bd value: TEMPL= ATE , sharedLocks=3D ] 2014-12-24 11:44:19,095 INFO [org.ovirt.engine.core.bll.RemoveVmTemplateCo= mmand] (org.ovirt.thread.pool-8-thread-47) [704a05dd] Running command: Remo= veVmTemplateCommand internal: false. Entities affected : ID: b0968117-4932= -47af-a4da-c3c5c9b2b2bd Type: VmTemplateAction group DELETE_TEMPLATE with r= ole type USER 2014-12-24 11:44:19,150 INFO [org.ovirt.engine.core.bll.RemoveAllVmTemplat= eImageTemplatesCommand] (org.ovirt.thread.pool-8-thread-47) [704a05dd] Runn= ing command: RemoveAllVmTemplateImageTemplatesCommand internal: true. Entit= ies affected : ID: b0968117-4932-47af-a4da-c3c5c9b2b2bd Type: VmTemplate 2014-12-24 11:44:19,224 INFO [org.ovirt.engine.core.bll.RemoveTemplateSnap= shotCommand] (org.ovirt.thread.pool-8-thread-47) [296e0a] Running command: = RemoveTemplateSnapshotCommand internal: true. Entities affected : ID: 7396= 8e04-9176-439c-a9e8-fa5313d15f8e Type: Storage 2014-12-24 11:44:19,291 INFO [org.ovirt.engine.core.vdsbroker.irsbroker.De= leteImageGroupVDSCommand] (org.ovirt.thread.pool-8-thread-47) [296e0a] STAR= T, DeleteImageGroupVDSCommand( storagePoolId =3D bd7c67a2-5008-41a0-808a-b9= f58f2742d7, ignoreFailoverLimit =3D false, storageDomainId =3D 73968e04-917= 6-439c-a9e8-fa5313d15f8e, imageGroupId =3D d584d61c-5759-4e13-a9a4-f1a75068= edd6, postZeros =3D false, forceDelete =3D false), log id: 1768709a 2014-12-24 11:44:19,324 ERROR [org.ovirt.engine.core.vdsbroker.irsbroker.De= leteImageGroupVDSCommand] (org.ovirt.thread.pool-8-thread-47) [296e0a] Comm= and DeleteImageGroupVDSCommand( storagePoolId =3D bd7c67a2-5008-41a0-808a-b= 9f58f2742d7, ignoreFailoverLimit =3D false, storageDomainId =3D 73968e04-91= 76-439c-a9e8-fa5313d15f8e, imageGroupId =3D d584d61c-5759-4e13-a9a4-f1a7506= 8edd6, postZeros =3D false, forceDelete =3D false) execution failed. Except= ion: IrsOperationFailedNoFailoverException: IRSGenericException: IRSErrorEx= ception: Shared Volume cannot be deleted: (u"Cannot delete shared image d58= 4d61c-5759-4e13-a9a4-f1a75068edd6. volImgs: {u'b24d30ea-8774-4dfa-adcf-e30b= 0ef73592': ImgsPar(imgs=3D(u'd584d61c-5759-4e13-a9a4-f1a75068edd6', u'dd10f= fd2-edb2-4923-bd34-a6a12a76beaf'), parent=3D'00000000-0000-0000-0000-000000= 000000')}",) 2014-12-24 11:44:19,457 INFO [org.ovirt.engine.core.vdsbroker.irsbroker.De= leteImageGroupVDSCommand] (org.ovirt.thread.pool-8-thread-47) [296e0a] FINI= SH, DeleteImageGroupVDSCommand, log id: 1768709a 2014-12-24 11:44:19,491 ERROR [org.ovirt.engine.core.bll.RemoveTemplateSnap= shotCommand] (org.ovirt.thread.pool-8-thread-47) [296e0a] Command org.ovirt= .engine.core.bll.RemoveTemplateSnapshotCommand throw Vdc Bll exception. Wit= h error message VdcBLLException: org.ovirt.engine.core.vdsbroker.irsbroker.= IrsOperationFailedNoFailoverException: IRSGenericException: IRSErrorExcepti= on: Shared Volume cannot be deleted: (u"Cannot delete shared image d584d61c= -5759-4e13-a9a4-f1a75068edd6. volImgs: {u'b24d30ea-8774-4dfa-adcf-e30b0ef73= 592': ImgsPar(imgs=3D(u'd584d61c-5759-4e13-a9a4-f1a75068edd6', u'dd10ffd2-e= db2-4923-bd34-a6a12a76beaf'), parent=3D'00000000-0000-0000-0000-00000000000= 0')}",) (Failed with error CannotDeleteSharedVolume and code 223) 2014-12-24 11:44:19,636 ERROR [org.ovirt.engine.core.bll.RemoveTemplateSnap= shotCommand] (org.ovirt.thread.pool-8-thread-47) [296e0a] Transaction rolle= d-back for command: org.ovirt.engine.core.bll.RemoveTemplateSnapshotCommand= . 2014-12-24 11:44:19,641 INFO [org.ovirt.engine.core.bll.tasks.AsyncTaskMan= ager] (org.ovirt.thread.pool-8-thread-47) [296e0a] Removed task e2d5b03c-00= 8d-4493-8601-51354f7cda7a from DataBase 2014-12-24 11:44:19,678 INFO [org.ovirt.engine.core.bll.RemoveAllVmTemplat= eImageTemplatesCommand] (org.ovirt.thread.pool-8-thread-47) [296e0a] Comman= d [id=3Df7b1b13c-2d21-4d2c-a4f6-7ab4f07c1fe3]: Compensating CHANGED_STATUS_= ONLY of org.ovirt.engine.core.common.businessentities.VmTemplate; snapshot:= EntityStatusSnapshot [id=3Db0968117-4932-47af-a4da-c3c5c9b2b2bd, status=3D= OK]. 2014-12-24 11:44:19,742 ERROR [org.ovirt.engine.core.bll.RemoveAllVmTemplat= eImageTemplatesCommand] (org.ovirt.thread.pool-8-thread-47) [296e0a] Transa= ction rolled-back for command: org.ovirt.engine.core.bll.RemoveAllVmTemplat= eImageTemplatesCommand. 2014-12-24 11:44:19,818 ERROR [org.ovirt.engine.core.dal.dbbroker.auditlogh= andling.AuditLogDirector] (org.ovirt.thread.pool-8-thread-47) [296e0a] Corr= elation ID: 704a05dd, Job ID: 7b890ce3-860e-41da-af7c-2951d82146d5, Call St= ack: null, Custom Event ID: -1, Message: Failed to initiate removal of Temp= late Vagrant_CentOS7_4 (User: admin). 2014-12-24 11:44:19,881 INFO [org.ovirt.engine.core.bll.RemoveVmTemplateCo= mmand] (org.ovirt.thread.pool-8-thread-47) [296e0a] Lock freed to object En= gineLock [exclusiveLocks=3D key: b0968117-4932-47af-a4da-c3c5c9b2b2bd value= : TEMPLATE , sharedLocks=3D ] Is there a way to force remove perhaps from the ovirt-shell? Jackson --_000_HK2PR03MB08201EA7FCCECDBF94D27A309C540HK2PR03MB0820apcp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"> <style></style> </head> <body lang=3D"JA" link=3D"blue" vlink=3D"purple" style=3D"text-justify-trim= :punctuation"> <div class=3D"WordSection1"> I ha= ve a template which I no longer need but I cannot remove it.  The temp= late is not attached to any VMs and is still fully functional, I can create= new VMs with this template.<o:p></o:p> <o:p= > </o:p> The = logs during removal:<o:p></o:p> <o:p= > </o:p> 2014= -12-24 11:44:19,002 INFO  [org.ovirt.engine.core.bll.RemoveVmTemplateC= ommand] (ajp--127.0.0.1-8702-4) [704a05dd] Lock Acquired to object EngineLo= ck [exclusiveLocks=3D key: b0968117-4932-47af-a4da-c3c5c9b2b2bd value: TEMPLATE<o:p></o:p> , sh= aredLocks=3D ]<o:p></o:p> 2014= -12-24 11:44:19,095 INFO  [org.ovirt.engine.core.bll.RemoveVmTemplateC= ommand] (org.ovirt.thread.pool-8-thread-47) [704a05dd] Running command: Rem= oveVmTemplateCommand internal: false. Entities affected :  ID: b0968117-4932-47af-a4da-c3c5c9b2b2bd Type: VmTemplate= Action group DELETE_TEMPLATE with role type USER<o:p></o:p> 2014= -12-24 11:44:19,150 INFO  [org.ovirt.engine.core.bll.RemoveAllVmTempla= teImageTemplatesCommand] (org.ovirt.thread.pool-8-thread-47) [704a05dd] Run= ning command: RemoveAllVmTemplateImageTemplatesCommand internal: true. Entities affected :  ID: b0968117-4932-47af-a4da-c3c5= c9b2b2bd Type: VmTemplate<o:p></o:p> 2014= -12-24 11:44:19,224 INFO  [org.ovirt.engine.core.bll.RemoveTemplateSna= pshotCommand] (org.ovirt.thread.pool-8-thread-47) [296e0a] Running command:= RemoveTemplateSnapshotCommand internal: true. Entities affected :  ID: 73968e04-9176-439c-a9e8-fa5313d15f8e Type: S= torage<o:p></o:p> 2014= -12-24 11:44:19,291 INFO  [org.ovirt.engine.core.vdsbroker.irsbroker.D= eleteImageGroupVDSCommand] (org.ovirt.thread.pool-8-thread-47) [296e0a] STA= RT, DeleteImageGroupVDSCommand( storagePoolId =3D bd7c67a2-5008-41a0-808a-b9f58f2742d7, ignoreFailoverLimit =3D false, s= torageDomainId =3D 73968e04-9176-439c-a9e8-fa5313d15f8e, imageGroupId =3D d= 584d61c-5759-4e13-a9a4-f1a75068edd6, postZeros =3D false, forceDelete =3D f= alse), log id: 1768709a<o:p></o:p> 2014= -12-24 11:44:19,324 ERROR [org.ovirt.engine.core.vdsbroker.irsbroker.Delete= ImageGroupVDSCommand] (org.ovirt.thread.pool-8-thread-47) [296e0a] Command = DeleteImageGroupVDSCommand( storagePoolId =3D bd7c67a2-5008-41a0-808a-b9f58f2742d7, ignoreFailoverLimit =3D false, s= torageDomainId =3D 73968e04-9176-439c-a9e8-fa5313d15f8e, imageGroupId =3D d= 584d61c-5759-4e13-a9a4-f1a75068edd6, postZeros =3D false, forceDelete =3D f= alse) execution failed. Exception: IrsOperationFailedNoFailoverException: IRSGenericException: IRSErrorException: Shared Volume cannot be deleted: (= u"Cannot delete shared image d584d61c-5759-4e13-a9a4-f1a75068edd6. vol= Imgs: {u'b24d30ea-8774-4dfa-adcf-e30b0ef73592': ImgsPar(imgs=3D(u'd584d61c-= 5759-4e13-a9a4-f1a75068edd6', u'dd10ffd2-edb2-4923-bd34-a6a12a76beaf'), parent=3D'00000000-0000-0000-0000-000000000000')}",)<o:p></o:p></span= > 2014= -12-24 11:44:19,457 INFO  [org.ovirt.engine.core.vdsbroker.irsbroker.D= eleteImageGroupVDSCommand] (org.ovirt.thread.pool-8-thread-47) [296e0a] FIN= ISH, DeleteImageGroupVDSCommand, log id: 1768709a<o:p></o:p> 2014= -12-24 11:44:19,491 ERROR [org.ovirt.engine.core.bll.RemoveTemplateSnapshot= Command] (org.ovirt.thread.pool-8-thread-47) [296e0a] Command org.ovirt.eng= ine.core.bll.RemoveTemplateSnapshotCommand throw Vdc Bll exception. With error message VdcBLLException: org.ovirt.eng= ine.core.vdsbroker.irsbroker.IrsOperationFailedNoFailoverException: IRSGene= ricException: IRSErrorException: Shared Volume cannot be deleted: (u"C= annot delete shared image d584d61c-5759-4e13-a9a4-f1a75068edd6. volImgs: {u'b24d30ea-8774-4dfa-adcf-e30b0ef73592': ImgsPar(imgs=3D(u'd584d= 61c-5759-4e13-a9a4-f1a75068edd6', u'dd10ffd2-edb2-4923-bd34-a6a12a76beaf'),= parent=3D'00000000-0000-0000-0000-000000000000')}",) (Failed with err= or CannotDeleteSharedVolume and code 223)<o:p></o:p> 2014= -12-24 11:44:19,636 ERROR [org.ovirt.engine.core.bll.RemoveTemplateSnapshot= Command] (org.ovirt.thread.pool-8-thread-47) [296e0a] Transaction rolled-ba= ck for command: org.ovirt.engine.core.bll.RemoveTemplateSnapshotCommand.<o:= p></o:p> 2014= -12-24 11:44:19,641 INFO  [org.ovirt.engine.core.bll.tasks.AsyncTaskMa= nager] (org.ovirt.thread.pool-8-thread-47) [296e0a] Removed task e2d5b03c-0= 08d-4493-8601-51354f7cda7a from DataBase<o:p></o:p> 2014= -12-24 11:44:19,678 INFO  [org.ovirt.engine.core.bll.RemoveAllVmTempla= teImageTemplatesCommand] (org.ovirt.thread.pool-8-thread-47) [296e0a] Comma= nd [id=3Df7b1b13c-2d21-4d2c-a4f6-7ab4f07c1fe3]: Compensating CHANGED_STATUS_ONLY of org.ovirt.engine.core.common.businesse= ntities.VmTemplate; snapshot: EntityStatusSnapshot [id=3Db0968117-4932-47af= -a4da-c3c5c9b2b2bd, status=3DOK].<o:p></o:p> 2014= -12-24 11:44:19,742 ERROR [org.ovirt.engine.core.bll.RemoveAllVmTemplateIma= geTemplatesCommand] (org.ovirt.thread.pool-8-thread-47) [296e0a] Transactio= n rolled-back for command: org.ovirt.engine.core.bll.RemoveAllVmTemplateIma= geTemplatesCommand.<o:p></o:p> 2014= -12-24 11:44:19,818 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandl= ing.AuditLogDirector] (org.ovirt.thread.pool-8-thread-47) [296e0a] Correlat= ion ID: 704a05dd, Job ID: 7b890ce3-860e-41da-af7c-2951d82146d5, Call Stack: null, Custom Event ID: -1, Message: Failed to initiate removal= of Template Vagrant_CentOS7_4 (User: admin).<o:p></o:p> 2014= -12-24 11:44:19,881 INFO  [org.ovirt.engine.core.bll.RemoveVmTemplateC= ommand] (org.ovirt.thread.pool-8-thread-47) [296e0a] Lock freed to object E= ngineLock [exclusiveLocks=3D key: b0968117-4932-47af-a4da-c3c5c9b2b2bd value: TEMPLATE<o:p></o:p> , sh= aredLocks=3D ]<o:p></o:p> <o:p= > </o:p> Is t= here a way to force remove perhaps from the ovirt-shell?<o:p></o:p><= /p> <o:p= > </o:p> Jack= son<o:p></o:p> </div> </body> </html> --_000_HK2PR03MB08201EA7FCCECDBF94D27A309C540HK2PR03MB0820apcp_--

1 0

Re: [ovirt-devel] Gluster Volume Snapshots - Feature review
by Shubhendu Tripathi 24 Dec '14

24 Dec '14

----_com.android.email_68837318013720 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 ClRoYW5rcyBKdWFuIGZvciB0aGUgY29tbWVudHMuIEkgd291bGQgdXBkYXRlIHRoZSB3aWtpIGFj Y29yZGluZ2x5IGFuZCBzZW5kIGZvciBjb25maXJtYXRpb24uCgpSZWdhcmRzClNodWJoZW5kdQoK U2VudCBmcm9tIFNhbXN1bmcgTW9iaWxlCgotLS0tLS0tLSBPcmlnaW5hbCBtZXNzYWdlIC0tLS0t LS0tCkZyb206IEp1YW4gSGVybsOhbmRleiA8amhlcm5hbmRAcmVkaGF0LmNvbT4gCkRhdGU6IDA5 LzEyLzIwMTQgIDE4OjUxICAoR01UKzA1OjMwKSAKVG86IFNodWJoZW5kdSBUcmlwYXRoaSA8c2h0 cmlwYXRAcmVkaGF0LmNvbT4sZGV2ZWxAb3ZpcnQub3JnLE1pY2hhZWwgUGFzdGVybmFrIDxtcGFz dGVybkByZWRoYXQuY29tPiAKU3ViamVjdDogUmU6IFtvdmlydC1kZXZlbF0gR2x1c3RlciBWb2x1 bWUgU25hcHNob3RzIC0gRmVhdHVyZSByZXZpZXcgCiAKT24gMTIvMDQvMjAxNCAwNzoxMSBQTSwg U2h1YmhlbmR1IFRyaXBhdGhpIHdyb3RlOgo+IEhpIEp1YW4vTWljaGFlbCwKPiAKPiBUaGlzIGlz IGEgZ2VudGxlIHJlbWluZGVyIGZvciB0aGUgcmV2aWV3IG9mIHRoZSBSRVNUIGFwaSBkZXNpZ24g Zm9yIHRoZSAKPiBiZWxvdyBmZWF0dXJlLgo+IFdlIHdvdWxkIGJlIHN0YXJ0aW5nIHRoZSBSRVNU IGRldmVsb3BtZW50IGZvciB0aGUgc2FtZSBzb29uIChwcm9iYWJseSBieSAKPiBEZWMgMjAxNCBl bmQpLgo+IAo+IElmIHRoZXJlIGFyZSBzcGVjaWZpYyBjb21tZW50cywgcGxlYXNlIHBhc3MgaXQg b24uIElmIG5vIGNvbW1lbnRzIHdlIAo+IHdvdWxkIGdvIGFoZWFkIHdpdGggdGhlIGN1cnJlbnQg ZGVzaWduIGFuZCBpbXBsZW1lbnQgYWNjb3JkaW5nbHkuCj4gCj4gUmVxdWVzdCB5b3VyIHRpbWUg Zm9yIHRoaXMuCj4gCj4gVGhhbmtzIGFuZCBSZWdhcmRzLAo+IFNodWJoZW5kdQo+IAo+IE9uIDEx LzEwLzIwMTQgMTI6MjIgUE0sIFNodWJoZW5kdSBUcmlwYXRoaSB3cm90ZToKPj4gSGkgQWxsLAo+ Pgo+PiBQbGVhc2UgaGVscCB1cyB0byByZXZpZXcgdGhlIGRlc2lnbiBvZiBHbHVzdGVyIFZvbHVt ZSBTbmFwc2hvdHMgaW4gb1ZpcnQsCj4+Cj4+IEhlcmUgYXJlIHR3byBkZXNpZ24gb24gd2lraSBw YWdlCj4+Cj4+IEdlbmVyYWwgRmVhdHVyZSBEZXNpZ24KPj4gaHR0cDovL3d3dy5vdmlydC5vcmcv RmVhdHVyZXMvR2x1c3RlclZvbHVtZVNuYXBzaG90cwo+Pgo+PiBEZXRhaWxlZCBEZXNpZ24KPj4g aHR0cDovL3d3dy5vdmlydC5vcmcvRmVhdHVyZXMvRGVzaWduL0dsdXN0ZXJWb2x1bWVTbmFwc2hv dHMKPj4KPj4gV2UgdGFyZ2V0IGl0IGluIG92aXJ0IDMuNiByZWxlYXNlLgo+Pgo+PiBNYXJrZWQg SnVhbi9NaWNoYWVsIHNwZWNpZmljYWxseSBmb3IgUkVTVCByZXZpZXcuCj4+Cj4+IEJlc3QgUmVn YXJkcywKPj4gU2h1YmhlbmR1IFRyaXBhdGhpCgpNeSBjb21tZW50cyBhYm91dCB0aGUgUkVTVEFQ SToKCjEuIFlvdSBjYW4ndCB1c2UgdGhlICJzbmFwc2hvdCIgYW5kICJzbmFwc2hvdHMiIFhNTCBl bGVtZW50cywgYXMgdGhvc2UKYXJlIGFscmVhZHkgaW4gdXNlIGZvciBkaXNrIHNuYXBzaG90cywg YW5kIHdlIGRvbid0IGhhdmUgbmFtZSBzcGFjZQpzdXBwb3J0IGluIHRoZSBSRVNUQVBJLiBZb3Ug d2lsbCBoYXZlIHRvIHVzZSBzb21ldGhpbmcgZGlmZmVyZW50LCBmb3IKZXhhbXBsZSAiZ2x1c3Rl cl92b2x1bWVfc25hcHNob3RzIiBhbmQgImdsdXN0ZXJfdm9sdW1lX3NuYXBzaG90Ii4KCjIuIFdo ZW4gYWRkaW5nIGEgdm9sdW1lIHNuYXBzaG90IHRoZSBuYW1lIG9mIHRoZSB2b2x1bWUgc2hvdWxk bid0IGJlIGEKcGFyYW1ldGVyLCBhcyB0aGF0IGlzIGltcGxpY2l0LiBPbmx5IHRoZSBuYW1lIGFu ZCBkZXNjcmlwdGlvbiBvZiB0aGUKc25hcHNob3Qgc2hvdWxkIGJlIHByb3ZpZGVkLgoKMy4gVGhl IG9wZXJhdGlvbiB0byBkZWxldGUgYSBzbmFwc2hvdCBzaG91bGQgYmUgcGVyZm9ybWVkIG9uIHRo ZQpzbmFwc2hvdCByZXNvdXJjZSwgbm90IG9uIHRoZSBjb2xsZWN0aW9uOgoKwqAgREVMRVRFCi9j bHVzdGVycy97Y2x1c3RlcjppZH0vZ2x1c3RlcnZvbHVtZXMve3ZvbHVtZTppZH0vc25hcHNob3Rz L3tzbmFwc2hvdDppZH0KCklkZWFsbHkgdGhpcyBvcGVyYXRpb24gc2hvdWxkbid0IHJlY2VpdmUg YW55IHBhcmFtZXRlcnMgKHRodXMgbm8gYm9keSkuCklmIGl0IGRvZXMgcmVxdWlyZSBwYXJhbWV0 ZXJzIHRoZW4gdGhleSBzaG91bGQgYmUgY29udGFpbmVkIGluc2lkZSBhbgoiYWN0aW9uIiBlbGVt ZW50LgoKNC4gVGhlIG9wZXJhdGlvbiB0byB1cGRhdGUgdGhlIHNuYXBzaG90IGNvbmZpZ3VyYXRp b24gc2hvdWxkIGJlIHRoZSBQVVQKb3BlcmF0aW9uIG9mIHRoZSB2b2x1bWUsIG5vdCBhIG5ldyAi c25hcHNob3Rjb25maWciIHN1Yi1yZXNvdXJjZSwgYXMKdGhlc2Uga2luZCBvZiBzdWItcmVzb3Vy Y2VzIGFyZW4ndCB3ZWxsIHN1cHBvcnRlZCBieSB0aGUgU0RLcyBhbmQgdGhlIENMSS4KCi0tIApE aXJlY2Npw7NuIENvbWVyY2lhbDogQy9Kb3NlIEJhcmRhc2FubyBCYW9zLCA5LCBFZGlmLiBHb3Ji ZWEgMywgcGxhbnRhCjPCukQsIDI4MDE2IE1hZHJpZCwgU3BhaW4KSW5zY3JpdGEgZW4gZWwgUmVn LiBNZXJjYW50aWwgZGUgTWFkcmlkIOKAkyBDLkkuRi4gQjgyNjU3OTQxIC0gUmVkIEhhdCBTLkwu Cg== ----_com.android.email_68837318013720 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keSA+PGRpdj48YnI+PC9kaXY+PGRpdj5U aGFua3MgSnVhbiBmb3IgdGhlIGNvbW1lbnRzLiBJIHdvdWxkIHVwZGF0ZSB0aGUgd2lraSBhY2Nv cmRpbmdseSBhbmQgc2VuZCBmb3IgY29uZmlybWF0aW9uLjwvZGl2PjxkaXY+PGJyPjwvZGl2Pjxk aXY+UmVnYXJkczwvZGl2PjxkaXY+U2h1YmhlbmR1PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48 ZGl2IHN0eWxlPSJmb250LXNpemU6NzUlO2NvbG9yOiM1NzU3NTciPlNlbnQgZnJvbSBTYW1zdW5n IE1vYmlsZTwvZGl2PjwvZGl2Pjxicj48YnI+PGJyPi0tLS0tLS0tIE9yaWdpbmFsIG1lc3NhZ2Ug LS0tLS0tLS08YnI+RnJvbTogSnVhbiBIZXJuw6FuZGV6ICZsdDtqaGVybmFuZEByZWRoYXQuY29t Jmd0OyA8YnI+RGF0ZTogMDkvMTIvMjAxNCAgMTg6NTEgIChHTVQrMDU6MzApIDxicj5UbzogU2h1 YmhlbmR1IFRyaXBhdGhpICZsdDtzaHRyaXBhdEByZWRoYXQuY29tJmd0OyxkZXZlbEBvdmlydC5v cmcsTWljaGFlbCBQYXN0ZXJuYWsgJmx0O21wYXN0ZXJuQHJlZGhhdC5jb20mZ3Q7IDxicj5TdWJq ZWN0OiBSZTogW292aXJ0LWRldmVsXSBHbHVzdGVyIFZvbHVtZSBTbmFwc2hvdHMgLSBGZWF0dXJl IHJldmlldyA8YnI+IDxicj48YnI+T24gMTIvMDQvMjAxNCAwNzoxMSBQTSwgU2h1YmhlbmR1IFRy aXBhdGhpIHdyb3RlOjxicj4mZ3Q7IEhpIEp1YW4vTWljaGFlbCw8YnI+Jmd0OyA8YnI+Jmd0OyBU aGlzIGlzIGEgZ2VudGxlIHJlbWluZGVyIGZvciB0aGUgcmV2aWV3IG9mIHRoZSBSRVNUIGFwaSBk ZXNpZ24gZm9yIHRoZSA8YnI+Jmd0OyBiZWxvdyBmZWF0dXJlLjxicj4mZ3Q7IFdlIHdvdWxkIGJl IHN0YXJ0aW5nIHRoZSBSRVNUIGRldmVsb3BtZW50IGZvciB0aGUgc2FtZSBzb29uIChwcm9iYWJs eSBieSA8YnI+Jmd0OyBEZWMgMjAxNCBlbmQpLjxicj4mZ3Q7IDxicj4mZ3Q7IElmIHRoZXJlIGFy ZSBzcGVjaWZpYyBjb21tZW50cywgcGxlYXNlIHBhc3MgaXQgb24uIElmIG5vIGNvbW1lbnRzIHdl IDxicj4mZ3Q7IHdvdWxkIGdvIGFoZWFkIHdpdGggdGhlIGN1cnJlbnQgZGVzaWduIGFuZCBpbXBs ZW1lbnQgYWNjb3JkaW5nbHkuPGJyPiZndDsgPGJyPiZndDsgUmVxdWVzdCB5b3VyIHRpbWUgZm9y IHRoaXMuPGJyPiZndDsgPGJyPiZndDsgVGhhbmtzIGFuZCBSZWdhcmRzLDxicj4mZ3Q7IFNodWJo ZW5kdTxicj4mZ3Q7IDxicj4mZ3Q7IE9uIDExLzEwLzIwMTQgMTI6MjIgUE0sIFNodWJoZW5kdSBU cmlwYXRoaSB3cm90ZTo8YnI+Jmd0OyZndDsgSGkgQWxsLDxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0 OyBQbGVhc2UgaGVscCB1cyB0byByZXZpZXcgdGhlIGRlc2lnbiBvZiBHbHVzdGVyIFZvbHVtZSBT bmFwc2hvdHMgaW4gb1ZpcnQsPGJyPiZndDsmZ3Q7PGJyPiZndDsmZ3Q7IEhlcmUgYXJlIHR3byBk ZXNpZ24gb24gd2lraSBwYWdlPGJyPiZndDsmZ3Q7PGJyPiZndDsmZ3Q7IEdlbmVyYWwgRmVhdHVy ZSBEZXNpZ248YnI+Jmd0OyZndDsgaHR0cDovL3d3dy5vdmlydC5vcmcvRmVhdHVyZXMvR2x1c3Rl clZvbHVtZVNuYXBzaG90czxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyBEZXRhaWxlZCBEZXNpZ248 YnI+Jmd0OyZndDsgaHR0cDovL3d3dy5vdmlydC5vcmcvRmVhdHVyZXMvRGVzaWduL0dsdXN0ZXJW b2x1bWVTbmFwc2hvdHM8YnI+Jmd0OyZndDs8YnI+Jmd0OyZndDsgV2UgdGFyZ2V0IGl0IGluIG92 aXJ0IDMuNiByZWxlYXNlLjxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyBNYXJrZWQgSnVhbi9NaWNo YWVsIHNwZWNpZmljYWxseSBmb3IgUkVTVCByZXZpZXcuPGJyPiZndDsmZ3Q7PGJyPiZndDsmZ3Q7 IEJlc3QgUmVnYXJkcyw8YnI+Jmd0OyZndDsgU2h1YmhlbmR1IFRyaXBhdGhpPGJyPjxicj5NeSBj b21tZW50cyBhYm91dCB0aGUgUkVTVEFQSTo8YnI+PGJyPjEuIFlvdSBjYW4ndCB1c2UgdGhlICJz bmFwc2hvdCIgYW5kICJzbmFwc2hvdHMiIFhNTCBlbGVtZW50cywgYXMgdGhvc2U8YnI+YXJlIGFs cmVhZHkgaW4gdXNlIGZvciBkaXNrIHNuYXBzaG90cywgYW5kIHdlIGRvbid0IGhhdmUgbmFtZSBz cGFjZTxicj5zdXBwb3J0IGluIHRoZSBSRVNUQVBJLiBZb3Ugd2lsbCBoYXZlIHRvIHVzZSBzb21l dGhpbmcgZGlmZmVyZW50LCBmb3I8YnI+ZXhhbXBsZSAiZ2x1c3Rlcl92b2x1bWVfc25hcHNob3Rz IiBhbmQgImdsdXN0ZXJfdm9sdW1lX3NuYXBzaG90Ii48YnI+PGJyPjIuIFdoZW4gYWRkaW5nIGEg dm9sdW1lIHNuYXBzaG90IHRoZSBuYW1lIG9mIHRoZSB2b2x1bWUgc2hvdWxkbid0IGJlIGE8YnI+ cGFyYW1ldGVyLCBhcyB0aGF0IGlzIGltcGxpY2l0LiBPbmx5IHRoZSBuYW1lIGFuZCBkZXNjcmlw dGlvbiBvZiB0aGU8YnI+c25hcHNob3Qgc2hvdWxkIGJlIHByb3ZpZGVkLjxicj48YnI+My4gVGhl IG9wZXJhdGlvbiB0byBkZWxldGUgYSBzbmFwc2hvdCBzaG91bGQgYmUgcGVyZm9ybWVkIG9uIHRo ZTxicj5zbmFwc2hvdCByZXNvdXJjZSwgbm90IG9uIHRoZSBjb2xsZWN0aW9uOjxicj48YnI+Jm5i c3A7IERFTEVURTxicj4vY2x1c3RlcnMve2NsdXN0ZXI6aWR9L2dsdXN0ZXJ2b2x1bWVzL3t2b2x1 bWU6aWR9L3NuYXBzaG90cy97c25hcHNob3Q6aWR9PGJyPjxicj5JZGVhbGx5IHRoaXMgb3BlcmF0 aW9uIHNob3VsZG4ndCByZWNlaXZlIGFueSBwYXJhbWV0ZXJzICh0aHVzIG5vIGJvZHkpLjxicj5J ZiBpdCBkb2VzIHJlcXVpcmUgcGFyYW1ldGVycyB0aGVuIHRoZXkgc2hvdWxkIGJlIGNvbnRhaW5l ZCBpbnNpZGUgYW48YnI+ImFjdGlvbiIgZWxlbWVudC48YnI+PGJyPjQuIFRoZSBvcGVyYXRpb24g dG8gdXBkYXRlIHRoZSBzbmFwc2hvdCBjb25maWd1cmF0aW9uIHNob3VsZCBiZSB0aGUgUFVUPGJy Pm9wZXJhdGlvbiBvZiB0aGUgdm9sdW1lLCBub3QgYSBuZXcgInNuYXBzaG90Y29uZmlnIiBzdWIt cmVzb3VyY2UsIGFzPGJyPnRoZXNlIGtpbmQgb2Ygc3ViLXJlc291cmNlcyBhcmVuJ3Qgd2VsbCBz dXBwb3J0ZWQgYnkgdGhlIFNES3MgYW5kIHRoZSBDTEkuPGJyPjxicj4tLSA8YnI+RGlyZWNjacOz biBDb21lcmNpYWw6IEMvSm9zZSBCYXJkYXNhbm8gQmFvcywgOSwgRWRpZi4gR29yYmVhIDMsIHBs YW50YTxicj4zwrpELCAyODAxNiBNYWRyaWQsIFNwYWluPGJyPkluc2NyaXRhIGVuIGVsIFJlZy4g TWVyY2FudGlsIGRlIE1hZHJpZCDigJMgQy5JLkYuIEI4MjY1Nzk0MSAtIFJlZCBIYXQgUy5MLjxi cj48L2JvZHk+ ----_com.android.email_68837318013720--

2 4

[Feature review] - Disk Provisioning for Gluster
by Ramesh 23 Dec '14

23 Dec '14

This is a multi-part message in MIME format. --------------000000060506010201040503 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi all, We are working on disk provisioning feature for Gluster in Ovirt. It helps the customer to provision the physical disks directly from oVirt. We are targeting this for Ovirt 3.6. Please review the feature/design and provide your comments. Feature page: http://www.ovirt.org/Features/GlusterHostDiskManagement Detailed design: http://www.ovirt.org/Features/Design/GlusterHostDiskManagement Regards, Ramesh --------------000000060506010201040503 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit <html> <head> <meta http-equiv="content-type" content="text/html; charset=utf-8"> </head> <body bgcolor="#FFFFFF" text="#000000"> Hi all, We are working on disk provisioning feature for Gluster in Ovirt. It helps the customer to provision the physical disks directly from oVirt. We are targeting this for Ovirt 3.6. Please review the feature/design and provide your comments. Feature page: <meta http-equiv="content-type" content="text/html; charset=utf-8"> <a href="http://www.ovirt.org/Features/GlusterHostDiskManagement">http://www.ovirt.org/Features/GlusterHostDiskManagement</a> Detailed design: <a href="http://www.ovirt.org/Features/Design/GlusterHostDiskManagement">http://www.ovirt.org/Features/Design/GlusterHostDiskManagement</a> Regards, Ramesh </body> </html> --------------000000060506010201040503--

3 2

CORS enabled for oVirt REST API
by Jenny Kang 23 Dec '14

23 Dec '14

Hello, As part of my OPW project, I'm trying to build a mobile web UI for oVirt but I'm having some troubles. I cannot access the oVirt REST API because it doesn't allow cross origin resource sharing (CORS). The only way to access the API is to host the UI on the same IP as the engine. If it is enabled then people would be able to run the mobile UI directly from the desktop without hosting it anywhere. Do you have any suggestions on how to access oVirt REST API from another host inside the browser? Any plans on enabling CORS on the REST API? Thank you! Cheers Jenny

1 0