- Devel - oVirt List Archives

[Engine-devel] UI Refresh synchronization
by Alexander Wels 12 Nov '13

12 Nov '13

Hi guys, I am working on providing our users with a better experience in regards to refresh synchronization. Quite often it will happen that you as a user will do a particular action, and it takes a whole refresh cycle for you to see the UI updated in response to that action. For instance if you remove a VM in the webadmin and click the ok button in the UI, the grid will still show the VM until the next refresh cycle, not when the VM is actually removed. I have created a wiki page that outlines the issues, and the ways we are intending to solve these issues [1]. Feel free to comment/e-mail/etc to let me know what you guys think. Alexander [1] http://www.ovirt.org/Features/Design/UIRefreshSynchronization

1 0

[Engine-devel] GWT DevMode plugin stopped working in Firefox 24+
by Greg Sheremeta 12 Nov '13

12 Nov '13

I submitted a bug. Please star it if this affects you. https://code.google.com/p/google-web-toolkit/issues/detail?id=8423 Detailed description (please be as specific as possible): The DevMode plugin does not work (Development Mode requires the GWT Developer Plugin). I encountered this in Firefox 24. Upgraded to Firefox 25 and plugin 1.25, still doesn't work. Workaround if you have one: roll back to Firefox 23. Greg Greg Sheremeta Red Hat, Inc. Sr. Software Engineer, RHEV Cell: 919-807-1086 gshereme(a)redhat.com

2 2

[Engine-devel] Permissions involved in using REST API
by Jonathan Daugherty 11 Nov '13

11 Nov '13

Hi all, I'm interested in setting up a non-administrative user account to be used to access the oVirt REST API. I have a user who is testing this functionality by integrating some Vagrant-related software to talk to oVirt. The user's oVirt account is a non-admin account with enough privileges to create and modify VMs on one of my clusters. What we found is that the account is unable to make requests to, say, /api/vms (he gets 401 or 404 responses) and instead gets a response indicating that the account has "insufficient permissions." My engine.log says of the access only this: 2013-11-06 14:50:28,158 ERROR [org.ovirt.engine.api.restapi.resource.AbstractBackendResource] (ajp--127.0.0.1-8702-13) Operation Failed: query execution faile d due to insufficient permissions. and in server.log I have see Java tracebacks involving this[1]: 2013-11-06 14:50:28,159 WARN [org.jboss.resteasy.core.SynchronousDispatcher] (ajp--127.0.0.1-8702-13) failed to execute: org.ovirt.engine.api.restapi.resource.BaseBackendResource$WebFaultException Later we found that assigning an Admin role to the user's account at the data center level with no permissions enabled permitted API access. So the user was able to make requests to /api/ URLs and get data and was able to log into the oVirt administration portal but was unable to take further action. So my questions are: - Is this expected behavior? Is there some smaller (less permissive) change in privileges I can use to bring about the same behavior? - Is there some place where such behavior is documented? I couldn't find any. The documentation on permissions on the RHEV docs only mentions the overall impact of using specific roles and permissions and says nothing about API access consequences or "Admin" roles with no permissions. My initial assumption was that any user with credentials would be able to make API requests, but that the corresponding API responses would be filtered based on what the user had privileges to see just as with the User Portal. Thanks! [1] A full trace can be found at http://pastebin.com/czcfQkYL -- Jonathan Daugherty Software Engineer Galois, Inc.

3 7

[Engine-devel] REST-API: Problem with additional DELETE action at collection level
by Shubhendu Tripathi 11 Nov '13

11 Nov '13

