- Devel - oVirt List Archives

Re: [Engine-devel] Mom Balloon policy issue
by Adam Litke 10 Oct '12

10 Oct '12

Thanks for writing this. Some thoughts inline, below. Also, cc'ing some lists in case other folks want to participate in the discussion. On Tue, Oct 09, 2012 at 01:12:30PM -0400, Noam Slomianko wrote: > Greetings, > > I've fiddled around with ballooning and wanted to raise a question for debate. > > Currently as long as the host is under memory pressure, MOM will try and reclaim back memory from all guests with more free memory then a given threshold. > > Main issue: Guest allocated memory is not the same as the resident (physical) memory used by qemu. > This means that when memory is reclaimed back (the balloon is inflated) we might not get as much memory as planed back (or non at all). > > *Example1 no memory is reclaimed back: > name | allocated memory | used by the vm | resident memory used in the host by qemu > Vm1 | 4G | 4G, | 4G > Vm2 | 4G | 1G | 1G > - MOM will inflate the balloon in vm2 (as vm has no free memory) and will gain no memory One thing to keep in mind is that VMs having less host RSS than their memory allocation is a temporary condition. All VMs will eventually consume their full allocation if allowed to run. I'd be curious to know how long this process takes in general. We might be able to handle this case by refusing to inflate the balloon if: (VM free memory - planned balloon inflation) > host RSS > *Example1 memory is reclaimed partially: > name | allocated memory | used by the vm | resident memory used in the host by qemu > Vm1 | 4G | 4G, | 4G > Vm2 | 4G | 1G | 1G > Vm3 | 4G | 1G | 4G > - MOM will inflate the balloon in vm2 and vm3 slowly gaining only from vm3 The above rule extension may help here too. > this behaviour might in the cause us to: > * spend time reclaiming memory from many guests when we can reclaim only from a subgroup > * be under the impression that we have more potential memory to reclaim when we do > * bring inactive VMs dangerously low as they are constantly reclaimed (I've had guests crashing from kernel out of memory) > > > To address this I suggest that we collect guest memory stats from libvirt as well, so we have the option to use them in our calculations. > This can be achieved with the command "virsh dommemstat <domain>" which returns > actual 3915372 (allocated) > rss 2141580 (resident memory used by qemu) I would suggest adding these two fields to the VmStats that are collected by vdsm. Then, to try it out, add the fields to the GuestMemory Collector. (Note: MOM does have a collector that gathers RSS for VMs. It's called GuestQemuProc). You can then extend the Balloon policy to add a snippet to check if the proposed balloon adjustment should be carried out. You could add the logic to the change_big_enough function. > additional topic: > * should we include per guest config (for example a hard minimum memory cap, this vm cannot run effectively with less then 1G memory) Yes. This is probably something we want to do. There is a whole topic around VM tagging that we should consider. In the future we will want to be able to do many different things in policy based on a VMs tag. For example, some VMs may be completely exempt from ballooning. Others may have a minimum limit. I want to avoid passing in the raw guest configuration because MOM needs to work with direct libvirt vms and with ovirt/vdsm vms. Therefore, we want to think carefully about the abstractions we use when presenting VM properties to MOM. -- Adam Litke <agl(a)us.ibm.com> IBM Linux Technology Center

4 3

[Engine-devel] How to update vds_bootstrap.py file under two different directories in engine server?
by Shu Ming 08 Oct '12

08 Oct '12

Hi, I got a question about vds_bootstrap.py file in engine. How do I update the vds_bootstrap.py file after engine and vdsm-bootstrap packages were updated? I mean the file under directory "/usr/share/ovirt-engine/engine.ear/components.war/vds/". It seems vds_bootstrap.py was updated along with the vdsm-bootstrap package into another directory "/usr/share/vdsm-bootstrap" but not the directory "/usr/share/ovirt-engine/engine.ear/components.war/vds/". -- --- 舒明 Shu Ming Open Virtualization Engineerning; CSTL, IBM Corp. Tel: 86-10-82451626 Tieline: 9051626 E-mail: shuming(a)cn.ibm.com or shuming(a)linux.vnet.ibm.com Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District, Beijing 100193, PRC

1 0

[Engine-devel] oVirt GUI available in Japanese language
by Vojtech Szocs 04 Oct '12

04 Oct '12

Hello everyone, oVirt WebAdmin and UserPortal web applications (GUI) now support Japanese language, please refer to [http://gerrit.ovirt.org/8312] for details. By default, oVirt GUI is compiled for English locale only. You can customize this by using "gwt.locale" property: $ mvn clean install -Pgwt-admin,gwt-user -Dgwt.locale=default,ja ("default" locale maps to English, "ja" locale maps to Japanese) Alternatively, you can use "all-langs" profile to compile for all supported locales: $ mvn clean install -Pgwt-admin,gwt-user,all-langs Regards, Vojtech

1 0

[Engine-devel] oVirt UI Plugins Presentation
by Vojtech Szocs 04 Oct '12

04 Oct '12

------=_Part_4538700_1948709573.1349346221588 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit The following is a new meeting request: Subject: oVirt UI Plugins Presentation Organizer: "Vojtech Szocs" <vszocs(a)redhat.com> Time: Tuesday, October 9, 2012, 4:00:00 PM - 6:00:00 PM GMT +01:00 Belgrade, Bratislava, Budapest, Ljubljana, Prague Invitees: engine-devel(a)ovirt.org; iheim(a)redhat.com; ecohen(a)redhat.com; George.Costea(a)netapp.com; Christopher.Morrissey(a)netapp.com; Dustin.Schoenbrun(a)netapp.com; Ricky.Hopper(a)netapp.com; Troy.Mangum(a)netapp.com; Chris.Frantz(a)hp.com *~*~*~*~*~*~*~*~*~* Hi guys, let me invite you to a presentation on oVirt UI Plugins feature. In this session, you will learn about: * high-level overview of UI Plugins feature: main concepts, how it works * current state of plugin infrastructure, including updates from recent revisions (rev.4 and rev.5) * tutorial on writing simple plugin, providing insight on plugin lifecycle from plugin author perspective * few tips for plugin authors on implementing new plugin API features Here are the details required for joining the session. Intercall dial-in numbers can be found at: https://www.intercallonline.com/portlets/scheduling/viewNumbers/listNumbers… Intercall Conference Code ID: 7128867405 # Elluminate session: https://sas.elluminate.com/m.jnlp?sid=819&password=M.49FFA576F865467B73763A… Regards, Vojtech ------=_Part_4538700_1948709573.1349346221588 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html><body id=3D'htmlmode'><h3>The following is a new meeting request:</h3= > <table border=3D'0'> <tr><th align=3Dleft>Subject:</th><td>oVirt UI Plugins Presentation </td></= tr> <tr><th align=3Dleft>Organizer:</th><td>"Vojtech Szocs" <vszocs(a)redhat.c= om> </td></tr> </table> <table border=3D'0'> <tr><th align=3Dleft>Time:</th><td>Tuesday, October 9, 2012, 4:00:00 PM - 6= :00:00 PM GMT +01:00 Belgrade, Bratislava, Budapest, Ljubljana, Prague </td></tr></table> <table border=3D'0'> <tr><th align=3Dleft>Invitees:</th><td>engine-devel(a)ovirt.org; iheim@redhat= .com; ecohen(a)redhat.com; George.Costea(a)netapp.com; Christopher.Morrissey@ne= tapp.com; Dustin.Schoenbrun(a)netapp.com; Ricky.Hopper(a)netapp.com; Troy.Mangu= m(a)netapp.com; Chris.Frantz(a)hp.com </td></tr> </table> <div>*~*~*~*~*~*~*~*~*~*</div> <div style=3D'font-family: times new roma= n,new york,times,serif; font-size: 12pt; color: #000000'>Hi guys, le= t me invite you to a presentation on oVi= rt UI Plugins feature. In this session, you will learn about:= <ul><li>high-level overview of UI Plugins feature: main concepts, how i= t works</li><li>current state of plugin infrastructure, including updates f= rom recent revisions (rev.4 and rev.5)</li><li>tutorial on writing simple p= lugin, providing insight on plugin lifecycle from plugin author perspective= </li><li>few tips for plugin authors on implementing new plugin API feature= s</li></ul> <hr style=3D"width: 100%; height: 2px;"> <p= >Here are the details required for joining the session. Intercall di= al-in numbers can be found at: <a target=3D"_blank" href=3D"https://www.intercallonline.com/po= rtlets/scheduling/viewNumbers/listNumbersByCode.do?confCode=3D7128867405">h= ttps://www.intercallonline.com/portlets/scheduling/viewNumbers/listNumbersB= yCode.do?confCode=3D7128867405</a> Intercall Conferenc= e Code ID: <a h= ref=3D"callto:7128867405" target=3D"_blank">7128867405</a>#<b= r>Elluminate session:<a target=3D"_blank" href=3D"https://sas.elluminate.= com/m.jnlp?sid=3D819&password=3DM.49FFA576F865467B73763A1B6F57CC">https= ://sas.elluminate.com/m.jnlp?sid=3D819&password=3DM.49FFA576F865467B737= 63A1B6F57CC</a> <hr style=3D"width: 100%; height: = 2px;"> Regards, Vojtech </div></body></html> ------=_Part_4538700_1948709573.1349346221588 Content-Type: text/calendar; charset=utf-8; method=REQUEST; name=meeting.ics Content-Transfer-Encoding: 7bit BEGIN:VCALENDAR PRODID:Zimbra-Calendar-Provider VERSION:2.0 METHOD:REQUEST BEGIN:VTIMEZONE TZID:Europe/Belgrade BEGIN:STANDARD DTSTART:19710101T030000 TZOFFSETTO:+0100 TZOFFSETFROM:+0200 RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=10;BYDAY=-1SU TZNAME:CET END:STANDARD BEGIN:DAYLIGHT DTSTART:19710101T020000 TZOFFSETTO:+0200 TZOFFSETFROM:+0100 RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=3;BYDAY=-1SU TZNAME:CEST END:DAYLIGHT END:VTIMEZONE BEGIN:VEVENT UID:eddd3397-ed17-4be8-8aac-25f3da56732c SUMMARY:oVirt UI Plugins Presentation ATTENDEE;CN=engine-devel;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRU E:mailto:engine-devel@ovirt.org ATTENDEE;CN=Itamar Heim;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE :mailto:iheim@redhat.com ATTENDEE;CN=Einav Cohen;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE :mailto:ecohen@redhat.com ATTENDEE;CN=George Costea;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TR UE:mailto:george.costea@netapp.com ATTENDEE;CN=Christopher Morrissey;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION ;RSVP=TRUE:mailto:christopher.morrissey@netapp.com ATTENDEE;CN=Dustin Schoenbrun;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSV P=TRUE:mailto:dustin.schoenbrun@netapp.com ATTENDEE;CN=Ricky Hopper;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRU E:mailto:ricky.hopper@netapp.com ATTENDEE;CN=Troy Mangum;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE :mailto:troy.mangum@netapp.com ATTENDEE;CN=Chris Frantz;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRU E:mailto:chris.frantz@hp.com ORGANIZER;CN=Vojtech Szocs:mailto:vszocs@redhat.com DTSTART;TZID="Europe/Belgrade":20121009T160000 DTEND;TZID="Europe/Belgrade":20121009T180000 STATUS:CONFIRMED CLASS:PUBLIC X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY TRANSP:OPAQUE LAST-MODIFIED:20121004T102341Z DTSTAMP:20121004T102341Z SEQUENCE:0 DESCRIPTION:The following is a new meeting request:\n\nSubject: oVirt UI Plu gins Presentation \nOrganizer: "Vojtech Szocs" <vszocs(a)redhat.com> \n\nTime: Tuesday\, October 9\, 2012\, 4:00:00 PM - 6:00:00 PM GMT +01:00 Belgrade\, Bratislava\, Budapest\, Ljubljana\, Prague\n \nInvitees: engine-devel@ovirt. org\; iheim(a)redhat.com\; ecohen(a)redhat.com\; George.Costea(a)netapp.com\; Chri stopher.Morrissey(a)netapp.com\; Dustin.Schoenbrun(a)netapp.com\; Ricky.Hopper@n etapp.com\; Troy.Mangum(a)netapp.com\; Chris.Frantz(a)hp.com \n\n\n*~*~*~*~*~*~* ~*~*~*\n\nHi guys\, \n\nlet me invite you to a presentation on oVirt UI Plug ins feature. \n\nIn this session\, you will learn about: \n\n * high-leve l overview of UI Plugins feature: main concepts\, how it works \n * curre nt state of plugin infrastructure\, including updates from recent revisions (rev.4 and rev.5) \n * tutorial on writing simple plugin\, providing insi ght on plugin lifecycle from plugin author perspective \n * few tips for plugin authors on implementing new plugin API features \n\n\n\n\n\n\nHere ar e the details required for joining the session. \n\nIntercall dial-in number s can be found at: \nhttps://www.intercallonline.com/portlets/scheduling/vie wNumbers/listNumbersByCode.do?confCode=7128867405 \n\nIntercall Conference C ode ID: 7128867405 # \n\n\nElluminate session: \nhttps://sas.elluminate.com/ m.jnlp?sid=819&password=M.49FFA576F865467B73763A1B6F57CC \n\n\n\n\nRegards\, \nVojtech \n\n\n X-ALT-DESC;FMTTYPE=text/html:<html><body id='htmlmode'><h3>The following is a new meeting request:</h3>\n\n\n<table border='0'>\n<tr><th align=left>S ubject:</th><td>oVirt UI Plugins Presentation </td></tr>\n<tr><th align=left >Organizer:</th><td>"Vojtech Szocs" &lt\;vszocs(a)redhat.com&gt\; </td></tr>\n </table>\n\n<table border='0'>\n<tr><th align=left>Time:</th><td>Tuesday\ , October 9\, 2012\, 4:00:00 PM - 6:00:00 PM GMT +01:00 Belgrade\, Bratislav a\, Budapest\, Ljubljana\, Prague\n </td></tr></table>\n\n<table border=' 0'>\n<tr><th align=left>Invitees:</th><td>engine-devel(a)ovirt.org\; iheim@red hat.com\; ecohen(a)redhat.com\; George.Costea(a)netapp.com\; Christopher.Morriss ey(a)netapp.com\; Dustin.Schoenbrun(a)netapp.com\; Ricky.Hopper(a)netapp.com\; Tro y.Mangum(a)netapp.com\; Chris.Frantz(a)hp.com </td></tr>\n</table>\n<div>*~*~*~* ~*~*~*~*~*~*</div> <div style='font-family: times new roman\,new york\,ti mes\,serif\; font-size: 12pt\; color: #000000'>Hi guys\, let me invit e you to a presentation on oVirt UI Plugin s feature. In this session\, you will learn about: <ul><li> high-level overview of UI Plugins feature: main concepts\, how it works</li> <li>current state of plugin infrastructure\, including updates from recent r evisions (rev.4 and rev.5)</li><li>tutorial on writing simple plugin\, provi ding insight on plugin lifecycle from plugin author perspective</li><li>few tips for plugin authors on implementing new plugin API features</li></ul> <hr style="width: 100%\; height: 2px\;"> Here are the d etails required for joining the session. Intercall dial-in numbers ca n be found at: <a target="_bl ank" href="https://www.intercallonline.com/portlets/scheduling/viewNumbers/l istNumbersByCode.do?confCode=7128867405">https://www.intercallonline.com/por tlets/scheduling/viewNumbers/listNumbersByCode.do?confCode=7128867405</a></s pan> Intercall Conference Code ID: <a href="callto:7128867405" target="_blank">712 8867405</a># Elluminate session:<a target="_blank" href="https ://sas.elluminate.com/m.jnlp?sid=819&amp\;password=M.49FFA576F865467B73763A1 B6F57CC">https://sas.elluminate.com/m.jnlp?sid=819&amp\;password=M.49FFA576F 865467B73763A1B6F57CC</a> <hr style="width: 100%\; height: 2px\;"> Regards\, Vojtech </div></body></html> BEGIN:VALARM ACTION:DISPLAY TRIGGER;RELATED=START:-PT5M DESCRIPTION:Reminder END:VALARM END:VEVENT END:VCALENDAR ------=_Part_4538700_1948709573.1349346221588--

1 0

[Engine-devel] new ovirt-engine-sdk features (form 3.1 till now)
by Michael Pasternak 04 Oct '12

04 Oct '12

- allow persistent_auth via localhost - make /filter header global rather than method driven #857018 - throw error when connecting to ssl site using http protocol - raise NoCertificatesError only when no ca_file specified - several rebases to include latest engine features -- Michael Pasternak RedHat, ENG-Virtualization R&D

1 0

[Engine-devel] new ovirt-engine-cli features (form 3.1 till now)
by Michael Pasternak 04 Oct '12

04 Oct '12

- support utf-8 encoding - do not log /connect command in history - disable /history while not connected - add username/password prompt/command-line functionality - history command does not support pipe redirection #854486 - valid UUIDs are treated as syntax error #854391 - Rename /delete command with /remove #855769 - Raise an error if identifier is not specified in /show command #855750 - remove --show-all option from /show command #855749 - rename "create" command with "add" #855773 - change NoCertificatesError message to ask only for ca_file - implement /filter flag - do not write to file i/o during script execution - shell does not exit when using /exit/ command in script -- Michael Pasternak RedHat, ENG-Virtualization R&D

1 0

Re: [Engine-devel] UI Plugins: PoC patch revision 5 is here
by Morrissey, Christopher 03 Oct '12

03 Oct '12

--_000_D290AD8432118048947689BA3AE8A9B3E47B82SACEXCMBX04PRDhqn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Vojtech, The patch is great and has cleared up some questions I had about the implem= entation. I've been able to get the sample plugins working and waded throug= h the code changes, so feel like I have a good understanding of what was de= livered. Thanks a lot for putting this all together. I do have a few questi= ons and suggestions for you, though. Will there eventually be a way to add one or more buttons to the context se= nsitive buttons and menus throughout the interface? For example, we'd like = to allow a button to provision a datastore when a data center, cluster, or = host is selected. When the button is clicked, it would open a dialog with a= n iframe in which we would load our interface to perform the associated act= ion. Some contexts would have several buttons, such as a storage domain (pr= ovision, resize, dedupe management, destroy) so it would probably make sens= e for a drop down menu to be available as well so that the number of button= s above the table doesn't get too cluttered. We'd also like to add these sa= me actions to the menus that popup when a contextual object is right clicke= d. If needed we can help work on an implementation for the dialog popup plugin= framework as we'd like to get it in relatively quickly so we can move forw= ard on the content side of our plugin. For the reverse proxy, would it be easier from a customer standpoint to jus= t include a reverse proxy servlet such as this one? http://sourceforge.net= /projects/j2ep/ I'm just thinking that setting up and managing a plugin for the HTTP server= may be more complex than including one internally that would be transparen= t to a customer. Thanks, Chris From: Vojtech Szocs <vszocs(a)redhat.com<mailto:vszocs@redhat.com>> Date: September 21, 2012 4:37:31 PM EDT To: engine-devel <engine-devel(a)ovirt.org<mailto:engine-devel@ovirt.org>> Subject: [Engine-devel] UI Plugins: PoC patch revision 5 is here Hi guys, it's been a while but here comes the latest revision of UI Plugins proof-of= -concept patch (please find it attached). This revision was originally meant to focus solely on server-side component= s of the plugin infrastructure. However, I ended up implementing all the ma= jor concepts and ideas as discussed on engine-devel mailing list, impacting= both client-side and server-side parts of the plugin infrastructure. As a = result, UI plugin infrastructure should be pretty much complete now, so we = can focus on specific plugin API features in upcoming PoC revisions. There's a whole bunch of changes and improvements in this revision, so I'll= try to cover all the relevant parts step by step. If you have any comments= , questions or ideas, please let me know! So here we go... (or if you just want to get the patch, find the link at th= e end of this message) ________________________________ 0. Added new Engine configuration values UI plugin data path is represented by ConfigValues.UIPluginDataPath enum op= tion ("UIPluginDataPath" in vdc_options table), and resolved relative to Co= nfigValues.DataDir if possible. Following (default) values: * UIPluginDataPath =3D ui-plugins * DataDir =3D /usr/share/ovirt-engine result in UI plugin data path: /usr/share/ovirt-engine/ui-plugins UI plugin config path is represented by ConfigValues.UIPluginConfigPath enu= m option ("UIPluginConfigPath" in vdc_options table), and resolved relative= to ConfigValues.ConfigDir if possible. Following (default) values: * UIPluginConfigPath =3D ui-plugins * ConfigDir =3D /etc/ovirt-engine result in UI plugin config path: /etc/ovirt-engine/ui-plugins 1. Processing UI plugin data on the server PluginDataManager is the class responsible for reading, validating and cach= ing UI plugin descriptor/configuration data on the server (Engine). It has = two main responsibilities: * return a snapshot of currently valid plugin data (getCurrentData meth= od) * reload plugin data from local file system if necessary (reloadData me= thod) The reloadData method doesn't modify "live" plugin data directly. Instead, = it creates a local working copy of current plugin data, updates this copy a= s it reads/validates plugin descriptor and configuration files, and attempt= s to update "live" plugin data through conditional reference re-assignment = (using java.util.concurrent.atomic.AtomicReference.compareAndSet method). In other words, reloadData method makes no attempts with regard to Java loc= k-based synchronization, in favor of dealing with "live" data through Atomi= cReference (reference that involves atomic volatile reads and writes): * In the best case, a thread will succeed in updating "live" data (Atom= icReference.compareAndSet =3D=3D true), which means that "live" data remain= ed unchanged since this thread acquired a reference of current plugin data. * In the worst case, a thread will NOT succeed in updating "live" data = (AtomicReference.compareAndSet =3D=3D false), which means that "live" data = was already changed by another thread since this thread acquired a referenc= e of current plugin data. In my opinion, when dealing with external resources like the local file sys= tem, this is a good compromise between performance and up-to-date data. Whi= le we might not get "completely-up-to-date" data at the given point in time= (reloadData + getCurrentData), we are guaranteed to get "recently-up-to-da= te" and consistent data. In other words, the requirement of "completely-up-= to-date" data would involve synchronized statements that would hurt perform= ance. In my (very humble) opinion, the benefit of having "completely-up-to-= date" data, at the cost of reduced performance, is not really worth it, esp= ecially in our case when the user can just hit refresh (F5) to reload WebAd= min and its plugin data. Plugin descriptor files are expected to be placed in UI plugin data path, f= or example: /usr/share/ovirt-engine/ui-plugins/foo.json Following descriptor file attributes are implemented and recognized by the = plugin infrastructure: * name: A name that uniquely identifies the plugin (required attribute)= . * url: URL of plugin host page that invokes the plugin code (required a= ttribute). * config: Default configuration object associated with the plugin (opti= onal attribute). * resourcePath: Path to plugin static resources, relative to UI plugin = data path (optional attribute). This is used when serving plugin files thro= ugh Engine PluginResourceServlet (more on this below). Plugin configuration files are expected to be placed in UI plugin config pa= th, for example: /etc/engine/ui-plugins/foo-config.json Note that plugin configuration files follow the "<descriptorFileName>-confi= g.json" convention. Following configuration file attributes are implemented and recognized by t= he plugin infrastructure: * config: Custom configuration object associated with the plugin (optio= nal attribute). This overrides the default plugin descriptor configuration,= if any. * enabled: Indicates whether the plugin should be loaded on WebAdmin st= artup (optional attribute). Default value is 'true'. * order: Defines the relative order in which the plugin will be loaded = on WebAdmin startup (optional attribute). Default value is Integer.MAX_VALU= E (lowest order). The concept of merging custom configuration (config attribute in foo-config= .json), if any, on top of default configuration (config attribute in foo.js= on), if any, remains unchanged. This makes the plugin configuration quite f= lexible - in my opinion, the added complexity of handling/merging such conf= iguration is definitely worth the effort. The enabled attribute is straight-forward, allowing users to turn the given= plugin off, if necessary. In future, users should still be able to load su= ch plugins through WebAdmin GUI. The order attribute controls the order in which plugins are loaded on WebAd= min startup. Since plugin resources are fetched asynchronously by the brows= er, this is basically a way of imposing some degree of determinism in the "= generally-non-deterministic" plugin environment, which is helpful when trou= bleshooting problems with multiple plugins. This attribute is also helpful = due to file listing methods in java.io.File giving no guarantees that files= would be listed in any particular order (otherwise we could just go for th= e "NN-<descriptorFileName>.json" convention, with NN being the order number= ). 2. Modified behavior of WebadminDynamicHostingServlet WebadminDynamicHostingServlet is the servlet used to serve WebAdmin applica= tion host page (HTML page that bootstraps WebAdmin JavaScript code). In addition to its former behavior, as part of handling the given request, = WebadminDynamicHostingServlet: * reloads descriptor/configuration data from local file system if neces= sary, and obtains a snapshot of currently valid plugin data (PluginDataMana= ger.reloadAndGetCurrentData) * embeds all plugin meta-data, suitable for use in client-side plugin i= nfrastructure, into WebAdmin host page as "pluginDefinitions" JavaScript ar= ray (PluginDefinitions) As a result, reloading UI plugin descriptor/configuration data is as simple= as refreshing (F5) WebAdmin application in the browser (no need to restart= Engine). 3. Added servlet for serving plugin static resources PluginResourceServlet is the servlet used to serve UI plugin static files (= plugin host page, 3rd party JavaScript, etc.) from the local file system. For example, requesting URL: * http://<EngineManagerHost>:8700/webadmin/webadmin/plugin/foo/content/= start.html<http://%3cEngineManagerHost%3e:8700/webadmin/webadmin/plugin/foo= /content/start.html> will send the content of: * /usr/share/ovirt-engine/ui-plugins/<resourcePath>/content/start.html to the client. As shown in the above example: * /webadmin/webadmin/plugin/ is the servlet root path for PluginResourc= eServlet * in the extra path beyond the servlet root path (/foo/content/start.ht= ml): * /foo represents the name of the plugin * /content/start.html represents the path to requested resource, rel= ative to "UIPluginDataPath / <resourcePath>" Note that each plugin using PluginResourceServlet to serve its static files= must declare non-empty resourcePath attribute in within the plugin descrip= tor. Also note that PluginResourceServlet, unlike WebadminDynamicHostingServlet,= does NOT reload descriptor/configuration data from local file system as pa= rt of handling the given request. In other words, it's assumed that plugin = data has already been (re)loaded when serving WebAdmin application host pag= e, with subsequent requests to PluginResourceServlet reading the current pl= ugin information. Until we solve the cross-origin issue in a clean way, PluginResourceServlet= should be used to serve all plugin resources from local file system. 4. Plugin lifecycle improved to deal with misbehaving plugins PluginState enum has been modified to deal with plugins that allow uncaught= exceptions to escape from plugin event handler functions (e.g. "UiInit"): * removed state INITIALIZED * added state INITIALIZING: The plugin is (currently) being initialized= by calling UiInit event handler function. * added state IN_USE: Plugin's UiInit event handler function has comple= ted successfully, we can now call other event handler functions as necessar= y. The plugin is in use now. * added state FAILED: An uncaught exception escaped while calling an ev= ent handler function, which indicates internal error within the plugin code= . The plugin is removed from service. I've attached a simple state diagram that illustrates different states and = transitions between them (green color is initial state, red color is end st= ate). Uncaught exceptions in plugin event handler functions will be caught and ha= ndled by the plugin infrastructure. This prevents a misbehaving plugin from= breaking WebAdmin application, since WebAdmin is the caller (initiator) of= the function call. In such case, the plugin will be removed from service. Update on cross-origin issue (consequence of same-origin policy) In order for the plugin to access WebAdmin plugin API, plugin host page (e.= g. start.html) must be served from URL on same origin as Engine origin. Oth= erwise, plugin code running in the context of an iframe'd host page will fa= il to evaluate "parent.pluginApi" expression, with "parent" being top-level= (WebAdmin) window, and "pluginApi" being the global plugin API object expo= sed by WebAdmin. This is why PluginResourceServlet, available on Engine origin, should be us= ed to serve all plugin resources from local file system. There's only one issue that remains to be solved: cross-origin "plugin vs. = remote service" communication, with "remote service" being anything other t= han Engine (REST API). In future, we'll address this with Apache reverse pr= oxy configuration, so that users can configure Apache server (placed in fro= nt of Engine JBoss AS) to put arbitrary (local or remote non-Engine) servic= es on same origin. However, this requires a change in current Apache config= uration. Until then, users can manually edit the Engine Apache configuratio= n file (/etc/httpd/conf.d/ovirt-engine.conf). ________________________________ I've attached some sample plugin files for you to experiment with. Instead = of attaching actual patch file (92 kB) to this email, I've submitted the pa= tch to oVirt Gerrit: http://gerrit.ovirt.org/8120 Let me know what you think! Cheers, Vojtech <ui-plugin-sample-files.tar.gz> <ui-plugin-lifecycle.png> _______________________________________________ Engine-devel mailing list Engine-devel(a)ovirt.org<mailto:Engine-devel@ovirt.org> http://lists.ovirt.org/mailman/listinfo/engine-devel --_000_D290AD8432118048947689BA3AE8A9B3E47B82SACEXCMBX04PRDhqn_ 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 bgcolor=3D"white" lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> Hi Vojtech,<o:p></o:p></s= pan> <o:p> </o:p><= /p> The patch is great and ha= s cleared up some questions I had about the implementation. I’ve been= able to get the sample plugins working and waded through the code changes, so feel like I have a good understanding of what was deliver= ed. Thanks a lot for putting this all together. I do have a few questions a= nd suggestions for you, though.<o:p></o:p> <o:p> </o:p><= /p> Will there eventually be = a way to add one or more buttons to the context sensitive buttons and menus= throughout the interface? For example, we’d like to allow a button to provision a datastore when a data center, cluster, or host is = selected. When the button is clicked, it would open a dialog with an iframe= in which we would load our interface to perform the associated action. Som= e contexts would have several buttons, such as a storage domain (provision, resize, dedupe management, destroy) s= o it would probably make sense for a drop down menu to be available as well= so that the number of buttons above the table doesn’t get too clutte= red. We’d also like to add these same actions to the menus that popup when a contextual object is right clicked.= <o:p></o:p> <o:p> </o:p><= /p> If needed we can help wor= k on an implementation for the dialog popup plugin framework as we’d = like to get it in relatively quickly so we can move forward on the content side of our plugin.<o:p></o:p> <o:p> </o:p><= /p> For the reverse proxy, wo= uld it be easier from a customer standpoint to just include a reverse proxy= servlet such as this one?  <a href=3D"http://sourceforge.net/p= rojects/j2ep/">http://sourceforge.net/projects/j2ep/</a> <o:p></o:p> I’m just thinking t= hat setting up and managing a plugin for the HTTP server may be more comple= x than including one internally that would be transparent to a customer.<o:p></o:p> <o:p> </o:p><= /p> Thanks,<o:p></o:p>= Chris<o:p></o:p></= p> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <div> From: Vojtech = Szocs <<a href=3D"mailto:vszocs@redhat.com">vszocs(a)redhat.com</a>><br= > Date: September 21, 2012 4:37:31 PM EDT To: engine-devel <<a href=3D"mailto:engine-devel@ovirt.org">engin= e-devel(a)ovirt.org</a>> Subject: [Engine-devel] UI Plugins: PoC patch revision 5 is here<= /b><o:p></o:p> </div> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <div> <div> Hi guys, it's been a while but here comes the latest revision of UI Plugins proof-of= -concept patch (please find it attached). This revision was originally meant to focus solely on server-side component= s of the plugin infrastructure. However, I ended up implementing all the ma= jor concepts and ideas as discussed on engine-devel mailing list, impacting= both client-side and server-side parts of the plugin infrastructure. As a result, UI plugin infrastructure = should be pretty much complete now, so we can focus on specific plugin API = features in upcoming PoC revisions. There's a whole bunch of changes and improvements in this revision, so I'll= try to cover all the relevant parts step by step. If you have any comments= , questions or ideas, please let me know! So here we go... (or if you just want to get the patch, find the link at th= e end of this message)<o:p></o:p> <div class=3D"MsoNormal" align=3D"center" style=3D"text-align:center"><span= style=3D"color:black"> <hr size=3D"2" width=3D"100%" align=3D"center"> </div> 0. Added new Engine configuration values UI plugin data path is represented by ConfigValues.UIPluginDataP= ath enum option ("UIPluginDataPath" in vdc_options table), and resolved relative to ConfigValues.DataDir= if possible. Following (default) values:<o:p></o:p> <ul type=3D"disc"> <li class=3D"MsoNormal" style=3D"color:black;mso-margin-top-alt:auto;mso-ma= rgin-bottom-alt:auto;mso-list:l0 level1 lfo1"> UIPluginDataPath =3D ui-plugins<o:p></o:p></li><li class=3D"MsoNorma= l" style=3D"color:black;mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;= mso-list:l0 level1 lfo1"> DataDir =3D /usr/share/ovirt-engine<o:p></o:p></li></ul> result in UI plugin data= path: /usr/share/ovirt-engine/ui-plugins UI plugin config path is represented by ConfigValues.UIPluginConf= igPath enum option ("UIPluginConfigPath" in vdc_options table), and resolved relative to ConfigValues.ConfigD= ir if possible. Following (default) values:<o:p></o:p> <ul type=3D"disc"> <li class=3D"MsoNormal" style=3D"color:black;mso-margin-top-alt:auto;mso-ma= rgin-bottom-alt:auto;mso-list:l3 level1 lfo2"> UIPluginConfigPath =3D ui-plugins<o:p></o:p></li><li class=3D"MsoNor= mal" style=3D"color:black;mso-margin-top-alt:auto;mso-margin-bottom-alt:aut= o;mso-list:l3 level1 lfo2"> ConfigDir =3D /etc/ovirt-engine<o:p></o:p></li></ul> result in UI plugin config path: /etc/ovi= rt-engine/ui-plugins<o:p></o:p> 1. Processing UI plugin data on the server PluginDataManager is the class responsible for reading, validating a= nd caching UI plugin descriptor/configuration data on the server (Engine). = It has two main responsibilities:<o:p></o:p> <ul type=3D"disc"> <li class=3D"MsoNormal" style=3D"color:black;mso-margin-top-alt:auto;mso-ma= rgin-bottom-alt:auto;mso-list:l2 level1 lfo3"> return a snapshot of currently valid plugin data (getCurrentData met= hod)<o:p></o:p></li><li class=3D"MsoNormal" style=3D"color:black;mso-margin= -top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l2 level1 lfo3"> reload plugin data from local file system if necessary (reloadData m= ethod)<o:p></o:p></li></ul> The reloadData method doesn't modify = "live" plugin data directly. Instead, it creates a local working = copy of current plugin data, updates this copy as it reads/validates plugin= descriptor and configuration files, and attempts to update "live" plugin data through conditional reference re-as= signment (using java.util.concurrent.atomic.AtomicReference.compareAndSet method).<o:p>= </o:p> <o:p> </o:p> In other words, reloadData method mak= es no attempts with regard to Java lock-based synchronization, in favor of = dealing with "live" data through AtomicReference (reference that involves atomic volatile read= s and writes):<o:p></o:p> <ul type=3D"disc"> <li class=3D"MsoNormal" style=3D"color:black;mso-margin-top-alt:auto;mso-ma= rgin-bottom-alt:auto;mso-list:l4 level1 lfo4"> In the best case, a thread will succeed in updating "live" data (= AtomicReference.compareAndSet =3D=3D true), which means that "l= ive" data remained unchanged since this thread acquired a reference of= current plugin data.<o:p></o:p></li><li class=3D"MsoNormal" style=3D"color= :black;mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l4 level= 1 lfo4"> In the worst case, a thread will NOT succeed in updating "live" d= ata (AtomicReference.compareAndSet =3D=3D false), which means that &= quot;live" data was already changed by another thread since this threa= d acquired a reference of current plugin data.<o:p></o:p></li></ul> In my opinion, when dealing with external re= sources like the local file system, this is a good compromise between perfo= rmance and up-to-date data. While we might not get "completely-up-to-d= ate" data at the given point in time (reloadData + getCurrentData), we are guaranteed to get "recently-up-to-d= ate" and consistent data. In other words, the requirement of "com= pletely-up-to-date" data would involve synchronized statements that would hurt performance. In my (very hum= ble) opinion, the benefit of having "completely-up-to-date" data,= at the cost of reduced performance, is not really worth it, especially in = our case when the user can just hit refresh (F5) to reload WebAdmin and its plugin data.<o:p></o:p> <o:p> </o:p> Plugin descriptor files are expected to be placed in UI plugin data path, for= example: /usr/share/ovirt-engine/ui-plugins/foo.json<o:p></o:p> <o:p> </o:p> Following descriptor file attributes are imp= lemented and recognized by the plugin infrastructure:<o:p></o:p> <ul type=3D"disc"> <li class=3D"MsoNormal" style=3D"color:black;mso-margin-top-alt:auto;mso-ma= rgin-bottom-alt:auto;mso-list:l9 level1 lfo5"> name: A name that uniquely identifies the plugin (required attribute= ).<o:p></o:p></li><li class=3D"MsoNormal" style=3D"color:black;mso-margin-t= op-alt:auto;mso-margin-bottom-alt:auto;mso-list:l9 level1 lfo5"> url: URL of plugin host page that invokes the plugin code (required = attribute).<o:p></o:p></li><li class=3D"MsoNormal" style=3D"color:black;mso= -margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l9 level1 lfo5"> config: Default configuration object associated with the plugin (opt= ional attribute).<o:p></o:p></li><li class=3D"MsoNormal" style=3D"color:bla= ck;mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l9 level1 lf= o5"> resourcePath: Path to plugin static resources, relative to UI plugin= data path (optional attribute). This is used when serving plugin files thr= ough Engine PluginResourceServlet (more on this below).<o:p></o:p></li></ul> Plugin configuration files<spa= n style=3D"color:black"> are expected to be placed in UI plugin config path= , for example: /etc/engine/ui-plugins/foo-config.json<o:p></o:p> <o:p> </o:p> Note that plugin configuration files follow = the "<descriptorFileName>-config.json" convention.<o:p></o:= p> <o:p> </o:p> Following configuration file attributes are = implemented and recognized by the plugin infrastructure:<o:p></o:p><= /p> <ul type=3D"disc"> <li class=3D"MsoNormal" style=3D"color:black;mso-margin-top-alt:auto;mso-ma= rgin-bottom-alt:auto;mso-list:l8 level1 lfo6"> config: Custom configuration object associated with the plugin (opti= onal attribute). This overrides the default plugin descriptor configuration= , if any.<o:p></o:p></li><li class=3D"MsoNormal" style=3D"color:black;mso-m= argin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l8 level1 lfo6"> enabled: Indicates whether the plugin should be loaded on WebAdmin s= tartup (optional attribute). Default value is 'true'.<o:p></o:p></li><li cl= ass=3D"MsoNormal" style=3D"color:black;mso-margin-top-alt:auto;mso-margin-b= ottom-alt:auto;mso-list:l8 level1 lfo6"> order: Defines the relative order in which the plugin will be loaded= on WebAdmin startup (optional attribute). Default value is Integer.MAX_VALUE (lowest order).<o:p></o:p></li></ul> The concept of merging custom configuration = (config attribute in foo-config.json), if any, on top of default configuration (config= attribute in foo.json), if any, remains unchanged. This makes the plugin configur= ation quite flexible - in my opinion, the added complexity of handling/merg= ing such configuration is definitely worth the effort.<o:p></o:p></p= > <o:p> </o:p> The enabled attribute is straight-for= ward, allowing users to turn the given plugin off, if necessary. In future,= users should still be able to load such plugins through WebAdmin GUI.<o:p>= </o:p> <o:p> </o:p> The order attribute controls the orde= r in which plugins are loaded on WebAdmin startup. Since plugin resources a= re fetched asynchronously by the browser, this is basically a way of imposi= ng some degree of determinism in the "generally-non-deterministic" plugin environment, which is helpf= ul when troubleshooting problems with multiple plugins. This attribute is a= lso helpful due to file listing methods in java.io.File giving no guarantees that files would be listed in any = particular order (otherwise we could just go for the "NN-<descripto= rFileName>.json" convention, with NN being the order number).<o:p><= /o:p> 2. Modified behavior of WebadminDynamicHostingServlet WebadminDynamicHostingServlet is the servlet used to serve WebAdmin = application host page (HTML page that bootstraps WebAdmin JavaScript code).= In addition to its former behavior, as part of handling the given request, = WebadminDynamicHostingServlet:<o:p></o:p> <ul type=3D"disc"> <li class=3D"MsoNormal" style=3D"color:black;mso-margin-top-alt:auto;mso-ma= rgin-bottom-alt:auto;mso-list:l7 level1 lfo7"> reloads descriptor/configuration data from local file system if necessary, = and obtains a snapshot of currently valid plugin data (PluginDataManager= .reloadAndGetCurrentData)<o:p></o:p></li><li class=3D"MsoNormal" style= =3D"color:black;mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list= :l7 level1 lfo7"> embeds all plugin meta-data, suitable for use in client-side plugin infrast= ructure, into WebAdmin host page as "pluginDefinitions" JavaScrip= t array (PluginDefinitions)<o:p></o:p></li></ul> As a result, reloading U= I plugin descriptor/configuration data is as simple as refreshing (F5) WebA= dmin application in the browser (no need to restart Engine). 3. Added servlet for serving plugin static resources PluginResourceServlet is the servlet used to serve UI plugin static = files (plugin host page, 3rd party JavaScript, etc.) from the local file sy= stem. For example, requesting URL:<o:p></o:p> <ul type=3D"disc"> <li class=3D"MsoNormal" style=3D"color:black;mso-margin-top-alt:auto;mso-ma= rgin-bottom-alt:auto;mso-list:l5 level1 lfo8"> <a href=3D"http://%3cEngineManagerHost%3e:8700/webadmin/webadmin/plugin/= foo/content/start.html">http://<EngineManagerHost>:8700/webadmin/weba= dmin/plugin/foo/content/start.html</a><o:p></o:p></li></ul> will send the content of:<o:p></o:p><= /p> <ul type=3D"disc"> <li class=3D"MsoNormal" style=3D"color:black;mso-margin-top-alt:auto;mso-ma= rgin-bottom-alt:auto;mso-list:l1 level1 lfo9"> /usr/share/ovirt-engine/ui-plugins/<resourcePath>/content/start.ht= ml<o:p></o:p></li></ul> to the client.<o:p></o:p> <o:p> </o:p> As shown in the above example:<o:p></o:p></s= pan> <ul type=3D"disc"> <li class=3D"MsoNormal" style=3D"color:black;mso-margin-top-alt:auto;mso-ma= rgin-bottom-alt:auto;mso-list:l10 level1 lfo10"> /webadmin/webadmin/plugin/ is the servlet root path for PluginRes= ourceServlet<o:p></o:p></li><li class=3D"MsoNormal" style=3D"color:blac= k;mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l10 level1 lf= o10"> in the extra path beyond the servlet root path (/foo/content/start.html<= /i>):<o:p></o:p></li></ul> <ul type=3D"disc"> <ul type=3D"circle"> <li class=3D"MsoNormal" style=3D"color:black;mso-margin-top-alt:auto;mso-ma= rgin-bottom-alt:auto;mso-list:l10 level2 lfo10"> /foo represents the name of the plugin<o:p></o:p></li><li class=3D"M= soNormal" style=3D"color:black;mso-margin-top-alt:auto;mso-margin-bottom-al= t:auto;mso-list:l10 level2 lfo10"> /content/start.html represents the path to requested resource, relat= ive to "UIPluginDataPath / <resourcePath>"<o:p></o:p></li><= /ul> </ul> Note that each plugin us= ing PluginResourceServlet to serve its static files must declare non= -empty resourcePath attribute in within the plugin descriptor. Also note that PluginResourceServlet, unlike WebadminDynamicHosti= ngServlet, does NOT reload descriptor/configuration data from local fil= e system as part of handling the given request. In other words, it's assume= d that plugin data has already been (re)loaded when serving WebAdmin application host page, with subsequent re= quests to PluginResourceServlet reading the current plugin information. Until we solve the cross-origin issue in a clean way, PluginResourceServ= let should be used to serve all plugin resources from local file system= . 4. Plugin lifecycle improved to deal with misbehaving plugins PluginState enum has been modified to deal with plugins that allow u= ncaught exceptions to escape from plugin event handler functions (e.g. &quo= t;UiInit"):<o:p></o:p> <ul type=3D"disc"> <li class=3D"MsoNormal" style=3D"color:black;mso-margin-top-alt:auto;mso-ma= rgin-bottom-alt:auto;mso-list:l6 level1 lfo11"> removed state INITIALIZED<o:p></o:p></li><li class=3D"MsoNormal" sty= le=3D"color:black;mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-li= st:l6 level1 lfo11"> added state INITIALIZING: The plugin is (currently) being initialize= d by calling UiInit event handler function.<o:p></o:p></li><li class=3D"Mso= Normal" style=3D"color:black;mso-margin-top-alt:auto;mso-margin-bottom-alt:= auto;mso-list:l6 level1 lfo11"> added state IN_USE: Plugin's UiInit event handler function has compl= eted successfully, we can now call other event handler functions as necessa= ry. The plugin is in use now.<o:p></o:p></li><li class=3D"MsoNormal" style= =3D"color:black;mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list= :l6 level1 lfo11"> added state FAILED: An uncaught exception escaped while calling an e= vent handler function, which indicates internal error within the plugin cod= e. The plugin is removed from service.<o:p></o:p></li></ul> I've attached a simple state diagram that illustrates different stat= es and transitions between them (green color is initial state, red color is= end state). Uncaught exceptions in plugin event handler functions will be caught and ha= ndled by the plugin infrastructure. This prevents a misbehaving plugin from= breaking WebAdmin application, since WebAdmin is the caller (initiator) of= the function call. In such case, the plugin will be removed from service. Update on cross-origin issue (consequence of same-origin policy) In order for the plugin to access WebAdmin plugin API, plugin host page (e.= g. start.html) must be served from URL on same origin as Engine origin. Ot= herwise, plugin code running in the context of an iframe'd host page will f= ail to evaluate "parent.pluginApi" expression, with "parent&= quot; being top-level (WebAdmin) window, and "pluginApi" being the global plugin API object exposed by WebAdmin. This is why PluginResourceServlet, available on Engine origin, shoul= d be used to serve all plugin resources from local file system. There's only one issue that remains to be solved: cross-origin "plugin= vs. remote service" communication, with "remote service" be= ing anything other than Engine (REST API). In future, we'll address this wi= th Apache reverse proxy configuration, so that users can configure Apache server (placed in front of Engine JBoss AS) to put ar= bitrary (local or remote non-Engine) services on same origin. However, this= requires a change in current Apache configuration. Until then, users can m= anually edit the Engine Apache configuration file (/etc/httpd/conf.d/ovirt-engine.conf).<o:p></o:p> <div class=3D"MsoNormal" align=3D"center" style=3D"text-align:center"><span= style=3D"color:black"> <hr size=3D"2" width=3D"100%" align=3D"center"> </div> I've attached some sample plugin files for you to experiment with. Instead = of attaching actual patch file (92 kB) to this email, I've submitted the pa= tch to oVirt Gerrit: <a href=3D"http://gerrit.ovirt.org/8120">http://gerrit.ovirt.org/8120</a><b= r> Let me know what you think! Cheers, Vojtech<o:p></o:p> </div> </div> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <div> <ui-plugin-sample-files.tar.gz><o:p></o:p> </div> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <div> <ui-plugin-lifecycle.png><o:p></o:p> </div> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <div> _______________________________________________ Engine-devel mailing list <a href=3D"mailto:Engine-devel@ovirt.org">Engine-devel(a)ovirt.org</a> <a href=3D"http://lists.ovirt.org/mailman/listinfo/engine-devel">http://lis= ts.ovirt.org/mailman/listinfo/engine-devel</a><o:p></o:p> </div> </blockquote> </div> </body> </html> --_000_D290AD8432118048947689BA3AE8A9B3E47B82SACEXCMBX04PRDhqn_--

3 4

[Engine-devel] Frontend questions.
by snmishra＠linux.vnet.ibm.com 02 Oct '12

02 Oct '12

Hi, I am looking at adding support for novnc in ovirt. I have not worked on the frontend and thought of asking some questions to the list to save time. Currently, when a user selects to open console on a VM with VNC. They get a popup window with IP, port and password for VNC session. I plan to take this info to host and run the command - novnc_server --vnc IP:(port-5900) This command returns a URL, use this url to open a new browser window which will be a vnc session to the VM. My questions are - 1. How to run the novnc-server command on the host? 2. How to open a new URL for VNC session? Thanks Sharad Mishra

4 3

[Engine-devel] Running test suites on other OSs
by Allon Mureinik 30 Sep '12

30 Sep '12

Hi guys, After some on-and-off work over the last week (thanks Daniel!), as of this morning, engine's test suite runs successfully on a couple of non-fedora/rhel OSs[1]. The easier to get/build/test the code, the more likely we'll be to get more developers on board, so let's try and keep it this way. How to achieve this, in one sentence: "Assumption is the mother of all screw-ups" Some slightly more detailed pointers: 1. File separators: Remember File.separatorChar? good. 2. TimeZones: If your test implicitly assumes a time zone (i.e., has anything to do with date formatting, DST changes, etc.), set it explicitly - don't assume that everyone's env shares your timezone 3. org.junit.Assume is your friend Thanks, Allon [1] Don't ask, don't tell: http://gerrit.ovirt.org/#/c/8192/5

1 0

[Engine-devel] [ATTENTION] Engine now uses PKCS#12 format to store private keys
by Alon Bar-Lev 30 Sep '12

30 Sep '12

Hello All, We committed a change in the method engine uses to store private keys. So far the engine used Java proprietary JKS format, this format enabled only Java applications to access the keys, and made it hard to manipulate them using external programs. >From now the engine is using the standard PKCS#12 format to store keys and associated certificate chain. PKCS#12 format is standard and supported by many applications, and it allowed simpler enrollment procedure. We also issue different certificate and key to be used as engine authentication (SSH, VDSM), and to be used for engine web interface (HTTPS). This change has two reasons: 1. Allow simpler migration to 3rd party certificate for the web interface. 2. Separate between different private key usages (signature and key exchange). engine-upgrade script has been modified to upgrade the environment to the new state. Please CC me for every issue you may experience. Regards, Alon.

1 0