June 2014 - Devel - oVirt List Archives

Re: [ovirt-devel] oVirt's MoM feature list ?
by Adam Litke 18 Jun '14

18 Jun '14

On 13/06/14 11:52 +0000, Vinod, Chegu wrote: >Cc'ng Gilad >Vinod > >From: Vinod, Chegu >Sent: Friday, June 13, 2014 4:45 AM >To: alitke(a)redhat.com >Subject: oVirt's MoM feature list ? > >Hi Adam, > >Where can I find some information about the future features/enhancements that are planned in MoM ? Perhaps it was discussed already in some email group or in some presentation...If yes can you please point me to the same ? This is a great question for the devel list (added to cc:). I think Doron and Martin (added to cc:) will be able to give some better responses to this as well. -- Adam Litke

3 2

Gerrit planned downtime
by David Caro 18 Jun '14

18 Jun '14

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --0UcbK2UxKcnbGFPGbXNtbAHvUs0U3hihB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi! In 15 minutes I'll start updating the gerrit machine, it will take some t= ime and I'll have to reboot it after, that should be the only planned downtime, b= ut if you might have some slowness and maybe even connection failures when updating/rebooting, I'll send an update once finished. Cheers! --=20 David Caro Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization R&D Email: dcaro(a)redhat.com Web: www.redhat.com RHT Global #: 82-62605 --0UcbK2UxKcnbGFPGbXNtbAHvUs0U3hihB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJToIMpAAoJEEBxx+HSYmnDpqkH/02c2SOoqc18ymenAx9rZsF1 oAkJRcty1GxE3OgsdqdzVWJP6IN4hR0DxOBmWGOBA6SlyL0gnJcPMRE7sYXcB/4j FQBFNauytwfWEkfI2rcmBWGT91l2uzZntkEKlE+hkf9UEG4VZm7omwVqvg/wwLPt Z0+U3oqADJUorMTQmSiRfm1tOfp2WmMbamREyTOQHxPgzTkDtd+ElnNLMpR8rQZ+ eCip16/LQ7PBTihJu2346bS/oI/zVAZcvjTkWT677JHgG/tyHETjRLfIsWAftbdD L+MgDxXe6iFoYpEbUnAwid81xW03YR+kRXyHv+IQqgpDt09qdg6UdPcLB2Pu1n8= =da5c -----END PGP SIGNATURE----- --0UcbK2UxKcnbGFPGbXNtbAHvUs0U3hihB--

1 2

oVirt.js - source control & distribution
by Vojtech Szocs 17 Jun '14

17 Jun '14

Hello, I'd like to share my ideas on how to manage oVirt.js source code and distribution for consumer applications. Please let me know what you think, nothing is set in stone :) 1, Idea: separate git repo for oVirt.js, example: "ovirt-engine-sdk-js" - using Node/Grunt for building oVirt.js distributable package - development build: ovirt.js - production build: ovirt.min.js - source maps for production build: ovirt.min.js.map - not sure we really need platform (make/RPM) build here, since WebAdmin & UserPortal are planned to have oVirt.js injected right into their output (GWT-generated) JavaScript code (no need to fetch it at runtime) 2, Idea: contain GWT/Java overlay for oVirt.js in "ovirt-engine" repo - overlay = Java facade to oVirt.js which uses JSNI [1] to delegate calls to underlying JavaScript (oVirt.js) code - for now, WebAdmin & UserPortal are the only GWT applications intended to consume oVirt.js, we can extract the overlay into different repo later if needed 3, Idea: distribute oVirt.js via Bower [2] for common audience - just like any other JavaScript library is distributed - this is similar to oVirt _Java_ SDK distributed via Maven Central (in that case, common audience = Java developers using Maven) 4, Idea: integrate oVirt.js into Engine Maven build as dependency - building oVirt.js would (also) produce ovirt-js-<version>.jar - GWT/Java overlay project (essentially GWT module) would depend on ovirt-js-<version>.jar, including its content into overlay's output JAR - WebAdmin & UserPortal would consume ovirt-js-gwt-<version>.jar (GWT overlay) as GWT module in their <moduleName>.gwt.xml files [1] http://www.gwtproject.org/doc/latest/DevGuideCodingBasicsJSNI.html [2] http://bower.io/ Regards, Vojtech

1 0

oVirt.js - API & implementation design summary
by Vojtech Szocs 17 Jun '14

17 Jun '14