This is a multi-part message in MIME format. --------------050509030900000404030401 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi All, There is a DELETE action defined at collection level for Gluster Bricks with signature - /@DELETE public////Response//remove//(//GlusterBricks//bricks//);/ Recently we had needed a commit action to remove migrated bricks. After multiple rounds of discussion on introducing a commit action to remove migrated bricks we introduced a DELETE action [1] which accepts a boolean parameter isForce. If the parameter is set to /true/, forced deletion of bricks happens without any data migration. And if the parameter is not set or set to /false,/ the deletion is meant for a brick on which migration has already taken place. To achieve the above functionality we introduced another DELETE action with new signature as below and also marked the first action as deprecated - /@DELETE public////Response//remove//(//Action//action//);/ The problem arises now as the new api works fine for all possible scenarios with below input structure - / //<action>// // <force>true/false</force>// // <bricks>// // <brick>// // <name>//brick1-name</name>// // <name>brick2-name</name>// // </brick>// // </bricks>// //</action>/ BUT after these change backward compatibility is broken and the old api does not work. If we try invoking old DELETE with bricks as input parameter as below, it still invokes the new api and gives an error saying "Invalid parameter". / //<bricks> <brick id="brick1-id"/> // <brick id="brick2-id"/> </bricks>/ Kindly suggest a solution around the same. *PS:* Both the actions are defined at collection level (//api/clusters/<cluster-id>/glustervolumes/<volume-id>/bricks/) [1]: http://gerrit.ovirt.org/#/c/21043/ Thanks and Regards, Shubhendu --------------050509030900000404030401 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"> Hi All,<br> <br> There is a DELETE action defined at collection level for Gluster Bricks with signature -<br> <br> <font color="#3333ff"><i><span class="kwd">@DELETE<br> public</span></i><i><span class="pln"> </span></i><i><span class="typ">Response</span></i><i><span class="pln"> remove</span></i><i><span class="pun">(</span></i><i><span class="typ">GlusterBricks</span></i><i><span class="pln"> bricks</span></i></font><span class="pun"><font color="#3333ff"><i>);</i></font><br> <br> Recently we had needed a commit action to remove migrated bricks. <br> After multiple rounds of discussion on introducing a commit action to remove migrated bricks we introduced a DELETE action [1] which accepts a boolean parameter isForce.<br> If the parameter is set to <i>true</i>, forced deletion of bricks happens without any data migration.<br> And if the parameter is not set or set to <i>false,</i> the deletion is meant for a brick on which migration has already taken place.<br> <br> To achieve the above functionality we introduced another DELETE action with new signature as below and </span><span class="pun"><span class="pun"><span class="pun">also marked the first action as deprecated</span></span> -<br> <br> </span><span class="pun"><font color="#3333ff"><i><span class="kwd">@DELETE<br> public</span></i><i><span class="pln"> </span></i><i><span class="typ">Response</span></i><i><span class="pln"> remove</span></i><i><span class="pun">(</span></i><i><span class="typ">Action</span></i><i><span class="pln"> action</span></i></font><span class="pun"><font color="#3333ff"><i>);</i></font><br> <br> The problem arises now as the new api works fine for all possible scenarios with below input structure -<br> <font color="#3333ff"><i><br> </i><i><action></i><i><br> </i><i>    <force>true/false</force></i><i><br> </i><i>    <bricks></i><i><br> </i><i>        <brick></i><i><br> </i><i>            <name></i><i>brick1-name</name></i><i><br> </i></font></span></span><span class="pun"><span class="pun"><font color="#3333ff"><i><span class="pun"><span class="pun">            <name>brick2-name</name></span></span></i><i><br> </i><i>        </brick></i><i><br> </i><i>    </bricks></i><i><br> </i><i></action></i></font><br> <br> BUT after these change backward compatibility is broken and the old api does not work.<br> If we try invoking old DELETE with bricks as input parameter as below, it still invokes the new api and gives an error saying "<font color="#ff0000">Invalid parameter</font>".<br> <font color="#3333ff"><i><br> </i></font></span></span><font color="#3333ff"><i><span class="pun"><span class="pun"><span class="pun"><span class="pun"><bricks><br>     <brick id="brick1-id"/><br> </span></span></span></span></i></font><span class="pun"><span class="pun"><font color="#3333ff"><i><span class="pun"><span class="pun"><span class="pun"><span class="pun"><span class="pun"><span class="pun">    <brick id="brick2-id"/></span></span></span></span><br> </bricks></span></span></i></font><br> <br> Kindly suggest a solution around the same.<br> <br> <b>PS:</b> Both the actions are defined at collection level (<font color="#3333ff"><i>/api/clusters/<cluster-id>/glustervolumes/<volume-id>/bricks</i></font>)<br> <br> [1]: <a href="http://gerrit.ovirt.org/#/c/21043/">http://gerrit.ovirt.org/#/c/21043/</a><br> <br> Thanks and Regards,<br> Shubhendu<br> <br> <br> </span></span> </body> </html> --------------050509030900000404030401--

