- Devel - oVirt List Archives

[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

[Engine-devel] Missing: Always up-to-date documentation of oVirt
by David Jaša 05 Nov '13

05 Nov '13

--=-ln9kcnV6W2ZIoMc8ulrR Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, The oVirt project made a great progress in last two releases, who doesn't believe, check Itamar's talk from recent KVM Forum. :) There is a downside to that positive trend though: oVirt has become too large for one person to know all its feautures in detail (save for full-time managers of course). The only sources currently are feature pages that tend to get outdated fairly quickly after their respective feature initial implementation, and release notes. This means that user evaluating oVirt or user looking for particular feature has to cycle through release notes of several versions, go through prospective feature pages or try luck with hopefully suitable full text query. RHEV/RHS documentation is good but not perfect either because it may lack some feature available upstream and it also has some for latest features. oVirt should present itself better than now in this respect. Full-blown documentation such as the one for RHEV/RHS is out of question IMO as it requires steady effort of handful of people to keep it up-to date and covered. What IMO is feasible though is something like what libvirt does - keep page/pages such as [1] that enumerates features with a short description and note of version since when the feature was available. It is feasible because the required run-time effort on single person is quite low: when the feature is added or heavily modified, a description of similar size to DocText of RFE bug has to be added/updated in the documentation page. There is just one problem in getting there: agree if the problem really exists and devote resources to record current state of affairs. There is also one technical catch: if the documentation is to be consumable by downstreams, the "available since" notes have to be in common format that can be machine-converted downstream to matching d/s versions. I personally can't do much more than spin up a discussion and probably write about area I know, so I hope that this email can trigger actual actions by Someone Else leading to ultimate goal.... Cheers, David [1] http://libvirt.org/formatdomain.html --=20 David Ja=C5=A1a, RHCE SPICE QE based in Brno GPG Key: 22C33E24=20 Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24 --=-ln9kcnV6W2ZIoMc8ulrR Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISsjCCBjQw ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK 75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC +y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr /+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq +n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1 9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGOTCCBSGg AwIBAgIDBl1jMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN MTMwNDEwMTE0ODI4WhcNMTQwNDEwMTM1MDM0WjBXMRkwFwYDVQQNExAxUktWVnliSEdDZnRMWjY3 MRkwFwYDVQQDDBBkamFzYUByZWRoYXQuY29tMR8wHQYJKoZIhvcNAQkBFhBkamFzYUByZWRoYXQu Y29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAx8unM64NLnlRZujXHb0ilCaqc7KB r1MwlyCtOWAyH4M/24zvfyRQyTz4ZkHd1sMeewJ5ap1/128hLSqMY/6So5yhL6UlK3nM1r9H9PTz CiPEMZmDazIzMb/Mt/4N3kkJBLpWPFRB5aB+COcex7a4dlmnUJASVWkVwvHRmfa06anME7DTccV5 cV95FKqoRUXawopdu5W2NhailCtbQJAbMIGf9FpH+J98swAsVHdvjZkSDnZcoQIPHzoPrEBawb7C vsmCe8p7pv5Dxtx3T47FdAXJiO9u+QJkaBFjfiA9ywN8fFo3Q/Jr4vl6WqEr1SyQjgL9/dWeQSYI 8LzByChnXQIDAQABo4IC1jCCAtIwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYI KwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ5AqZ3fyU5HOme+iF4KA3f8RxHPjAfBgNVHSME GDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAbBgNVHREEFDASgRBkamFzYUByZWRoYXQuY29tMIIB TAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCCASowLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQg YWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBT dGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3Nl IGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYGA1UdHwQv MC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUF BwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3Mx L2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3Vi LmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29t LzANBgkqhkiG9w0BAQUFAAOCAQEArlvH1bAdnpLvyeMQzPtJYs65ur7cpYnrxrIZ3P/r0F7juzIU fb1S+M9sYBhalmBoZQMySlVveDYHUHPDsNJQtqUzYAJMbVTdRtviCSq3wmYtG/VJOOif11gM25u4 HcgXVuhF3di5G0CHwAIx0mjUi7fPJ3WMeFKWp550ZqpbFK/i9A5fJGfHk3MfXOhAu7vkEEjJY+gA BpFqvk134+30mP4KoXfNGZpekWvj6lS/tfaxuuSTusPcY0yIGGtJqqFtL1tRlTIoaDGiok5O0k6W pMFPtm+dGnOyKT4HQMFCaAgBOVCQFDYthuGlnUlJOP/BheuvaMfwgIqM4ir+DIqOyjCCBjkwggUh oAMCAQICAwZdYzANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2 BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4X DTEzMDQxMDExNDgyOFoXDTE0MDQxMDEzNTAzNFowVzEZMBcGA1UEDRMQMVJLVlZ5YkhHQ2Z0TFo2 NzEZMBcGA1UEAwwQZGphc2FAcmVkaGF0LmNvbTEfMB0GCSqGSIb3DQEJARYQZGphc2FAcmVkaGF0 LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMfLpzOuDS55UWbo1x29IpQmqnOy ga9TMJcgrTlgMh+DP9uM738kUMk8+GZB3dbDHnsCeWqdf9dvIS0qjGP+kqOcoS+lJSt5zNa/R/T0 8wojxDGZg2syMzG/zLf+Dd5JCQS6VjxUQeWgfgjnHse2uHZZp1CQElVpFcLx0Zn2tOmpzBOw03HF eXFfeRSqqEVF2sKKXbuVtjYWopQrW0CQGzCBn/RaR/iffLMALFR3b42ZEg52XKECDx86D6xAWsG+ wr7JgnvKe6b+Q8bcd0+OxXQFyYjvbvkCZGgRY34gPcsDfHxaN0Pya+L5elqhK9UskI4C/f3VnkEm CPC8wcgoZ10CAwEAAaOCAtYwggLSMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQG CCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUOQKmd38lORzpnvoheCgN3/EcRz4wHwYDVR0j BBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwGwYDVR0RBBQwEoEQZGphc2FAcmVkaGF0LmNvbTCC AUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVk IGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUg U3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9z ZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEF BQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNz MS9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1 Yi5jbGFzczEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNv bS8wDQYJKoZIhvcNAQEFBQADggEBAK5bx9WwHZ6S78njEMz7SWLOubq+3KWJ68ayGdz/69Be47sy FH29UvjPbGAYWpZgaGUDMkpVb3g2B1Bzw7DSULalM2ACTG1U3Ubb4gkqt8JmLRv1STjon9dYDNub uB3IF1boRd3YuRtAh8ACMdJo1Iu3zyd1jHhSlqeedGaqWxSv4vQOXyRnx5NzH1zoQLu75BBIyWPo AAaRar5Nd+Pt9Jj+CqF3zRmaXpFr4+pUv7X2sbrkk7rD3GNMiBhrSaqhbS9bUZUyKGgxoqJOTtJO lqTBT7ZvnRpzsik+B0DBQmgIATlQkBQ2LYbhpZ1JSTj/wYXrr2jH8ICKjOIq/gyKjsoxggNvMIID awIBATCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs YXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMGXWMwCQYFKw4DAhoFAKCCAa8w GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMxMTA1MDAwMTUyWjAj BgkqhkiG9w0BCQQxFgQUrxISTbkhz0FRsFQ+luSezjBCAhYwgaUGCSsGAQQBgjcQBDGBlzCBlDCB jDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBE aWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJp bWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMGXWMwgacGCyqGSIb3DQEJEAILMYGXoIGUMIGM MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmlt YXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwZdYzANBgkqhkiG9w0BAQEFAASCAQBsV8LEtRQT UEJQ7qWHhUTsaBOYvIbc3krAosri3Fym6p/0hl00DCS2rrR0ezpyCW54qSoXSsCikYmKNIKeewNf /yZ7TacKGTmVvHKA+U9gkd3soj5Gvv6zDJfxW0n/XewVHKsfDQhqxgCUd+UPONr7BDcw05xEBuBC GqleQ69AxWYi+5rZSfh5CycBpqg397IrAeApAQlDc/V7eXsbNYONk5+/WknQIbSITwEo4cqKCJt+ hUTDrHnr2BltjiEVlrwQ6SdpUgnnsTwtS+5l7FTJDXpALUvSb8VwoHbRXFiIeAIno+g3QmH3verk byIhET466uYcKqz1Itn+nFlQS3HlAAAAAAAA --=-ln9kcnV6W2ZIoMc8ulrR--