Hello, this is a follow-up to my oVirt.js announcement email, I'd like to give you a quick summary of API & implementation design. In other words, I'll try to describe key decisions in oVirt.js API & implementation. 1, General design We're trying to follow best practices in JavaScript development, such as: - containing the whole SDK in a single global variable (because until ES6 we cannot truly avoid global variables) and using IIFE/closure for better information hiding - using ES5 "use strict" (Strict Mode) on function level (so that Strict Mode compliant environments will detect problems early) while not relying on semantical differences introduced by Strict Mode (main reason = IE9) 2, API design As presented in earlier "oVirt JavaScript SDK: Design Proposal" session, our main goals here are API usability and readability. (If you missed this session before, let me know and I'll forward you the slides.) - using fluent interface concept, for example: ovirt.api.datacenters.list().success(dcsListedCallback).run(); - separating the concept of resource (collection) vs. operation (operation = reusable RESTful method abstraction) - separating three logical namespaces: * ovirt.svc -- services used by API implementation Each service should be an object containing reusable methods. 1. existing services can be overridden to achieve SDK portability for given runtime environment. 2. existing services can be used and new services can be added by SDK extensions or clients. * ovirt.util -- utilities used by API implementation Unlike services, utilities are meant to assist with writing more efficient JavaScript code. * ovirt.api -- API as the main entry point to SDK functionality 3, Implementation design I've tried to catch up with my JavaScript knowledge recently, but I'm not an expert, I'm still learning things. Following are ideas which I took into practice within oVirt.js API implementation: - creating objects via mixins, each mixin is a function which gets some object ("that") and adds new properties to that object (augmentation) - simple dependency injection mechanism for mixins, with dependencies resolved against "ovirt.svc" namespace, for example: // Create new object, "spec" = information needed for object creation. function makeSomeObject (spec) { return mixins.mix(spec, [mixinOne, mixinTwo], // array of mixin functions ['depNameOne', 'depNameTwo'] // array of dependency names ); } // "that" = object to augment. // "spec" = information provided for object creation. // "my" = object containing shared secrets, for more details see [1] function mixinOne (that, spec, my) { // Augment "that" with "quack" method, utilize closure to capture // "spec.name" without exposing it to users of "that" object. that.quack = function () { console.log(spec.name + ' says quack!'); // Consume "depNameOne" service, resolved from ovirt.svc namespace that.doSomething = function () { my.depNameOne.whatever(); } } [1] JavaScript: The Good Parts (2008) by Douglas Crockford, chapter "Inheritance", section "Functional" - explanation of "my" object within functional constructor pattern We are NOT using "new" operator in JavaScript. We are also NOT relying on object's prototype chain. We are simply creating useful objects via mixins, which is in my opinion the most simple and flexible way. Regards, Vojtech

1 0

oVirt Node Weekly Meeting Minutes -- 2014-06-17
by Fabian Deutsch 17 Jun '14

17 Jun '14

Minutes: http://ovirt.org/meetings/ovirt/2014/ovirt.2014-06-17-13.01.html Minutes (text): http://ovirt.org/meetings/ovirt/2014/ovirt.2014-06-17-13.01.txt Log: http://ovirt.org/meetings/ovirt/2014/ovirt.2014-06-17-13.01.log.html ================================= #ovirt: oVirt Node Weekly Meeting ================================= Meeting started by fabiand at 13:01:20 UTC. The full logs are available at http://ovirt.org/meetings/ovirt/2014/ovirt.2014-06-17-13.01.log.html . Meeting summary --------------- * Agenda (fabiand, 13:01:36) * Build Status (3.0.5) (fabiand, 13:01:55) * Feature Status (3.5) (fabiand, 13:02:01) * Feature Status (ovirt-node-3.1) (fabiand, 13:02:13) * Other Items (fabiand, 13:02:17) * Action Item Review (fabiand, 13:03:35) * LINK: http://resources.ovirt.org/meetings/ovirt/2014/ovirt.2014-06-10-13.01.txt (fabiand, 13:04:05) * fabiand to finish OVA builds and push (fabiand, 13:04:47) * ovirt-appliance is pushed (sources) (fabiand, 13:05:27) * LINK: http://gerrit.ovirt.org/gitweb?p=ovirt-appliance.git (fabiand, 13:06:02) * LINK: http://dummdida.tumblr.com/post/88944206100/say-hello-to-the-ovirt-engine-v… (fabiand, 13:07:35) * announced on devel(a)ovirt.org (fabiand, 13:07:44) * rbarry about to post the email (fabiand, 13:10:45) * fabiand did not yet build images for 3.4.2 and 3.5 b/c of a failing tool (fabiand, 13:11:41) * Build Status (3.0.5) (fabiand, 13:12:14) * 3.0.5 is ready, just needs to be published with 3.5 packages (fabiand, 13:12:30) * Feature Status (3.5) (fabiand, 13:12:56) * hosted-engine-plugin -- Merged awaits testing (fabiand, 13:13:09) * generic-registration -- Merged and needs testing, not enabled by default (fabiand, 13:15:08) * generic registration needs more discussion, which will hopefully take place on the devel@ ml (fabiand, 13:17:01) * Engine part of generic registration is merged. (fabiand, 13:18:09) * rbarry to also discuss how the migratoin to the genric-registration can take place (in the TUI, and AI) (fabiand, 13:26:21) * ovirt-appliance -- Pushed to gerrit and announced (fabiand, 13:26:46) * needs testing (fabiand, 13:26:49) * Feature Status (ovirt-node-3.1) (fabiand, 13:27:57) * Considering to release ovirt-node-3.1 with all 3.5 features plus some additional before 3.5 TestDays (fabiand, 13:29:59) * ACTION: Node team to review and merge pending patches (as long as the patch is in a good shape) (fabiand, 13:31:19) * Other Items (fabiand, 13:31:33) * Some patches in gerrit are pending and -1'ed - because they basically go into the blivet direction, but we also consider anaconda, they are on hold (fabiand, 13:33:33) Meeting ended at 13:34:56 UTC. Action Items ------------ * Node team to review and merge pending patches (as long as the patch is in a good shape) Action Items, by person ----------------------- * **UNASSIGNED** * Node team to review and merge pending patches (as long as the patch is in a good shape) People Present (lines said) --------------------------- * fabiand (125) * rbarry (21) * bkp (12) * ovirtbot (5) * doron (3) * doron_afk (1) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot

1 0

[oVirt 3.5 Localization Question #1] "Permissive"
by Yuko Katabami 17 Jun '14

17 Jun '14

This is a multi-part message in MIME format. --------------000200000508080200080403 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello all, I am a Brisbane-based translator working on oVirt 3.5 localization project along with 5 other translators, each specialized in a different locale. Our localization cycle is just kicked off and I would like to post our questions to this mailing list, just as I did for 3.4. It would be greatly appreciated if you could help us by answering questions, so that we can ensure accuracy of our translations, based on the context. Here is our first question. *File:***LocalizedEnums* **Resource ID:*** SELinuxMode___PERMISSIVE* **Strings:*** Permissive *Question:* Could someone explain to us how this appears in the Admin Portal? (we currently do not have a demo environment and cannot check it on the screen). Translators usually leave SELinux modes untranslated as they appear in the command line in English, however this string starts with the uppercase letter "P". We just wonder if this is used as descriptive or it refers exactly the "permissive" mode as shown in the terminal. Kind regards, Yuko Katabami --------------000200000508080200080403 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 text="#000000" bgcolor="#FFFFFF"> Hello all, <div class="moz-signature"> I am a Brisbane-based translator working on oVirt 3.5 localization project along with 5 other translators, each specialized in a different locale. Our localization cycle is just kicked off and I would like to post our questions to this mailing list, just as I did for 3.4. It would be greatly appreciated if you could help us by answering questions, so that we can ensure accuracy of our translations, based on the context. Here is our first question. File: LocalizedEnums Resource ID: <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> SELinuxMode___PERMISSIVE Strings: <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> Permissive Question: Could someone explain to us how this appears in the Admin Portal? (we currently do not have a demo environment and cannot check it on the screen). Translators usually leave SELinux modes untranslated as they appear in the command line in English, however this string starts with the uppercase letter "P". We just wonder if this is used as descriptive or it refers exactly the "permissive" mode as shown in the terminal. Kind regards, Yuko Katabami </div> </body> </html> --------------000200000508080200080403--

2 1

Announcing oVirt.js prototype
by Vojtech Szocs 17 Jun '14

17 Jun '14

------=_Part_23610907_1521630269.1403011303574 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hello everyone, in past few weeks, we've been working on JavaScript SDK for oVirt Engine. Today, I'm happy to announce the first prototype called oVirt.js :) Attached, there's an "sdk-testdrive" UI plugin which: - bundles oVirt.js prototype [ovirt.js] - contains test code for DataCenter object [plugin.js] To install this plugin, simply copy (or symlink) sdk-testdrive.json file and sdk-testdrive-resources directory under /usr/share/ovirt-engine/ui-plugins. Following is a quick recap of test code exercising oVirt.js. To add new DataCenter: // Obtain DataCenter resource collection. // Resource collection is a handle to work with RESTful objects. var dcColl = ovirt.api.datacenters; // Obtain "add DataCenter" operation. // Operation is a reusable, uhm, operation, backed by HTTP request. // You can run the same operation multiple times, if necessary. var addOp = dcColl.add({ name: 'test-dc', local: false }); // Register result handler and run the operation. addOp.success(dcAddedCallback).run(); // Example of operation result handler that receives a single resource. function dcAddedCallback (dc) { console.log('Added: ' + dc.data().name); } In dcAddedCallback function shown above, "dc" is a resource object, representing a handle to work with RESTful DataCenter object. It provides access to underlying resource data: var dcDataObj = dc.data(); // Get var dcName = dcDataObj.name; var dcDesc = dcDataObj.description; // Set multiple properties at once ... dc.data({ name: 'test-dc-updated', description: 'test' }); // ... or one by one dcDataObj.name = 'test-dc-updated'; dcDataObj.description = 'test'; It also gives access to nested collections (if any) and supported actions (if any): // Obtain Cluster resource collection for given DataCenter. var dcClusterColl = dc.clusters; oVirt.js is currently only 445 lines of code, yey :) we're not using any code generation at this point, we're simply relying on HATEOAS [1] principle of REST and dynamically augmenting resource objects with nested collections and supported actions, which are part of resource representation. [1] http://en.wikipedia.org/wiki/HATEOAS I feel we'll eventually come to a point where code generation can be useful, but for now, we're trying to keep things small and simple. oVirt.js currently uses Lo-Dash library [2] containing various utility functions. I think that Lo-Dash is great because it makes working with JavaScript a bit easier. [2] http://lodash.com/ Overall, oVirt.js will be self-contained, which means there will be no additional dependencies from JavaScript perspective. Using oVirt.js in HTML page will be as simple as this: <script src="ovirt.js"></script> This means that (build-time) dependencies such as Lo-Dash will be inlined into resulting oVirt.js build. We're also planning to provide minified version + Source Maps for better debugging. oVirt.js is planned to be usable NOT ONLY in web browsers. In fact, there's "ovirt.svc" namespace containing services used by oVirt.js API implementation. You (or any 3rd party extension) can override these services to achieve SDK portability for given runtime environment. In other words, I'd love to see oVirt.js used also with Node.js :) Finally, an important thing to mention - oVirt.js requires AT LEAST ECMAScript 5.1 compliant environment. All modern browsers support ES5, including IE9+. Unfortunately, IE9 doesn't support ES5 Strict Mode, but that's not that big of a deal. I'll send some more emails outlining implementation design and also how to manage source control & distribution of oVirt.js. Regards, Vojtech ------=_Part_23610907_1521630269.1403011303574 Content-Type: application/x-compressed-tar; name=ovirt-js-sdk.tar.gz Content-Disposition: attachment; filename=ovirt-js-sdk.tar.gz Content-Transfer-Encoding: base64 H4sIADVAoFMAA+0873PbNrL9nL8C5w9H+VWm5F9xx4l749pO67ukztjOzZvJZDoQCVmMKUIlSDu6 nv/3t7sASYAEJaf1tL13oWcsiVzsLnYXi90FQBXfbhVCFXGe3ImtXChZ5pFQI3mX5EX4UX31BNd4 PH6+t8fgc/tgf2x/4rUHv56z7Z3dvYP9g93d8S4b74x3t59/xcZPQXzdVaqC58DKnfqXjFZ0d91z 3RlWf/6HXKMRk//UqmaLXBayWC5E+AxuX4qfywQMgp2dvDm+ivJkUbD9cJtFcr5IE54VTGRgJDKb i6w4xBZsVhSLw9Ho/v4+FNGcbyVZIfKMF4nMeBrK/GZEt3ee74wA0wjbnJR5Du3TJcsreq/l1ilX M5Ymk5znSwd1KmN4FAIPo2fUXGYFTzJWzAS7Ov0Hu0+KGfwMyHwDdpPKCU/ZHc8TPkmhX/CN0TN2 xH55eEE4zj4tpBJMifwuAdNnpRIxmyzZ8dtzlkBfBXaQOkFyOePRrAJmaibLFKAF4xmTk48iKkBA xFOS3UCfSoWE2VwUMxkrQnBVEYpFlPIciFEHEsUyPhdqwQHvjN9BozItEqDPcpkKpeWwHTLxKVEF Yq85joA4sCDvRJ4ncSwAnWTAZiLutFgWMi/4JEmTYsmmMmc3MNgzlpdZkcyFrUeisbOCBgmHZzHL xH3nIQfaJDqkKT4VIlMgNcWAYpQmgF49035F3UWggMG0zCKUKxtssl+eMbiCEjVR5ElUBKAdvIUq qwkZreF94PSH6+u3tSqwX0pksZb7zyU4NYVyyMVcFlq9Imd3CdfNyNgjmYYVsmvUgKtv7K1i//vm 9Q9gfZcaZ6VlVS5Qqrq/92LCJrm8ByJKI6w4DtFwkW26a0hdAZuaC8Noh8/QBg8Qx1ue87kK1lmc g3WBbQSMQTAeCx/bYoE2yOBQN9C/kAvo8RAMc8rB9kh8wfdn10G7dZmn0PTd5WuEQKFbHXGbi/kC bA41CswNYhmVKF024aDnd5fnm23MM8Fj4Bewd/sGFpUb7RkwHy3dro13IuMlIOXZEgwqLYWrP1fF IfWoMk6XRlamqaMbmV2VESjaVU3dGtsk2Z28Fex+BmPO0Q+5UoE8KI1jCtiXbABTUlHCqJKxYDvj 8WbYoniW5zL/FfSmPEmBmINfguvMwf2ANbmkUAiHDd5BY4RDVncavxI3m5aFV6P20ywHy0dH4cp3 sGmGsD0keJYUyb8EML8oCxU6zxvSgM/68e9/N+6guoBoKLMc7GOJ3RQR9OxGQLuus7GvZMoG2JQa XmFDdnR0xPZ8sFb/jBgAPTY2cv32CEXJ/vpX++ZLtjset3i1+n+udcYX4JcWMFsVOAdkcQq6qRgP vW0N4xUjQPSnMFGvTJtBranNvp7gVUMZGagFuG1xDQMOVOVr8MBECiMYif9lJXVtHKtpE8ygkVUf zc5d907bEiiGUTKFObDHK4YdkzWO0Lay0NwDYyNf+KLTCLyh2wJvILgH1jguF766aey53QZ9l9uA 7gA0eqNur89xKKEF4dAzvQ67g2QhsoHu2xC7MGRFXgrP0DzPorQETxFBqAK+O+GpQn81Y1xpwfKy mMG4hQl4rqdNjA8iKW8TmD0htolyqdSWSoCjamLusoOR24lF4YjY6XJzvFiYYBF1aSTnorugGSC8 FUs1MACbIXCHkZsVc2C05TNMFLmeI44q/O8R9gOat3MjLOQVzWwDj8mSPYvC+LwfqB3RHBrsZCGt hg8e+b+CqJjJ6ZSC3F51orseoF1YGPX4qMZFLooyz+rI5MWzh03yxE0IXBYYIibrY+B3WZrcNiHz 0GoJAS2MIkwPMAZVCuJIisrZfZ5QRDmXACGm0yTCiJD9nd9xk13gfBSaCBERuiFiRWxNqNhw4saK 74om/AVL5sSLjhWwu8RZ8imBaJW4jQUMDzDGCG0NnEhJTMxpOknUXMu/phWapq04D7ITYLCEKKaJ 1SxStWdXNGJqkojQmfHVQkRrIz97AGZCYCSOfa0Aqcv2JIKINdst1DzP+dJDYIxxPGmvxb2LE7rx +RhNgEgDA3wGeYHpsgrlE0ySesVDgXttJwuRoxzgjkxTeU85TAEsuREwpFEkEQEyWAaGtSEQW4C2 kTg2m1FypgRAgo3wuaxtxMG10+CCMKrowcajooRU1AxC6qiDZTcEP3pDwbHFUssY0axzPaeBdnM5 r7OfOnV0kO6FGFGAvzT2CfJp8ThJdMYUYAIaUMBvAzjY9sOKfT8MELEDRrTaoaGMQfRC+YLE+dIM 1PYDJGGPYYuTlcEikoV29OGZUOuRar4AyPsPLgiyCgD0YR73BRaOZnAQ2zoMO1g/YxaaL82kc1S7 WX1j/YRx7FV5v65Dj4A8nE4zH5/TLIx4mg4Q05Dp/0bzy3WTm7EmbGRNWsNnttW90b6m9mQKayM0 oPJJUmCBiMlFyw3hoLnQN22DbJjzGaLBYkwnrH76cgyUsQ54KygsK9yIAoLKkaKPhiyN4LnIb8SW zLbgKThF7ILMXbkjd2HDRDO3TKFrc34rvhfFlSjeIKZXmemMgX+cYJ1ooDUl3sv8FqVK3LY8u8NK e457w2+d/BP8HGlHGXnQqDAykfW8pSOgx4gGp1GwLz0VKKyIwTdXuM10yPMbXV+4T9JUY8ZCD8wJ FBHIqfYqBjrJaAhAI1E7M2LX8XIOKxeYLd8nWCRpNySSE2Eai7hp11Fe1yg1rrZZGj4a4HIRwzzT l79i6qVj3wqwL+/6KSTZDDRZCN80uD/v8hpTbVQ6EfSTqVoSFU/bdvrmPniMpRqf0LbTylX4bTUW YsGiVGYYVkN0RUse4B999hJo0QTaWMh6dEvLTjAup5uNypHECd46zmJSujMxEsFa6h5fpEkcgZ7o 2ylgM61aOjIcVPokaI86vYlALS7KBOrCrJsSYAIAYxm7OMdCOwwu8LgLmegAHwu9Vcc4qqiK3/ki ccP3mtqa+L2en9vB9YsapNFuR+MN0LTrRRt76k4qbqzGLs+urqdlyqoFMYha01RYZZjG36lLA3NS g/RNNeTiYSg41agkbty4f/yj/7gAm+S6pmJMvmNiJuDqDkVZTYXmy7ADgaWFN1QKONRFji4IKBQX W8Sn4i0vZod6knRvsq9ZMArgP3Sp0x6m6kxhZH5JXtweD2CsvM9TWSKo5DzoryUhpkOHFLU4hdua ir+w5HF8Ld+0aQ+mF06Acqk5lJWCcFikmPXWi6nsJpflQifUtM7Ta1UkKDQSQmBbyX+AhXQ0bCvt GFPA3yRTHseN4OrhqqUaoHLrmZgc9aPEjDiPWpb4JxuNby+ufMJGmO9kvDxkf7+6+DHU+TOkzNrM /58PPw1ROfPrih7L+X2jdCRILh7nmcmyeeDEDM26iY/rrnBq+FhMk0y81cHC8lLw+CLDtRsMH36k Kh9++yfGuW3hmvqki8HYXtPcV5gEZIcN3q6WscaG682gXg5hWRcgktk0uSlzDYQV1i6MyCCGtiA6 OVyjpK5YchGXkXidZLeKDaju0zOM6Fmowa0wQcf4Q/Cg2a3PKPXz9/gYGqeYHtP3WS6mXTMytHSj VjIKEu7pTBUpBkkcsAwyk0qsdnzn0/4AWwzJ8sIk3nzhQYl8fi5SamPQ4vcW4sb+MSYVOm7LhELf 6HGBVp5MS+vlpAlctN6ONCmUa7s80seig0UFQ9sOBl0S9niOBS6BNiQf0blm7Zb7usSdvtDACg0g lvDt36G2s0f2knu7x91+1ViM8SG5tss6w5VsmKk8DguLegG4qMDOMEwBdbrOiXVmXIYT1KabBdXE bcJDQ9TUbU2RFiJhLFenwnIKVYK0dIWOqy0gbXvtBUm/cICQkuYL9IIwYSqyG4gcca11e5P9Dfv1 Hh+8H3/4wA7d2ptd+XOYt4aQRYA+ISWmz0H9BKk0YF0Sl7XP8Ei6pVdNYs4Xg9XT6eOm0c+bPh3n telYmNce7PSknZhU/OnSH3yY6OW9uWMV1IbejOfDZtvET+R8UcK4NuvvE1HcC9yYdC/rnMs2cBYn 06lniQATT3wkcpFFwtqsI5wWVfEFF0SxFoJlGsFwS5U0HLRGSqTZO0UcA5knNwnkr0M2l4A1EbEt HDJchGsVo1sllwrJZrUKbu7XKHvCABoqNZCn7goAfcuU1VDEbnj2FtDyfMVXOOPq4j6r4w1E2xf2 YYEz1nu8KhJgHErpdSZwFQZngGu/EhedsAa81EUSSy/+LQsIgIMcJ++q4/T7M8tLbj0ucg0OI796 F1vdiVxEZa6SOwHMovnpSsl6lm1BA9eW9dR6px4M3Q71VNRQLzbGVdsjbGG56vZBr90j0Vc/StTZ zyVPB0iOIiPwkjSYDokDy9X4NNJB4xtRNcLqVqc+9evrM71Fmb5SDDr6zuSrCmm2Yxq3UlNtrZ1W cxnkiqajpzTLd+NhXAG/yXQukVsOva1yon/EbBDf6pVNrlUfpBmid6HC7egTLFegE744vQCbFHdY cUc8qBvLZ2AJdQDsoRcuGE9pbxUzEmW0ggz2QAy5gnYnOsrUjXxWrYUYATQ2ZStb74lJV4QOjaZo 8gvb8uwpSxgP4hQcWlUGA/KnLee8ffdZFQaf8zulwUAie7rig6WRFUHRr1q1+E2VKJOxrFK5AfnT qvz07PXZ9dlKrQe/PASPFtOxWfauxxa5kV+XhNYJaOtuyx3a4ZML+djNXqipepHdHyp7ovROIdyh rfGtDNTXy+1R+W0tJr5ePvzzBNNj92ZfsT48oFGa7UwmMz7VVdisb2h0hN6w0SDorb/i9USjBa/1 Iwavx9RiKzivt2w65nGMeLXtifcaEl4PbX/30G9cND+bkkkhF1spzNRpKxKwpmraGSczUG6Cudba hPIxaWS1MOlThHdFiZiCBKr+QRUvq4trk9JuKno+ZcE0CzAdbDYqDO0ZorXH2k0s6hQ1k1ty0QKt JQPh1KvsIv9RAkhrq4wVHdc7oxHibxDOQDj8U5hBozbT3RC43ofphsD1EK15r09u0cGRoNo/1ImR 6xFkB8m0b6eV/dbbwynkbLhtntMWbutpNxBGViosA2eHedsr50vPiIVuveW5ouiNmuKqNA01b2Ks K77AEIEssKVL1JMtu0sJ9V6TaqccJG2ZQPZ5vuwSrYoBtYLJgFuBT2++XbPra2Vq4t5VEl8nzFGC xnWbwyUMc/QJj2673Df7/720HqBpEc3YwLv1pPI0+rwCE2QK2q+kyw40eBglUxGm8mYQaLO5nyVY VgQlmV0+pCbwt+xr1t7w0ERuvtUHNDKN05xxOZGxb3Z7JL8Or5fuIRo9UVsHaZBbi2hfInIpbhJF m6EeoR+KJVU99prpsgJt980eqZZHauC96X9rn1g7Au4wrEXWw64wruAxzFZu46lYLfVmnJrTYX0i 8JGn7agHOaBZdV4IfREkrLjTfeU5BPe8Bw1tNNAf+k97VKcLAszaF0WAMVKAO3iTiPoz+qhkFvS0 ock0K7aulwvxeS1fJSkomNrApFxtQhxAuEgPtBtS3dpCWwqrTtY4Z7g8211NjFVLSQdd3ZCpzNPD FpcCIq1MfMeVeJenOAq7W1M8iY7u/GF9lLADMaFwrmYIo7t25NUWCB3s7D2mMV8SIn1Uwz5OZ82N w8aH9a55O9GYNYn/xqp+jekDgOjQoRVLUfJBG7ssnA29OqLuDJcz0lB16vP1kLynLAsIY2CyS2h3 p0rxZLfT0lHsoQ5nDkej7Z2DcAx/24ffjL8ZtwJyPDCTcixTx2T6uFNwJvQhR8m0QZv5VhFDMdMH ffNA4eEBKnM7KReJ3B4IZnW9Xb30CvbDZrPrrEr2cE8dTR+eoLyTIlezVR39kfEnWVJYexcwhI0T FeEJcAhy09RCbWEkhNgcA+sId8+QZ1qb+rYj9UC/HmJL62cEj0cWRl01qJORKnxeJNY+Q9yXBwB/ 9NsPvlyq5/0fT0ljPB4f7O/3vf9Dvy9je2d3n+B2dth4+/n+wc5XbP8pmei7/svf/+HoP8Qg4elp rH7/y7h+/8v4+Q783wb97+893/ny/pff49JOfgOLTRuHbMMxhw09s25AyIXPFmkJ7n7kgIz0TYhr 5mkFXjkRnCs6OBsXs/Hs4Yv//8OvPv9v6fU301g3/ncPdsz7n/Z2xjt7+P6ng+cHX8b/73G9/Ess I3znE0NVf/vsZfUBWdG3NJ5fQmrGcVdFrkRxtFEW061vNgBipEFeYppkIJU+x63y6GhjNIri7KPC BeoynuJ7juitTfwj/zRKk4mqXuX0UY12wr1wu/m98e3LkcbkQVu9l2wlkDFeF+rlSHMKjFMX/2jJ /zmuNeP/SV4At2b87+4e7Lnx3854b3f/y/j/PS5aaciSOccTJ0nE3p0zrXo2kbJQkJ0v9FvT9N1j yv6x6JMVYX1rEDhmhC+1qJ+FuakfmnwSEs0Cbl8JSrOPI326/7Cn3IY4TxHnoK5EPLSw83hZvcbi GrdYd19nR6sonOUJvl6iSZor1A3FZhc7z2I5P4d09kbkbDBPsiFkyZ88xZU3EOSE01TKfEBfdUvA +D/QjH9iWwwas69xc+vX+LWzOHUxoY22uEB4Qvlz/7EV2nUUYYYOOqiP2dnJvFVrMNv3GrxDUJve wUdrbFzh0iCg1ydoqtUkrLyKzBxe1cTwlIxVDMBQ8ZAFKL6tONrCsrcjrsF4yLZhCFjLnamMeGpX TR42q6r2II6O8a1xJ1XVF6uv9QuimtMWLhSDZrYynEI9QerVg1ivIQ42Q1rmbgpqaPa4C21pCSjA N/Lp2cLZ7NUgsR5jefUd7euJGS+ImBE3mGpYyPOri+6rYfAkq94LZKulKnhjFVyftFTALAviKOjs SQRe9G6igS1Bw0hHhpalWZJsQa+UpYFdL81TveGlv19UgNfbTpw1PE8P9eYZp4ca/WN72IKGHtKN S0O2t7emnemt08a8moo+RGcQv8bjelh2a/qvnCGE3tXpkMImjzD7Fhwq67h9qsbc8mzuiDtvOnD6 q3GvUa7p4veisJ0UuIzz09YLLnRXQduDBlkS273+XhbfLc/9atR+oU+lrZYrjRZgNX8revbwJfv8 cn25vlz/5df/AadgwuoAXAAA ------=_Part_23610907_1521630269.1403011303574--