3 8

[Engine-devel] Custom properties per device + vNIC profile = not working (< 3.3)
by Mike Kolesnik 11 Nov '13

11 Nov '13

------=_Part_29121434_1238593392.1384156173914 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hi, I came across a situation where I wanted to define custom properties on a vNIC profile sitting under a network in a 3.2 data center. >From what I saw the configuration value for custom properties (CustomDeviceProperties) is split into 4, one per each version (3.0, 3.1, 3.2, 3.3). Since vNIC profile is located under the DC tree, it takes the DC version - 3.2 in this specific case. I tried to set the config value for 3.2 but got: $ engine-config -s CustomDeviceProperties="{type=interface;prop={myProp=[a-zA-Z0-9-]+}}" --cver=3.2 Cannot set value {type=interface;prop={myProp=[a-zA-Z0-9-]+}} to key CustomDeviceProperties. Device custom properties are not supported in version 3.2 This is already not very good, since in a 3.2 DC there can be 3.3 clusters with 3.3 hosts that do support custom device properties. I also tried to alter the config value in the DB directly, but the custom properties code ignored it since custom properties are not supported in 3.2. So, de facto, I have no reasonable way as a user to define custom device properties to use for my vNIC profiles in DC < 3.3. I opened the bug https://bugzilla.redhat.com/show_bug.cgi?id=1028757 for this, however I also want to discuss the situation: 1. As a user, I can't set custom properties for level < 3.3 which is not good. Removing the blocking, and loading custom properties for all versions would fix the bug and allow using custom device properties for older versions, the reasonable place to block this would be running a VM (or plugging a device). Basically this is the lesser issue.. 2. I just don't see the added value of splitting the definition of the properties per level.. The custom properties are extensions which might or might not be available to a certain VM, I don't see how having different sets of custom properties per version (what version, DC version, cluster version?) would make any difference - either the VM can utilize the extension given some state of the system, or it can't, but the determining factor is not the version but rather the availability of the extension. For example, I can have a hook for vNIC altering some property installed on host A and not host B, if the VM runs on host A it will get this capability and on host B it won't, regardless the DC version the VM is in. This is not to say we shouldn't block custom properties on the engine-VDSM API level since it's only available since 3.3, but this is handled by another config value (SupportCustomDeviceProperties) which is not alterable by the user. So basically, I think splitting the value per version is over complication and see no added value to the users, just more maintenance should they choose to use this feature. Your thoughts please. Regards, Mike ------=_Part_29121434_1238593392.1384156173914 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html><body><div style=3D"font-family: times new roman, new york, times, se= rif; font-size: 12pt; color: #000000"><div>Hi,<br></div><div><br></div><div= >I came across a situation where I wanted to define custom properties on a = vNIC profile sitting under a network in a 3.2 data center.<br></div><div>Fr= om what I saw the configuration value for custom properties (CustomDevicePr= operties) is split into 4, one per each version (3.0, 3.1, 3.2, 3.3).<br></= div><div>Since vNIC profile is located under the DC tree, it takes the DC v= ersion - 3.2 in this specific case.<br></div><div><br></div><div>I tried to= set the config value for 3.2 but got:<br></div><div>$ engine-config -s Cus= tomDeviceProperties=3D"{type=3Dinterface;prop=3D{myProp=3D[a-zA-Z0-9-]+}}" = --cver=3D3.2<br>Cannot set value {type=3Dinterface;prop=3D{myProp=3D[a-zA-Z= 0-9-]+}} to key CustomDeviceProperties. Device custom properties are not su= pported in version 3.2<br><br></div><div>This is already not very good, sin= ce in a 3.2 DC there can be 3.3 clusters with 3.3 hosts that do support cus= tom device properties.<br></div><div><br></div><div>I also tried to alter t= he config value in the DB directly, but the custom properties code ignored = it since custom properties are not supported in 3.2.<br></div><div>So, de f= acto, I have no reasonable way as a user to define custom device properties= to use for my vNIC profiles in DC < 3.3.<br></div><div><br></div><div>I= opened the bug <a href=3D"https://bugzilla.redhat.com/show_bug.cgi?id=3D10= 28757">https://bugzilla.redhat.com/show_bug.cgi?id=3D1028757</a> for this, = however I also want to discuss the situation:</div><div><br></div><div>1. A= s a user, I can't set custom properties for level < 3.3 which is not goo= d.<br></div><div>    Removing the blocking, and loading cust= om properties for all versions would fix the bug and allow using custom dev= ice properties for older versions, the reasonable place to block this would= be running a VM (or plugging a device).<br></div><div>    B= asically this is the lesser issue..<br></div><div><br></div><div>2. I just = don't see the added value of splitting the definition of the properties per= level..<br></div><div>    The custom properties are extensi= ons which might or might not be available to a certain VM, I don't see how = having different sets of custom properties per version (what version, DC ve= rsion, cluster version?) would make any difference - either the VM can util= ize the extension given some state of the system, or it can't, but the dete= rmining factor is not the version but rather the availability of the extens= ion.<br></div><div>    For example, I can have a hook for vN= IC altering some property installed on host A and not host B, if the VM run= s on host A it will get this capability and on host B it won't, regardless = the DC version the VM is in.<br></div><div><br></div><div>  &nbsp= ; This is not to say we shouldn't block custom properties on the engine-VDS= M API level since it's only available since 3.3, but this is handled by ano= ther config value (SupportCustomDeviceProperties) which is not alterable by= the user.<br></div><div>    So basically, I think splitting= the value per version is over complication and see no added value to the u= sers, just more maintenance should they choose to use this feature.<br></di= v><div><br></div><div>Your thoughts please.<br></div><div><br></div><div><s= pan name=3D"x"></span>Regards,<br>Mike<span name=3D"x"></span><br></div><di= v><br></div></div></body></html> ------=_Part_29121434_1238593392.1384156173914--

