- Devel - oVirt List Archives

[Engine-devel] Failed to execute stage 'Misc configuration'
by Michael Pasternak 13 Aug '13

13 Aug '13

Any insight? [ ERROR ] Failed to execute stage 'Misc configuration': Command '/home/mpastern/Coding/ovirt/ovirt-engine/share/ovirt-engine/dbscripts/upgrade.sh' failed to execute [WARNING] Rolling back upgrade * rebased at 20031dd61f6c6517a5e21d38485c3c3b626fd8aa -- Michael Pasternak RedHat, ENG-Virtualization R&D

3 3

[Engine-devel] Deprecating signatures/parameters in restapi (RSDL)
by Michael Pasternak 12 Aug '13

12 Aug '13

Hi All, We have added the ability to deprecate signatures/parameters in RSDL, you can mark parameter as deprecated in rsdl_metadata.yaml file this way [1], please make sure you deprecating signatures/parameters which planned to be non-maintained/removed. thanks. [1] signature parameter: =================== vm.display.type--DEPRECATED: xs:string url parameter: ============= max: {context: matrix, type: 'xs:int', value: 'max results', required: false, deprecated: true} header parameter: ================= Filter: {value: true|false, required: false, deprecated: true} entire signature: ================ - mandatoryArguments: {} optionalArguments: {action.vm.os.initRd: 'xs:string', action.vm.domain.name: 'xs:string', action.vm.placement_policy.host.id|name: 'xs:string', action.vm.placement_policy.affinity: 'xs:string', action.async: 'xs:boolean', action.vm.os.kernel: 'xs:string', action.grace_period.expiry: 'xs:long', action.vm.display.type: 'xs:string', action.vm.stateless: 'xs:boolean', action.vm.os.cmdline: 'xs:string', action.vm.domain.user.username: 'xs:string', action.pause: 'xs:boolean', action.vm.os.boot--COLLECTION: {boot.dev: 'xs:string'}, action.vm.domain.user.password: 'xs:string'} deprecated: true -- Michael Pasternak RedHat, ENG-Virtualization R&D

1 0

[Engine-devel] Port mirroring in 3.4
by Moti Asayag 12 Aug '13

12 Aug '13

Hi All, As part of adding the the vnic profiles feature, the configuration of the port mirroring moved from a vnic level to the profile level which the vnic uses. It unravels the need for granting a specific PORT_MIRRORING action group on the network to allow the user to set a vnic for port mirroring on that network. The old behaviour was simplified by granting the VnicProfileUser role on the profile that the admin permits the user to use. The admin is responsible to determine whether the profile should be served for port mirroring or not. It makes the old PORT_MIRRORING action group redundant, as it is no longer being used for controlling the port mirroring attribute of the network on the vm. An existing permissions for user for port mirroring will be replaced with a proper permissions on a vnic profile setted for port mirroring during upgrade. I would like to remove the PORT_MIRRORING action group entirely from the engine and from the REST as well. Is there any objection for doing so ? Thanks, Moti

1 0

Re: [Engine-devel] [vdsm] How to handle qemu 1.3 dep for Gluster Storage Domain
by Andrew Cathrow 12 Aug '13

12 Aug '13

