Hi Adrian, I see your point, we can consider this later on, for now there are some gaps we need to close with API/infrastructure. You mean API for plugins to log messages so that WebAdmin can collect/send them to Engine? (Client-side logging in WebAdmin is disabled in production mode, in long-term we'll implement support for collecting client-side logs via HTML5 local storage, and sending them to Engine so that they can be stored in JBoss log directory.) Wiki page: http://www.ovirt.org/Features/UIPlugins Discussion page: http://www.ovirt.org/Talk:Features/UIPlugins You can also request new features on engine-devel mailing list (I highly recommend subscribing to that list, since all important UI Plugins updates take place on that list). Regards, Vojtech ----- Original Message ----- From: "Adrian Gibanel" <adrian.gibanel(a)btactic.com&gt; To: "ovirt-users" <users(a)ovirt.org&gt; Cc: "Oved Ourfalli" <ovedo(a)redhat.com&gt;, "Christopher Morrissey" <christopher.morrissey(a)netapp.com&gt; Sent: Friday, January 25, 2013 1:09:31 PM Subject: Re: [Users] Community feedback on the new UI-plugin Framework ----- Mensaje original ----- Was there finally any video recorded of this workshop? 5. Everything should be a plugin. One trend among platform design is that everything should be a plugin. I'm not sure how it will go with oVirt but the idea is that: * Hosts tab * Virtual machines tab * GlusterFS volumes tab * Disks tab are each one of them a plugin. You should remark that as a side-effect you win two things: * People can check how standard plugins (you could make them not-uninstallable and not-being-able-to-disable) to learn how to build their own plugins * Your plugin system would be better because it would need to be improved to support all the current default plugins capabilities 6. Plugin logs Maybe an standard way of saving plugin logs through standard ovirt-engine logs and specific plugin logs. 7. Wiki Page Is there any wiki page about this UI-plugin framework so that I can add a New ideas or new features requests page link there and add these same ideas? I think that's all. I will, for sure, take a look at them. -- -- Adrián Gibanel I.T. Manager +34 675 683 301 www.btactic.com Ens podeu seguir a/Nos podeis seguir en: i Abans d´imprimir aquest missatge, pensa en el medi ambient. El medi ambient és cosa de tothom. / Antes de imprimir el mensaje piensa en el medio ambiente. El medio ambiente es cosa de todos. AVIS: El contingut d'aquest missatge i els seus annexos és confidencial. Si no en sou el destinatari, us fem saber que està prohibit utilitzar-lo, divulgar-lo i/o copiar-lo sense tenir l'autorització corresponent. Si heu rebut aquest missatge per error, us agrairem que ho feu saber immediatament al remitent i que procediu a destruir el missatge . AVISO: El contenido de este mensaje y de sus anexos es confidencial. Si no es el destinatario, les hacemos saber que está prohibido utilizarlo, divulgarlo y/o copiarlo sin tener la autorización correspondiente. Si han recibido este mensaje por error, les agradeceríamos que lo hagan saber inmediatamente al remitente y que procedan a destruir el mensaje . _______________________________________________ Users mailing list Users(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/users

Hi Oved, replying late, thanks for sharing the feedback! Glad to hear this! In fact, a minimalistic UI plugin is just one JSON file (plugin descriptor) + one HTML file (plugin host page): http://www.ovirt.org/Features/UIPlugins#UI_plugin_cheat_sheet Yes, this is planned long-term, e.g. we can have an API for creating table-based main/sub tab, with functions that allow adding columns, setting data or adding custom action buttons. On the other hand, I'm also planning to prototype another approach for providing custom UI content - using popular JavaScript frameworks like Backbone/Underscore/jQuery to construct UI on the client (via plugin code) instead of using contentURL/iframe approach. (I'll post a separate email on this later on.) Actually we plan to have WebAdmin dialog that lists loaded plugins, with the option to enable/disable them or view their current status. As for installing/removing plugins, this requires root privileges since plugins are meant to be installed/removed as RPM packages. Not sure if a separate tool for this is necessary. Very interesting ideas! Public configuration entries could be changed via <plugin>-config.json or in WebAdmin, private ones would be hidden/read-only. Regards, Vojtech ----- Original Message ----- From: "Oved Ourfalli" <ovedo(a)redhat.com&gt; To: "ovirt-users" <users(a)ovirt.org&gt; Cc: "Christopher Morrissey" <christopher.morrissey(a)netapp.com&gt;, "Vojtech Szocs" <vszocs(a)redhat.com&gt; Sent: Friday, January 25, 2013 2:41:40 AM Subject: Community feedback on the new UI-plugin Framework Hey all, We had an oVirt workshop this week, which included a few sessions about the new oVirt UI Plugin framework, including a Hackaton and a BOF session. I've gathered some feedback we got from the different participants about the framework, and what they would like to see in the future of it. 1. People liked the fact that it is a simple framework, allowing you to do nice extensions rapidly, without the need to know complex technologies (simple javascript knowledge is all you need to know). 2. People want the framework to provide tools for adding UI components (main/sub tabs, dialogs, etc.) that aren't URL based, but are based on components we currently have in oVirt, such as grids, key-value pairs (such as the general sub-tab), action buttons in these custom tabs and etc. The main reason for that is to easily develop a plugin with an oVirt-like look-and-feel. Chris Morrissey from Netapp showed a very nice plugin he wrote that did have an oVirt-like look-and-feel, but it wasn't easy.... and it required him to to develop something specific for the plugin to interact with, in the 3rd party application (something similar to the work we did in the oVirt-Foreman UI-plugin). 3. Support adding tasks to the system - plugins may trigger asynchronous tasks behind the scene, both oVirt and external ones. oVirt tasks and their progress will be reflected in the tasks management view, but if the flows contain external tasks as well, then it would be hard to track through the oVirt UI. 4. Plugin management * The ability to see what plugins are installed... install new plugins and remove existing ones. * Change the plugin configuration through webadmin * Distinguish between public plugin configuration entries (entries the user to change), to private ones (entries it can't). I guess that this point will be relevant for engine-plugins as well (once support for such plugins will be available) so we should consider providing a similar solution for both. Also, Chris pointed out that it should be taken into consideration as well when working on supporting HA-oVirt-engine, as plugins are vital part of the oVirt environment. If you find the feedback above true, or you have other comments that weren't mentioned here, please share it with us! Thank you, Oved P.S: I guess the slides will be uploaded sometime next week (I guess someone would have asked it soon... so now you have your answer :-) )