1 0

[Engine-devel] oVirt UI plugins feature announcements
by Vojtech Szocs 08 Nov '13

08 Nov '13

Hello everyone, I'd like to share some important updates on oVirt UI plugins feature. First of all, UI plugins wiki [1] is finally complete. API reference (application events, API functions, API options, entity types) now includes all the details and snippets of example code. I've also added section "Why load plugins via iframe element?" explaining reasons behind this design decision. [1] http://www.ovirt.org/Features/UIPlugins You might have noticed the changes in oVirt Engine URI layout [2], these are already reflected in UI plugins wiki. For existing plugins, this means changing URLs like this: /webadmin/webadmin/plugin/ExamplePlugin/start.html to this: /ovirt-engine/webadmin/plugin/ExamplePlugin/start.html [2] http://gerrit.ovirt.org/#/c/20473/ We're planning to merge patch "Improve UI Plugin vs. REST API integration" [http://gerrit.ovirt.org/#/c/20404/] soon, please review the change outlined in commit message, let me know if you have any questions. Last but not least, oVirt Space Shooter (a.k.a UI plugins crash course) wiki [3] has been updated to reflect changes mentioned above. [3] http://www.ovirt.org/Tutorial/UIPlugins/CrashCourse Regards, Vojtech

2 1

[Engine-devel] Browsing source repository
by Bob Doolittle 07 Nov '13

07 Nov '13

Hi folks, Do we have gitweb installed for the ovirt-engine repo, or is there any other way of browsing the source repository without cloning the entire thing? Is there a description of the various branches in the ovirt-engine repository? If I wanted to build the 3.3 source is the ovirt-engine-3.3 branch sufficient? I'm afraid I am new to git and also to general source/build conventions in place for Linux community projects, so sorry if my questions are naive (I come from a long Unix development background but no FOSS projects so far). I'm familiar with sccs, cvs, svn, and a little hg, but not git (yet). Thanks, Bob P.S. I'll be studying the User Portal primarily

3 2

Re: [Engine-devel] [UX] how to design a bar/line chart?
by Justin Hammond 06 Nov '13

06 Nov '13