2 1

[Engine-devel] gerrit 2.7
by Itamar Heim 05 Nov '13

05 Nov '13

the only change i see interesting in gerrit 2.7 is: - New copyMaxScore setting for labels. Labels can be configured to copy approvals forward to the next patch set. but it's not clear on its scope, considering the mentioned changes in 2.8 release notes on same topic. I plan to upgrade gerrit to 2.7 in a couple of weeks, mainly to prepare for the 2.8 upgrade later on. gerrit 2.8 (not released yet) has these interesting changes: - Configurable external robots.txt file. (courtesy of juan hernandez) as well as: - Labels can be configured to copy scores forward to new patch sets if there is no code change. - Labels can be configured to copy scores forward to new patch sets for trivial rebases. - New button to cherry-pick the change to another branch. - When issuing a rebase via the Web UI, the committer is now the logged in user, rather than "Gerrit Code Review". - Copy reviewed flag to new patch sets for identical files. If a user has already seen and reviewed a file, the reviewed flag is forwarded on to the next patch set when the content of the file in the next patch set is identical to the reviewed file. other interesting changes in 2.8: - New change screen with completely redesigned UI and fully using the REST API. - Secondary indexing with Lucene and Solr. - Lots of new REST API endpoints. - New UI extension and JavaScript API for plugins.

1 0