> ----- Forwarded Message ----- > > From: "Itamar Heim" <iheim(a)redhat.com> > > To: "Sahina Bose" <sabose(a)redhat.com> > > Cc: "engine-devel" <engine-devel(a)ovirt.org>, "VDSM Project > > Development" <vdsm-devel(a)lists.fedorahosted.org> > > Sent: Wednesday, August 7, 2013 1:30:54 PM > > Subject: Re: [vdsm] How to handle qemu 1.3 dep for Gluster Storage > > Domain > > > > On 08/07/2013 08:21 AM, Sahina Bose wrote: > > > [Adding engine-devel] > > > > > > On 08/06/2013 10:48 AM, Deepak C Shetty wrote: > > >> Hi All, > > >> There were 2 learnings from BZ > > >> https://bugzilla.redhat.com/show_bug.cgi?id=988299 > > >> > > >> 1) Gluster RPM deps were not proper in VDSM when using Gluster > > >> Storage > > >> Domain. This has been partly addressed > > >> by the gluster-devel thread @ > > >> http://lists.gnu.org/archive/html/gluster-devel/2013-08/msg00008.html > > >> and will be fully addressed once Gluster folks ensure their > > >> packaging > > >> is friendly enuf for VDSM to consume > > >> just the needed bits. Once that happens, i will be sending a > > >> patch to > > >> vdsm.spec.in to update the gluster > > >> deps correctly. So this issue gets addressed in near term. > > >> > > >> 2) Gluster storage domain needs minimum libvirt 1.0.1 and qemu > > >> 1.3. > > >> > > >> libvirt 1.0.1 has the support for representing gluster as a > > >> network > > >> block device and qemu 1.3 has the > > >> native support for gluster block backend which supports > > >> gluster://... > > >> URI way of representing a gluster > > >> based file (aka volume/vmdisk in VDSM case). Many distros (incl. > > >> centos 6.4 in the BZ) won't have qemu > > >> 1.3 in their distro repos! How do we handle this dep in VDSM ? > > >> > > >> Do we disable gluster storage domain in oVirt engine if VDSM > > >> reports > > >> qemu < 1.3 as part of getCapabilities ? > > >> or > > >> Do we ensure qemu 1.3 is present in ovirt.repo assuming > > >> ovirt.repo is > > >> always present on VDSM hosts in which > > >> case when VDSM gets installed, qemu 1.3 dep in vdsm.spec.in will > > >> install qemu 1.3 from the ovirt.repo > > >> instead of the distro repo. This means vdsm.spec.in will have > > >> qemu >= > > >> 1.3 under Requires. > > >> > > > Is this possible to make this a conditional install? That is, > > > only if > > > Storage Domain = GlusterFS in the Data center, the bootstrapping > > > of host > > > will install the qemu 1.3 and dependencies. > > > > > > (The question still remains as to where the qemu 1.3 rpms will be > > > available) RHEL6.5 (and so CentOS 6.5) will get backported libgfapi support so we shouldn't need to require qemu 1.3 just the appropriate qemu-kvm version from 6.5 https://bugzilla.redhat.com/show_bug.cgi?id=848070 > > > > > > > hosts are installed prior to storage domain definition usually. > > we need to find a solution to having a qemu > 1.3 for .el6 (or > > another > > version of qemu with this feature set). > > > > > >> What will be a good way to handle this ? > > >> Appreciate your response > > >> > > >> thanx, > > >> deepak > > >> > > >> _______________________________________________ > > >> vdsm-devel mailing list > > >> vdsm-devel(a)lists.fedorahosted.org > > >> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel > > > > > > _______________________________________________ > > > vdsm-devel mailing list > > > vdsm-devel(a)lists.fedorahosted.org > > > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel > > > > _______________________________________________ > > vdsm-devel mailing list > > vdsm-devel(a)lists.fedorahosted.org > > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel > > >

1 0

[Engine-devel] LockManager maybe not be really taking locks in your flows...
by Yair Zaslavsky 12 Aug '13

12 Aug '13