Not directly related, but it would be good if the UI could also display disk activity per VM and overall for a host. I've got a few disk intensive VM's or the occasional memory starved VM that kills disk throughput for other VM's. it's always a struggle to identify them , so something in the UI would help me as a admin Sent from my iPhone On 6 Nov, 2013, at 11:45 PM, "Alexander Wels" <awels(a)redhat.com> wrote: > I suppose we need to answer a few questions before we can go into which > library is better: > > 1. Do we mind sending data over to Google so Google can render images for us. > 2. Are we fine with just an image being displayed in the grid? If we aren't > okay with #1, we will have to create some sort of servlet to generate the > images. > 3. Do we want the client to render the spark lines using javascript? > 4. Do we want interactivity with these visualizations? For instance if I move > my mouse over the spark line, does the value displayed change? > 5. Can we display whatever we choice in our current grid implementation? I > know the amount of javascript we can apply to it is somewhat limited right > now. > 6. Any other consideration I am not thinking of? > > Alexander > > On Wednesday, November 06, 2013 11:03:06 AM Malini Rao wrote: >> Is this a possibility? Looks nicer. http://style.org/chartapi/sparklines/ >> >> ----- Original Message ----- >> From: "Alexander Wels" <awels(a)redhat.com> >> To: engine-devel(a)ovirt.org >> Cc: "Malini Rao" <mrao(a)redhat.com>, "Tomas Jelinek" <tjelinek(a)redhat.com>, >> "Eldan Hildesheim" <ehildesh(a)redhat.com>, "info" <info(a)eldanet.com> Sent: >> Wednesday, November 6, 2013 10:46:01 AM >> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? >> >> Maybe gchart is an option? Examples available here [1] one of the available >> charts is a spark line. I just don't know how well that will play with our >> grid implementation. >> >> [1] >> http://clientsidegchart.googlecode.com/svn/trunk/javadoc/com/googlecode/gcha >> rt/client/package-summary.html#ChartGallery >> On Wednesday, November 06, 2013 10:24:56 AM Malini Rao wrote: >>> Hey all, >>> >>> Comments inline- >>> >>> >>> >>> ----- Original Message ----- >>> >>>> From: "Tomas Jelinek" <tjelinek(a)redhat.com> >>>> To: "Einav Cohen" <ecohen(a)redhat.com> >>>> Cc: "engine-devel" <engine-devel(a)ovirt.org>, "Eldan Hildesheim" >>>> <ehildesh(a)redhat.com>, "info" <info(a)eldanet.com>, "Malini Rao" >>>> <mrao(a)redhat.com>, "Martin Polednik" <mpoledni(a)redhat.com> Sent: >>>> Wednesday, November 6, 2013 9:58:03 AM >>>> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? >>>> >>>> Hi Einav, >>>> >>>> ----- Original Message ----- >>>> >>>>> From: "Einav Cohen" <ecohen(a)redhat.com> >>>>> To: "Tomas Jelinek" <tjelinek(a)redhat.com> >>>>> Cc: "engine-devel" <engine-devel(a)ovirt.org>, "Eldan Hildesheim" >>>>> <ehildesh(a)redhat.com>, "info" <info(a)eldanet.com>, >>>>> "Malini Rao" <mrao(a)redhat.com> >>>>> Sent: Wednesday, November 6, 2013 3:26:15 PM >>>>> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? >>>>> >>>>> Hi Tomas, >>>>> >>>>> Like Itamar, I think that a line chart is a better idea, and that a >>>>> chart per monitored fact (rather than a combined chart) is better. >>>> >>>> OK >>> >>> Based on the original request in the bug, it seems like Itamar is looking >>> for a trend rather than just one data point. I think we are thinking along >>> the correct lines here with a line graph but I think more specifically, we >>> should consider sparklines - >>> http://www.edwardtufte.com/bboard/q-and-a-fetch-msg?msg_id=0001OR. Agree >>> that we should have one sparkline per fact but we may have to see how this >>> looks when multiple sparklines reside in columns next to each other. See >>> example of a grid where there are 2 sparklines next to each other - >>> http://www.panopticon.com/Tables-Grids >>> >>>>>>> the statistics readable enough. Maybe if you hover the chart it >>>>>>> could >>>>>>> pop >>>>>>> up a bigger version of the chart? Or not needed? >>>>> >>>>> this is a nice-to-have, I think, definitely not needed. >>>> >>>> OK >>> >>> Agree. As shown in the glucose example in the Tufte link I posted above, >>> maybe all we need is to indicate the acceptable range with a band and if >>> the last point is in the range or outside, it will be clear to the user if >>> they should pay attention to it. >>> >>>>>>> - Would it be enough to have it in one color? Or should it be >>>>>>> something >>>>>>> like "the bigger the utilization the more red"? >>>>> >>>>> question is what will happen when there are a lot of "jumps": let's >>>>> say >>>>> that the graph changes from 0% to 100% to 0% to 100% and so on... what >>>>> will be painted red? the entire line, but only in the periods that it >>>>> jumps to 100%? only the parts of line that are in 100%? >>>>> maybe a single color is enough. >>>> >>>> OK >>> >>> One color with a dot to indicate the most recent or most relevant data and >>> display its value next to the sparkline >>> >>>>> I have another concern about this feature: currently, the GUI's most >>>>> frequent >>>>> refresh rate available is 5 seconds, which means that the line will >>>>> "change" >>>>> only every 5 seconds, which would be more noticeably slow when >>>>> displayed >>>>> in >>>>> a form of a line chart (not even talking about lower frequencies). >>>>> Moreover, I am not sure at what rate the VM statistics are pulled from >>>>> VDSM, >>>>> but if it is 10 seconds or 15 seconds, it means that the line in the >>>>> GUI >>>>> will >>>>> be "flat" for every 2 reads / 3 reads, which is not so good, I think. >>>>> >>>>> any thoughts around that? >>>> >>>> Good point! AFAIK the VDSM is polled each 3 seconds for basic info (e.g. >>>> the resource >>>> usage not included) and than every 5th poll (e.g. every 15 seconds) for >>>> full data >>>> (with resource usage not included). This would indeed make the graph >>>> pretty >>>> useless. >>>> >>>> Michal proposed to do some averages on the VDSM site from more frequent >>>> sampling and >>>> send this average back to engine when polled - so we would display an >>>> average after each poll (15s). >>>> >>>> I wonder if something like this is not already used on other places: >>>> @Martin, do you know about something like this? >>> >>> Why does the change in the line need to seem palpable every few seconds? I >>> think the base requirement of how accurate the data is when a user looks >>> at >>> a grid has not changed.. just the data visualization. Right? So , if the >>> refresh rate is not a problem today, why is it a problem now? Am I missing >>> something? >>> >>>>> ----- Original Message ----- >>>>> >>>>>> From: "Itamar Heim" <iheim(a)redhat.com> >>>>>> To: "Tomas Jelinek" <tjelinek(a)redhat.com>, "engine-devel" >>>>>> <engine-devel(a)ovirt.org> >>>>>> Sent: Tuesday, November 5, 2013 10:10:34 AM >>>>>> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? >>>>>> >>>>>> On 11/05/2013 11:50 AM, Tomas Jelinek wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> There is a feature request [1] which aims to replace the resource >>>>>>> utilization graphs (for example the cpu utilization from vm tab) >>>>>>> by >>>>>>> some >>>>>>> which shows not only >>>>>>> the actual percentage which is not so useful by some monitor >>>>>>> graph. >>>>>>> >>>>>>> I have the following concerns: >>>>>>> - I can think of a bar chart or a line chart and not sure what >>>>>>> would >>>>>>> be >>>>>>> better. >>>>>>> - Not sure if replacing the current chart with a bar/line chart >>>>>>> would >>>>>>> make >>>>>>> the statistics readable enough. Maybe if you hover the chart it >>>>>>> could >>>>>>> pop >>>>>>> up a bigger version of the chart? Or not needed? >>>>>>> - Would it be enough to have it in one color? Or should it be >>>>>>> something >>>>>>> like "the bigger the utilization the more red"? >>>>>>> >>>>>>> Please advise from the UX perspective. As soon as the final design >>>>>>> will >>>>>>> be >>>>>>> a bit more clear I will provide a feature page. >>>>>>> >>>>>>> Thank you, >>>>>>> Tomas >>>>>>> >>>>>>> [1]: https://bugzilla.redhat.com/show_bug.cgi?id=803251 >>>>>>> _______________________________________________ >>>>>>> Engine-devel mailing list >>>>>>> Engine-devel(a)ovirt.org >>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>>>> >>>>>> a moving trend graph (just like fedora's system monitor for >>>>>> cpu/ram/network) is what i have in mind. so a line chart. >>>>>> you could have a single chart with different lines for >>>>>> cpu/ram/network, >>>>>> or what seems to be more common, a chart per monitored fact >>>>>> _______________________________________________ >>>>>> Engine-devel mailing list >>>>>> Engine-devel(a)ovirt.org >>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>> >>> _______________________________________________ >>> Engine-devel mailing list >>> Engine-devel(a)ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/engine-devel > > _______________________________________________ > Engine-devel mailing list > Engine-devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel

2 1

[Engine-devel] [QE] 3.3.2 Release tracker
by Sandro Bonazzola 06 Nov '13

06 Nov '13

Hi, as you may know, we're planning to build oVirt 3.3.2 beta really soon and release 3.3.2 by early December. I have created a tracker bug (https://bugzilla.redhat.com/show_bug.cgi?id=1027349) for this release. Beta build will be composed in 2 weeks. The following is a list of the bugs with target 3.3.2 or 3.3: Whiteboard Bug ID Summary infra 987982 When adding a host through the REST API, the error message says that "rootPassword" is required... infra 1017267 Plaintext user passwords in async_tasks database infra 992883 VdsManager.OnTimer loads VDS instead of VdsDynamic infra 1020344 Power Managent with cisco_ucs problem infra 1009899 exportDbSchema scripts generates output file with wrong name integration 1022440 AIO - configure the AIO host to be a gluster cluster/host integration 1026926 engine-cleanup (and possible engine-setup) does not affect runtime value of shmmax integration 902979 ovirt-live - firefox doesn't trust the installed engine integration 1021805 oVirt Live - use motd to show the admin password network 1019818 Support OpenStack Havana layer 2 agent integration network 988002 [oVirt] [network] Add button shouldn't appear on specific network network 987916 [oVirt] [provider] Dialog doesn't update unless focus lost network 987999 [oVirt] [provider] Add button shouldn't appear on specific provider storage 915753 Deadlock detected during creation vms in pool storage 987917 [oVirt] [glance] API version not specified in provider dialog storage 1024449 Check the performance with lvm-2.02.100-7 virt 1007940 Cannot clone from snapshot while using GlusterFS as POSIX Storage Domain ? 991267 [RFE] Add TUI information to log file. Please set the target to 3.3.2 and add the bug to the tracker if you think that 3.3.2 should not be released without it fixed. Please also update the target to 3.3.3 or any next release for bugs that won't be in 3.3.2: it will ease gathering the blocking bugs for next releases. For those who want to help testing the bugs, I suggest to add yourself as QA contact for the bug. -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 0