1 0

[VDSM] [REVIEW] Profiling patches
by Nir Soffer 17 Jun '14

17 Jun '14

Hi all, I have few easy to review patches adding useful features to vdsm profiler. Please review: - http://gerrit.ovirt.org/27786 profile: Test profile decorator format - http://gerrit.ovirt.org/27787 profile: Support yappi builtins option - http://gerrit.ovirt.org/27816 profile: Support yappi clock types - http://gerrit.ovirt.org/27894 profile: Allow disabling threads when using the decorator Thanks, Nir

2 1

Fwd: [libvirt] KVM Forum 2014 Call for Participation
by Brian Proffitt 17 Jun '14

17 Jun '14

----- Forwarded Message ----- From: "Paolo Bonzini" <pbonzini(a)redhat.com> To: "Libvirt" <libvir-list(a)redhat.com> Sent: Monday, June 16, 2014 12:08:22 PM Subject: [libvirt] KVM Forum 2014 Call for Participation ================================================================= KVM Forum 2014: Call For Participation October 14-16, 2014 - Congress Centre Düsseldorf - Düsseldorf, Germany (All submissions must be received before midnight July 27, 2014) ================================================================= KVM is an industry leading open source hypervisor that provides an ideal platform for datacenter virtualization, virtual desktop infrastructure, and cloud computing. Once again, it's time to bring together the community of developers and users that define the KVM ecosystem for our annual technical conference. We will discuss the current state of affairs and plan for the future of KVM, its surrounding infrastructure, and management tools. Mark your calendar and join us in advancing KVM. http://events.linuxfoundation.org/events/kvm-forum/ Once again we are colocated with the Linux Foundation's LinuxCon Europe, CloudOpen Europe, Embedded Linux Conference (ELC) Europe, and this year, the Linux Plumbers Conference. KVM Forum attendees will be able to attend LinuxCon + CloudOpen + ELC for a discounted rate. http://events.linuxfoundation.org/events/kvm-forum/attend/register We invite you to lead part of the discussion by submitting a speaking proposal for KVM Forum 2014. http://events.linuxfoundation.org/cfp Suggested topics: KVM/Kernel - Scaling and optimizations - Nested virtualization - Linux kernel performance improvements - Resource management (CPU, I/O, memory) - Hardening and security - VFIO: SR-IOV, GPU, platform device assignment - Architecture ports QEMU - Management interfaces: QOM and QMP - New devices, new boards, new architectures - Scaling and optimizations - Desktop virtualization and SPICE - Virtual GPU - virtio and vhost, including non-Linux or non-virtualized uses - Hardening and security - New storage features - Live migration and fault tolerance - High availability and continuous backup - Real-time guest support - Emulation and TCG - Firmware: ACPI, UEFI, coreboot, u-Boot, etc. - Testing Management and infrastructure - Managing KVM: Libvirt, OpenStack, oVirt, etc. - Storage: glusterfs, Ceph, etc. - Software defined networking: Open vSwitch, OpenDaylight, etc. - Network Function Virtualization - Security - Provisioning - Performance tuning =============== SUBMITTING YOUR PROPOSAL =============== Abstracts due: July 27, 2014 Please submit a short abstract (~150 words) describing your presentation proposal. Slots vary in length up to 45 minutes. Also include in your proposal the proposal type -- one of: - technical talk - end-user talk Submit your proposal here: http://events.linuxfoundation.org/cfp Please only use the categories "presentation" and "panel discussion" You will receive a notification whether or not your presentation proposal was accepted by Aug 20th. Speakers will receive a complimentary pass for the event. In the instance that your submission has multiple presenters, only the primary speaker for a proposal will receive a complementary event pass. For panel discussions, all panelists will receive a complimentary event pass. TECHNICAL TALKS A good technical talk should not just report on what has happened over the last year; it should present a concrete problem and how it impacts the user and/or developer community. Whenever applicable, it should focus on the work that needs to be done or the difficulties that haven't yet been solved. Summarizing recent developments is okay but it should not be more than a small portion of the overall talk. END-USER TALKS One of the big challenges as developers is to know what, where and how people actually use our software. We will reserve a few slots for end users talking about their deployment challenges and achievements. If you are using KVM in production you are encouraged submit a speaking proposal. Simply mark it as an end-user talk. As an end user, this is a unique opportunity to get your input to developers. HANDS-ON / BOF SESSIONS We will reserve some time for people to get together and discuss strategic decisions as well as other topics that are best solved within smaller groups. This time can also be used for hands-on hacking sessions if you have concrete code problems to solve. These sessions will be announced during the event. If you are interested in organizing such a session, please add it to the list at http://www.linux-kvm.org/page/KVM_Forum_2014_BOF Let people you think might be interested know about it, and encourage them to add their names to the wiki page as well. Please try to add your ideas to the list before KVM Forum starts. PANEL DISCUSSIONS If you are proposing a panel discussion, please make sure that you list all of your potential panelists in your abstract. We will request full biographies if a panel is accepted. =============== HOTEL / TRAVEL =============== The KVM Forum 2014 will be held in Düsseldorf, Germany at Congress Centre Düsseldorf http://events.linuxfoundation.org/events/kvm-forum/attend/hotel-and-travel =============== IMPORTANT DATES =============== Notification: August 20, 2014 Schedule announced: August 29, 2014 Event dates: October 14-16, 2014 Thank you for your interest in KVM. We're looking forward to your submissions and seeing you at the KVM Forum 2014 in October! -your KVM Forum 2014 Program Committee Please contact us with any questions or comments. -- libvir-list mailing list libvir-list(a)redhat.com https://www.redhat.com/mailman/listinfo/libvir-list

1 0

Question/thoughts about our engine logging framework
by Yair Zaslavsky 16 Jun '14

16 Jun '14

Hi all, During my recent work on AAA, I was suggested by Juan Hernandez to use slf4j logging framework which serves as a facade for other logging frameworks (including java utils logging which is now used by jboss), log4j and others. I have accepted Juan's offer, and then when looking at our LogFactory class I have noticed we use commons logging. Several thoughts/questions - A. Why continue use our own wrapper as slf4j is already a facade. b. I think we should move cross java code to slf4j. What do you think on this point? Some reading material - http://javarevisited.blogspot.com.au/2013/08/why-use-sl4j-over-log4j-for-lo… http://stackoverflow.com/questions/3222895/what-is-the-issue-with-the-runti… Yair

6 14