Hi all, Thanks to Alon Bar Lev's efforts for preventing to concurrent host installation for the same host entity + Roy Golan's check of the code, we saw that for commands that override getExclusiveLocks() or getSharedLocks() the locking mechanism does not work (lock is not being acquired) if there is no annotation of @LockIdNameAttribute on the class. A bug was filed for removing this annotation (leftover from some historical code ) , but until it is fixed - bare in mind you need to add this annotation in current commands you are working on in order to utilize the mechanism. See RemoveVmCommand (has the annotation) vs AddDiskCommand (which doesn't have the annotation) Cheers, Yair

3 4

[Engine-devel] should we check for active host before activate SD?
by plysan 12 Aug '13

12 Aug '13

Hi all: Currently I get into a situation with a NFS data center which maintained both hosts and storage domains. Now if I first activate host then SD, everything works fine. But if I mistakenly first activate SD, the data center gets into a non responsive status, after this if I try to activate a host, it will get into a non operational state, it seems I can't find a way to get the DC running again. I think a additional check should be done before activate a SD, and i've uploaded a patch for a solution of this issue: http://gerrit.ovirt.org/17940 I haven't test with other storage types, but activating a SD need a functioning host, right? correct me if i'm wrong :) Best regards, plysan

2 2

[Engine-devel] [oVirt/RHEV 3.3 Localization Question #14] "No Position"
by Yuko Katabami 12 Aug '13

12 Aug '13

This is a multi-part message in MIME format. --------------080006040707040909010608 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello again. I would like to ask one more question with the following details: *File:* ApplicationConstants *Resource ID: * noPositionFilter *Strings:***No Position *Question:* Could anyone please explain the usage of this string and where in the Admin Portal it appears? Thank you, Yuko -- Regards, Yuko Katabami (?????) Technical Translator II NAATI Accredited Professional Translator (English into Japanese) #28138 RHCSA #111-119-244 *Mobile:* +61 415 847 352 *Email:* ykatabam(a)redhat.com Red Hat *Red Hat, Asia-Pacific Pty Ltd* Level 1, 193 North Quay Brisbane 4000 *Office:* +61 7 3514 8100 *Fax:* +61 7 3514 8199 *Website:* www.redhat.com <http://www.redhat.com> *Facebook:* Red Hat APAC <http://www.facebook.com/redhatapac> | Red Hat Japan <http://www.facebook.com/redhatjapan> | Red Hat Korea <http://www.facebook.com/redhatkorea> | JBoss APAC <http://www.facebook.com/JBossAPAC> *Twitter:* Red Hat APAC <http://www.twitter.com/red_hat_apac> | Red Hat ANZ <http://www.twitter.com/redhatanz> *LinkedIn:* Red Hat APAC <http://www.linkedin.com/groups?gid=3124596> | JBoss APAC <http://www.linkedin.com/groups?gid=4068303> --------------080006040707040909010608 Content-Type: multipart/related; boundary="------------080601050400080508090608" --------------080601050400080508090608 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <html> <head> <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> </head> <body bgcolor="#FFFFFF" text="#000000"> Hello again. I would like to ask one more question with the following details: File: ApplicationConstants Resource ID: <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> noPositionFilter Strings: No Position Question: Could anyone please explain the usage of this string and where in the Admin Portal it appears? Thank you, Yuko <div class="moz-signature">-- Regards, Yuko Katabami (方波見裕子) Technical Translator II NAATI Accredited Professional Translator (English into Japanese) #28138 RHCSA #111-119-244 Mobile: +61 415 847 352 Email: <a class="moz-txt-link-abbreviated" href="mailto:ykatabam@redhat.com">ykatabam(a)redhat.com</a> <a target="_blank"><img src="cid:part1.09020107.09080707@redhat.com" alt="Red Hat" border="0" height="42" width="128"></a> Red Hat, Asia-Pacific Pty Ltd Level 1, 193 North Quay Brisbane 4000 Office: +61 7 3514 8100 Fax: +61 7 3514 8199 Website: <a href="http://www.redhat.com" target="_blank">www.redhat.com</a> Facebook: <a href="http://www.facebook.com/redhatapac" target="_blank">Red Hat APAC</a> | <a href="http://www.facebook.com/redhatjapan" target="_blank">Red Hat Japan</a> | <a href="http://www.facebook.com/redhatkorea" target="_blank">Red Hat Korea</a> | <a href="http://www.facebook.com/JBossAPAC" target="_blank">JBoss APAC</a> Twitter: <a href="http://www.twitter.com/red_hat_apac" target="_blank">Red Hat APAC</a> | <a href="http://www.twitter.com/redhatanz" target="_blank">Red Hat ANZ</a> LinkedIn: <a href="http://www.linkedin.com/groups?gid=3124596" target="_blank">Red Hat APAC</a> | <a href="http://www.linkedin.com/groups?gid=4068303" target="_blank">JBoss APAC</a> </div> </body> </html> --------------080601050400080508090608 Content-Type: image/png; name="redhat-logo.png" Content-Transfer-Encoding: base64 Content-ID: <part1.09020107.09080707(a)redhat.com> Content-Disposition: inline; filename="redhat-logo.png" iVBORw0KGgoAAAANSUhEUgAAAIAAAAApCAYAAAD9LSHtAAAAGXRFWHRTb2Z0d2FyZQBBZG9i ZSBJbWFnZVJlYWR5ccllPAAAA6NpVFh0WE1MOmNvbS5hZG9iZS54bXAAAAAAADw/eHBhY2tl dCBiZWdpbj0i77u/IiBpZD0iVzVNME1wQ2VoaUh6cmVTek5UY3prYzlkIj8+IDx4OnhtcG1l dGEgeG1sbnM6eD0iYWRvYmU6bnM6bWV0YS8iIHg6eG1wdGs9IkFkb2JlIFhNUCBDb3JlIDUu MC1jMDYxIDY0LjE0MDk0OSwgMjAxMC8xMi8wNy0xMDo1NzowMSAgICAgICAgIj4gPHJkZjpS REYgeG1sbnM6cmRmPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50YXgt bnMjIj4gPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIgeG1sbnM6eG1wTU09Imh0dHA6 Ly9ucy5hZG9iZS5jb20veGFwLzEuMC9tbS8iIHhtbG5zOnN0UmVmPSJodHRwOi8vbnMuYWRv YmUuY29tL3hhcC8xLjAvc1R5cGUvUmVzb3VyY2VSZWYjIiB4bWxuczp4bXA9Imh0dHA6Ly9u cy5hZG9iZS5jb20veGFwLzEuMC8iIHhtbG5zOmRjPSJodHRwOi8vcHVybC5vcmcvZGMvZWxl bWVudHMvMS4xLyIgeG1wTU06RG9jdW1lbnRJRD0ieG1wLmRpZDpDMTM3NDQ3MkZCQzExMUUw OTQzNzk0QTNCNkFFNjg1RCIgeG1wTU06SW5zdGFuY2VJRD0ieG1wLmlpZDpDMTM3NDQ3MUZC QzExMUUwOTQzNzk0QTNCNkFFNjg1RCIgeG1wOkNyZWF0b3JUb29sPSJBZG9iZSBJbGx1c3Ry YXRvciBDUzMiPiA8eG1wTU06RGVyaXZlZEZyb20gc3RSZWY6aW5zdGFuY2VJRD0idXVpZDpD QzZBQjQzODY4MDNERDExOENBRDk2OTlCQTZCNjM4OSIgc3RSZWY6ZG9jdW1lbnRJRD0idXVp ZDpDQjZBQjQzODY4MDNERDExOENBRDk2OTlCQTZCNjM4OSIvPiA8ZGM6dGl0bGU+IDxyZGY6 QWx0PiA8cmRmOmxpIHhtbDpsYW5nPSJ4LWRlZmF1bHQiPnJlZGhhdF9jbXlrX2xvZ288L3Jk ZjpsaT4gPC9yZGY6QWx0PiA8L2RjOnRpdGxlPiA8L3JkZjpEZXNjcmlwdGlvbj4gPC9yZGY6 UkRGPiA8L3g6eG1wbWV0YT4gPD94cGFja2V0IGVuZD0iciI/Pv93CnUAAA4OSURBVHja7FwL dBTVGf5ms49kySYkgSQkIZCkvKLyCCAIEQRFLdIiqPUN4qsitmhFQKgWKlpRQT1HsEINePBR hfr2+ECUtAoICCggGEKCEEkC5EFeu9nN7vS/s/+SyWR2s4mBgGf/cz4ye+femdn7f/d/3Vkk tE0MhPMJowgXEXoRkgidCDJBItgJxYQCwhbCRsL3BBdCcs5KLGEGYSuhgZUdLDyE3YQ5hITQ VJ5bEk54kFe03A4oJywgRIWm9uyX4YRdzZVo0EBSwffZ11fSfD6FPMKloSnuOJFaOC/M/RKC RT0kMtyM0amJSDYZ4ZJlFLvcOFJrR62rARFGI/pEWTHYYkKiLMFEIwpJ9+9X1GDnkRLWexMR ruFRwuMhdZxdBHiS/XVTX0BKX9o3HVdUS6RK73AXHdUpQYEMM7W5jMCOCBnbPA04aHeid4QF 1zUY8ZzswEd5h/VIIORFwr0hlZxZCfPT/hRhtl7wPy4jBTPtJtTTpypSpIPgIqVLyllJUa2b rEKCE4iwGLD6cDE2HS1D/+RY/NFhwnqzjPJah949hxISCR+F1NKxBLiPsMjfgBtTuiLFKWGX TUZvpwERpPRwholQr1zUS4gCCh37xNpwd3wchpHFsJFLkOMikFta7u/yQ9gqbQyppmNcwEjC hqY+v1GMYQa83bsXdhg9WLD7IKZk9kQ8tZW4Pagh9LUYMbHaADMp2kO2QJDDopBCWArvzTwG YKqjAj8cPe7PFQi5mvBeSD1n1gJYCW8RuvvjSjqt5NskK+JIk9tNEjYUknk/Vo4Kj4yqBjec hjAMMxgR4ZGUyE4UCoSLaOArCHXHyAaUdzZhy7HKQAQQ7uB1Ql1IRWeOADMJUwMZi4GJcbhG NiO6QUJWdARORFsxJzkB96MTbjFaMV4mJ+CmGMC/YhViJJDV+KTejjpnQ6CCk5DPz8E5FYmP qIpWn0sEiCesaizMeEO6xmMv0mKjcLXHhJOk4FiXhIlEhuR6KNmAk/4Vpl5u4YZuMTtuA76L MiG/vDqQFcgkrCVUnGME6AxvpfR6tqYi4Ck9Wx/WyH9vJiT7FJ4SG40R8Z3Rx2xEJBFBdDrs cSMnvwiv9UrFzdVhICOAWor23S2qXF9GUGr4SeCxMYQ7CfPOMQIIIxdJGMboy2TwfSdBkMKz iQASE0A5HJmWhEWmSKQ6yI9z5GYiRa+PNqHa4cKjuw/gm949MMliwQU1EmJlr6UQxtyO4Ahh p+tlUQbR2WpBZV19ICtwHWckv5ZYIIvwCQfbW8+GBxLaG8RQFHFnVCS6U5pXTkSuFJDFXyDN 7kFql2hlyEd5R3Dn7jzcai/DgxYHVtoa8LXNAzvRqbNkUOoBgUSQJc4FdLVFonHzUHfMb3iy fi0i86LrdIbuJyzQGkLXQBZgVKPDl5SlJktNF6Wo9CXTil3YLV7ZwfnpxEmlb15JGaEc77Pl S+sai98nxGBajdewePysbHH2CCWa1nojVp/fGwcMHnxaWYvth0u8T0H3l+VTY8cQ1v/Kgm/5 DN3ncnY/DwayAMPUDWur6xQnFqZZkTXUOpxitpy4eEzN7IH46E68an07veTYjlfg+T0F2ESh ZKQkBfQ7XxrcuCrGhotrDJhWZcQqQxTm989QSs1y0+m5sB0mQqS4afC/+yjOpxJ68mqRgryu qJekEHqw32+LhPO9U/k4GKstKqbpHLcZgyCbJ9DF0tV9NxYUYYnVhWiaA2MzEsjoQi77r3UW vJqYhAcuSMOg7olKgUidNXxWX6/sB/oTcZ1xDQbcUG1QXE0FQbwlckdVGOb166ntnt6KyRV7 CdsI3xAe4Lbp8L6HUKBq80kGvHsQewg/Eg7wX2FxrmghQP07vLukeYy9hGeYQA1BBIpC/kbI JxwShpWP/+JHqV24/w8cRO4XhpQ/36jp+yq8L99M57RUFPe28/Nuhup9DGNj9N9IghV7C+DM TMNDdSalvGtXWSyR7gkk1EuYUW/C1LAo7O1rw9eSG7tr61F4sgYbj5RgfUYqLqmWUKtj7QSt kh3eCmFjeigTESRcU2XAe0Sqbxt3DsWE2hTetCyCPUP4+HtW+FLNilVXG1dxVK5V7qUMsRn2 lOa8WO0fEC7QtKeyqf1tECtZBFMb+Xn/QdjJtY874N197U+4TTPmeq7VLCPkEo6z9ZnJRTNh 3V7ivpsIBwmjOcXfwHUJk6JCwKHWRTl/6WbGYUx6MuaarcggZVX5ifANyj4AlJKvIMYJolSx xVsniHXCbxzgN4mmIPJ+k10JNHmhCOMwgLAviOGP8MoEr+TOaPr20WLCXHjfcfiCEMHt27gK Km54Lbyvuan96HqVq8hVkQw8sYJsZn5Os+aZ3lKlgWP4vj/xiryJFaKWhfBuj4sMaJ2qPZLr Nid1vve7HMuJV/PKNPMxn4lywp8L8Gulviz4GdNKS/CKza1QJ0onwvcoW8GyYsbFS4CUECCz VkJcG5Qvri1SxGK7s61xknqbsQ8rP4/N6q1cWBLyuEr5Yvcxm833Up5IdQVSHUBN1yhfuJrB PP5CdhulQQR/NVx1der0WcKr+/ZmnlNf+eDnFot4hG4JN0BMY2jJVR2tqMJju/NxU20pPjQ6 leAuCvqpnkep+3u3iNtSIIqia28nQ7azqLitBNA+1H5W6LPsF78lXEwYqyLMHI0iGjRuYwSv ICFTVO1VbKYPqNo2sklu6flyCLV++lTxdbKCCPB8soeLrP3aUgiq03cBjaQddXE2si+5DG99 9jHWFhXgptgYjCL/Hk00qOMS8C8VUXGsCJPxAhFObpqHikpRZRsvu1RnRY5WHRezP75ItRic 7Dpc7DNt7Ks9mgn+mAmmlS/4eTsHeK69LTy38N+/42cr85N99OIgNpH1Fwb/73cEJMDPzQNB VVTVowfeeP0NJKWk4JH5czF6zFj8efMm9I2LxlWJXTDOHYY0B1kEyVvhc6F1pl/EDp0IB8Jl LHBUY0fz18aOo20bK+IiO3Ta1UoUqeHXQVwrjoloUrV966evK0DaJem4Kj2pZmVqLXQSW6zr mRzCiqj3StxtIUBBoFzbaDQiIsIb1IZbLHjh2SW4d8YMJCalYMkHH+Jf4WEYmtIN2VYLhjgl pDi8LkJxCZL37SC3qt4nvpWJTL14RVQUmA5RwPi+qQHvFB1HSaXu5lBBkBmAXsFRz8ya23At u0b5CGDC2+Kq9M5rJ0JkJf9hcjxB+JQtWBUTtLQVLqMJAUQgc0OzWTKb4XQ6kX/wIOY9/DBe XLFSaR86bDg2bd4Mk8mMh2fPxpNPP43P848oUVNMpwhlx7CnNRxpZiOSKWiMoa8RTuvBSiwQ pWKKD2lJe1DocWM/BXt7jlagrNqOxheFm8kvqZnrxTj1qmORT/+JeSkFuMb/ONhTS7czWDlM 4gB2F6eZ9vasLGZZwsPdVqtVjo6Ols/L7CfPuOceeduWb+TVL+fIUVFRimZWrVwp68mcWbNk rh5rXgH3QrTTDMpG7iOd6mMI9Lq4GuNa8V1mq8YJX56p02e+qs8JntxgpAevet9Yf64ji02x r9+bqnNjue2SFu41n4nqq+HP5HFD/PSPZYs3Tyctrg+4F7Ds+ed39h84YKfZZB4cabMhPSMD 4RHeDGnIsAtRXV2F+2fNwrS77kJMbCwmTp7c5ALCAmRnZyMnJwclx0oR2SkSyUlJGDRoIOrs DuTm5mLAgAHontoDX36xATZbJBK6xmPxkiXBTHp+kD66NSKM1WO84uPYnN4WxDhf7j5KlR3c zhG9Wh5qObtqtfTiVX/Iz/kEtmLa2MPN7f5dg9h0ITwgB5BtW7bIr69ZIxcfPSq3h9w3fXqw vyB6opUTFYwFAPtS9X1yuZzan+sHw7lusKJpqVwp3KjHOTjFFGZ5MmcG2u/w73awAIt5nL80 bzmfn6tpv4Pb+7ZEgHhCkdxOcqiwUP7808+U4x/37ZP3/bC3yfmLR44MRvllHKWL6tkfdIKw X0KAJK7eae/ZwOPUbddpxr7ZwnOXsqXwfX63HQiQzeNe0fQTcyJ+v3GM3dMzmvNDedx8Tbuw CpMIV/lMlbjAc+1lr15esQLjrrwCg7MGYfI1k/Hdzp2NERgFlpWVQaX1/+TNjgmEiVxrDyao DSbSPsqxxWto+mvlMB2iaf2nMPur/VxXkPYW3is4Vd9qYxagruB9xSXuKVzizuES8xG2Spdz yqt9oddX4l7E+wHvsrUQtYPxhCsl1b67qHP/VyfabbWcrKjA3r17sHz5cmSkZ2DhosafGZAr wc1TvAU1CjwxsH9/9OndW4kbjCYjTp6swv4f9x8sKCwclncgv4yebxwXYz5Ayz8tH8JFHRf7 v3Vo+Z1CYSUuYzMZzRaghPcetnKlTy+/HsFmP4nP72BzX8yB4EhefcJvf8hjknkT6h0mIQIE kkIPazQ1gzFMgniOCTYwiat4oUB1L7Ve72brY+B9jWXstlw+F+DDSIJDPk0iYojMfv1OZQMi FtCTn4uKJr69bh2yBg5ESE6zaAggcN/pIsCE8eMVxQ8dMlh+ZvFif0HlAt+zXDtpUkhBHUAA gafaW/kvLV+mKH/ihAmyy+Xy1+1F9XOECNBxBBB4sr2Uv23rVjmpWzf5srFj5Mrycn/dlmuf IUSAjiWAwIz2iAm+ys2V31671t/KdxPm690/RICOJ4DAcMKu0xQW5BEu9XfvEAFOvwRTstzC lbFZnB61h4jUbAGnbRtCaji7CQDORUXx/jx4//+AbWj93rPIifdwuVKUNBdy/hqSDpTW7h+X cxFBvErd0v8TWMdl0YMI/T+BZ638X4ABALiJt5GyzHDtAAAAAElFTkSuQmCC --------------080601050400080508090608-- --------------080006040707040909010608--

2 2

[Engine-devel] clean testable code
by Giuseppe Vallarelli 11 Aug '13

11 Aug '13

Talking with my teammates I've noticed that there is some confusion related to what testing means and in general how tests can improve the quality of the codebase by favouring the development of components that are of higher quality - unluckily it doesn't favour hair regrowing. Tests are also cool because when done right they represent an executable form of documentation. Some intro material: 1 How to Write Clean, Testable Code by Miško Hevery (A Googler) http://www.youtube.com/watch?v=XcT4yYu_TTs 2 How to write testable code by Miško Hevery (hands on ;-)) http://misko.hevery.com/attachments/Guide-Writing%20Testable%20Code.pdf Examples are provided in Java but the same principles apply to Python as well. 3 TDD by James Shore (a practice created by Kent Beck) http://www.jamesshore.com/Agile-Book/test_driven_development.html A broad article explaining TDD and related concepts. 4 Difference between state based testing and interaction based testing http://martinfowler.com/articles/mocksArentStubs.html Not so intro - but easier to understand after consuming previous material: 5 Mock Roles, not Objects by Freeman and Pryce http://jmock.org/oopsla2004.pdf They both wrote a very interesting book: Growing Object Oriented Software: Guided by Tests http://www.amazon.com/Growing-Object-Oriented-Software-Guided-Tests/dp/0321… I didn't read it yet. Points from 3 to 5 mostly describe a different kind of working practice, which is very opinionated but nevertheless with some interesting ideas. I consider points 1-2 fundamentals. Enjoy, Giuseppe I will share new materials if there's some interest on it.

1 0

[Engine-devel] users cannot log into userportal
by Dead Horse 09 Aug '13

09 Aug '13

Seeing and issue where users are not able to log in. Also for some reason the engine is seemingly forgeting about AD users. Removing the AD domain via engine-manage-domains and re-adding it works for enumerating the users, however the first attempt to login as a user results in the engine no longer enumerating the users nor allowing logins. Attached are the pertinent logs. Engine is built and running from current master as of this morning, and was installed/built and upgraded via RPMs yum/engine-upgrade - DHC

5 15

[Engine-devel] direct manipulation of libvirt
by Dead Horse 09 Aug '13

09 Aug '13

A broad question here, perhaps not a possibility but I figured I would toss it out there anyway. VDSM is great at what it does, however there are those times when direct manipulation of libvirt or libvirt VM configuration would be very handy. The safe defaults and tested VM configurations that VDSM/ovirt provides are great. However at times it would be nice to simply connect to a hypervisor managed by ovirt/vdsm and make a couple changes to a VM (via virt-manager or directly via virsh). This could be enabling a new feature that has made it's way into QEMU/libvirt/KVM or tweaking a VM configuration for whatever reason. Now there is nothing stopping someone from doing this now either directly or via VDSM hooks. Hooks are a pain along with the custom properties to jack them into engine. Direct manipulation of libvirt since it has been upstarted by vdsm results in an unhappy VDSM/engine. Thoughts? - DHC

3 5