[Engine-devel] RFE: SPICE and VNC graphics at the same time
by Frantisek Kobzik 06 Nov '13

06 Nov '13

Dear devels, I started working on a feature that allows user to run a VM with both SPICE and VNC graphics [1]. In the engine we derive the graphics server type (SPICE/VNC) from the video device (QXL/CIRRUS), which I think is wrong. These are two different things and should be treated separately. What I suggest is to split that configuration in vm_static into two fields: 1, (already existing) Display type with values QXL or CIRRUS 2, (new) Graphics types - enum or comma-separated string that indicates that the VM should be run with 'spice'/'vnc'/'spice,vnc'/'auto' (the last means that the type will be derived from the video device which is current behavior. The feature would consist of three patches: - vdsm - add new field in vm.conf with information about graphics types of a vm. - engine backend - add graphics types to VM and corresponding entities, adjust xml rpc communication. - engine frontend - "only" adjust the ui. The patches would be backwards compatible with older engine/vdsm versions. There are some things that must be taken into account, mostly it's about differences in SPICE/VNC supported features (like multimonitors, single qxl, smartcard, migration...). e.g. if you run a vm with both graphic types together the engine should probably disallow some spice features. But this is more of an implementation detail. Feel free to reply if you have anything to say about this feature. Cheers, Franta. [1]: https://bugzilla.redhat.com/show_bug.cgi?id=976044

3 3