November 2013 - Devel - oVirt List Archives

[Engine-devel] REST API in web UI - design proposal review call
by Vojtech Szocs 18 Nov '13

18 Nov '13

------=_Part_26065156_1804954053.1384790432845 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit The following is a new meeting request: Subject: REST API in web UI - design proposal review call Organizer: "Vojtech Szocs" <vszocs(a)redhat.com> Time: Wednesday, November 20, 2013, 2:30:00 PM - 4:30:00 PM GMT +01:00 Belgrade, Bratislava, Budapest, Ljubljana, Prague Required: Optional: engine-devel(a)ovirt.org *~*~*~*~*~*~*~*~*~* Hi guys, we're moving towards using REST API in web UI (i.e. WebAdmin and UserPortal) and would like to hear your opinion on the matter. This is a review call to summarize and discuss "Using REST API In Web UI" feature design proposal: http://www.ovirt.org/Features/Design/Using_REST_API_In_Web_UI Meeting agenda: - review current state, i.e. using GWT RPC - review main aspects of design proposal - discussion / feel free to ask questions anytime during the meeting Estimated duration: ~2 hrs. To join this meeting, dial into the Intercall bridge and use following conference code: 712 886 7405 # [https://www.intercallonline.com/listNumbersByCode.action?confCode=7128867405] Everyone is welcome to join and share his (her) thoughts. Regards, Vojtech ------=_Part_26065156_1804954053.1384790432845 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:16010101T030000 TZOFFSETTO:+0100 TZOFFSETFROM:+0200 RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=10;BYDAY=-1SU TZNAME:CET END:STANDARD BEGIN:DAYLIGHT DTSTART:16010101T020000 TZOFFSETTO:+0200 TZOFFSETFROM:+0100 RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=3;BYDAY=-1SU TZNAME:CEST END:DAYLIGHT END:VTIMEZONE BEGIN:VEVENT UID:8ec06680-c452-4cd9-a6fe-b94dd32a813d SUMMARY:REST API in web UI - design proposal review call ATTENDEE;CN=engine-devel;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRU E:mailto:engine-devel@ovirt.org ORGANIZER;CN=Vojtech Szocs:mailto:vszocs@redhat.com DTSTART;TZID="Europe/Belgrade":20131120T143000 DTEND;TZID="Europe/Belgrade":20131120T163000 STATUS:CONFIRMED CLASS:PUBLIC X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY TRANSP:OPAQUE LAST-MODIFIED:20131118T160032Z DTSTAMP:20131118T160032Z SEQUENCE:0 DESCRIPTION:The following is a new meeting request:\n\nSubject: REST API in web UI - design proposal review call \nOrganizer: "Vojtech Szocs" <vszocs@re dhat.com> \n\nTime: Wednesday\, November 20\, 2013\, 2:30:00 PM - 4:30:00 PM GMT +01:00 Belgrade\, Bratislava\, Budapest\, Ljubljana\, Prague\n \nRequir ed: \nOptional: engine-devel(a)ovirt.org \n\n*~*~*~*~*~*~*~*~*~*\n\nHi guys\, \n\nwe're moving towards using REST API in web UI (i.e. WebAdmin and UserPor tal) and would like to hear your opinion on the matter.\n\nThis is a review call to summarize and discuss "Using REST API In Web UI" feature design prop osal: http://www.ovirt.org/Features/Design/Using_REST_API_In_Web_UI\n\nMeeti ng agenda:\n- review current state\, i.e. using GWT RPC\n- review main aspec ts of design proposal\n- discussion / feel free to ask questions anytime dur ing the meeting\n\nEstimated duration: ~2 hrs.\n\nTo join this meeting\, dia l into the Intercall bridge and use following conference code: 712 886 7405 # [https://www.intercallonline.com/listNumbersByCode.action?confCode=7128867 405]\n\nEveryone is welcome to join and share his (her) thoughts.\n\nRegards \,\nVojtech\n BEGIN:VALARM ACTION:DISPLAY TRIGGER;RELATED=START:-PT5M DESCRIPTION:Reminder END:VALARM END:VEVENT END:VCALENDAR ------=_Part_26065156_1804954053.1384790432845--

1 0

[Engine-devel] move api from /api to /ovirt-engine/api
by Michael Pasternak 18 Nov '13

18 Nov '13

Hey Alon, i've noticed that ForwardServlet does not address URI parameters (such as query/matrix), i.e all destinations of this servlet will lack URI parameters been passed at source. On 11/06/2013 12:10 PM, Alon Bar-Lev wrote: > Alon Bar-Lev has posted comments on this change. > > -- > To view, visit http://gerrit.ovirt.org/20786 > To unsubscribe, visit http://gerrit.ovirt.org/settings> > -- Michael Pasternak RedHat, ENG-Virtualization R&D

2 4

[Engine-devel] oVirt 3.3.2 beta status
by Sandro Bonazzola 18 Nov '13

18 Nov '13

Hi, we're going to branch and build oVirt 3.3.2 beta on Nov 27th. A bug tracker is available at [1] and it shows only 2 bugs blocking the release: Bug 1029792 - VDSM does not report the qemu version in capabilities, if qemu-kvm-rhev is used Bug 1029885 - cloud-init testcase does not work in engine 3.3.1 The following is a list of the bugs still open with target 3.3.2 or 3.3: Whiteboard Bug ID Summary 991267 [RFE] Add TUI information to log file. infra 987982 When adding a host through the REST API, the error message says that "rootPassword" is required, but ... infra 1017267 Plaintext user passwords in async_tasks database infra 1020344 Power Managent with cisco_ucs problem infra 1009899 exportDbSchema scripts generates output file with wrong name infra 1029792 VDSM does not report the qemu version in capabilities, if qemu-kvm-rhev is used integration 1026933 pre-populate ISO domain with virtio-win ISO integration 1026930 Package virtio-win and put it in ovirt repositories integration 1030437 RFE: Configuration of email notifications integration 1022440 AIO - configure the AIO host to be a gluster cluster/host integration 902979 ovirt-live - firefox doesn't trust the installed engine integration 1021805 oVirt Live - use motd to show the admin password 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 network 906313 [oVirt-webadmin] [setupNetworks] "No valid Operation for <network_name> and Unassigned Logical Networks panel" network 1023722 [oVirt-webadmin][network] Network roles in cluster management should be radio buttons network 997197 Some AppErrors messages are grammatically incorrect (singular vs plural) storage 1016118 async between masterVersion : can't connect to StoragePool storage 987917 [oVirt] [glance] API version not specified in provider dialog storage 1029069 Live storage migration snapshot removal fails, probably due to unexpected qemu-img output ux 906394 [oVirt-webadmin] [network] Loading animation in network main tab 'hosts' and 'vms' subtab is stuck on first view... virt 1007940 Cannot clone from snapshot while using GlusterFS as POSIX Storage Domain 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 and add yourself to the testing page [2]. [1] https://bugzilla.redhat.com/1027349 [2] http://www.ovirt.org/Testing/Ovirt_3.3.2_testing -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

2 1

Re: [Engine-devel] RSDL breakage in oVirt upstream
by Michael Pasternak 15 Nov '13

15 Nov '13

Hi Shubhendu, On 11/14/2013 04:32 PM, Shubhendu Tripathi wrote: > Hi Michael/Ori, > > There is payload breakage for RSDL in upstream oVirt. can you elaborate a bit? [1] works for me. [1] http://localhost:8080/api?rsdl > This has happened somewhere between the patches gerrit.ovirt.org/#/c/20610/ and http://gerrit.ovirt.org/#/c/15409/. > If I try to test out with patch http://gerrit.ovirt.org/#/c/15409/, it does break. > > Not sure what could be the issue. Tried debugging but not able to figure it out. > > Kindly help me on the same figuring out what could be the issue. > > Thanks and Regards, > Shubhendu > -- Michael Pasternak RedHat, ENG-Virtualization R&D

2 2

[Engine-devel] [QE] ovirt-engine 3.3.1-2 published in beta repository
by Sandro Bonazzola 15 Nov '13

15 Nov '13

Hi, ovirt-engine 3.3.1-2 has been published in beta repository and is ready for testing. Bugs fixed in this version: {{BZ|1023739}} - Cannot create same Local SD path on different Hosts {{BZ|1009391}} - Change multi-monitor setting in VM Console option dialog for 3.2 compatible cluster {{BZ|1025313}} - support relative answer file name<br> {{BZ|1028748}} - answer files are world-readable and contain passwords Other fixes: Fixed a bug which caused failure to run VM with VNC console -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 2

[Engine-devel] ovirt-cli 3.3.0.1 released
by Michael Pasternak 14 Nov '13

14 Nov '13

- at vm.start() --vm-os-boot doesn't send the order of devices #921464 - rephrase status command help - add option to retrieve system summary #854369 - accept IP address as FQ argument rather than string #886067 - fix broken pipe - Bad error message when trying to create a new Role #908284 - add flag --dont-validate-cert-chain #915231 - collection-based-options could be passed in 2 ways #859684 - make NO_SUCH_ACTION error a bit more clear - ovirt-cli DistributionNotFound exception on f18 #881011 - ovirt-shell misleading help for command "connect" #907943 - show event -id accept strings instead of numeric values #886786 - Use vncviewer passwordFile instead of passwdInput More details can be found at [1]. [1] http://wiki.ovirt.org/Cli-changelog -- Michael Pasternak RedHat, ENG-Virtualization R&D

1 5

[Engine-devel] Error message while trying to delete default cluster
by Shubhendu Tripathi 14 Nov '13

14 Nov '13

Hi, While trying to delete the Default cluster in oVirt it shows the below error message - "Cannot remove default Host Cluster. Cannot remove Cluster. One or more Template(s) are still associated with it" But in the case of RHSC, Templates are not used and this message is not relevant. [1]. Can we opt for not installing the templates while engine setup? And would it be having any impact/consequences ? Kindly provide your thoughts and possibility of the same. Thanks and Regards, Shubhendu PS: [1]: https://bugzilla.redhat.com/show_bug.cgi?id=1019838

2 1

[Engine-devel] Consideration of the permission type
by Piotr Kliczewski 14 Nov '13

14 Nov '13

Hello everyone, I am working on https://bugzilla.redhat.com/show_bug.cgi?id=878812 bug so I played a bit with the code to understand how permission system works and noticed few things (please correct me if I am wrong): - In order to login to admin portal user need to have one of the admin roles (role_type = 1) - system tree is built using number of queries - before running each query permission validation happens so the code checks whether the user is able to run a query - I noticed that none of the queries required to build system tree is admin query and validation depends on result of getUser().isAdmin() (Please check http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=blob;f=backend/manager/… line 123). This statement is always true for a user which was able to log in to admin portal. I was able to come up with following ways to solve this issue (please help to find the good enough): - fix verification - filter results of query - change a bit permission model. The structure is quite flat (there are only 2 role_types) or we could go with containers as it was proposed in bug description. Thanks, Piotr

1 0

[Engine-devel] OpenLdap and Kerberos for oVirt on f19
by Piotr Kliczewski 14 Nov '13

14 Nov '13

Hello everyone, I working on configuring OpenLdap 2.4.36 with kerberos for oVirt running on f19. I follow following instruction: https://bugzilla.redhat.com/show_bug.cgi?id=967327#c5 Please note that the instruction was written for f18. In order to have step 18 working from command line I had to set SASL_NOCANON to off. The reason was that I got: ldap_sasl_interactive_bind_s: Invalid credentials (49) additional info: SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context When SASL_NOCANON is off I can search the ldap but have the same issue from java code: I got javax.naming.AuthenticationException: [LDAP: error code 49 - SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context]. Have this when connecting using engine-manage-domains (http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=blob;f=backend/manager/… line 84). Can you please point me where is my config issue? I copied engine-devel for reference. Thanks, Piotr

2 3

[Engine-devel] daily oVirt 3.3.1 blocker status
by Sandro Bonazzola 14 Nov '13

14 Nov '13

Hi, The following blockers are still not fixed: VDSM: Bug 1022961 - Running a VM from a gluster domain uses mount instead of gluster URI Bug 1022975 - [vdsm] storage domain upgrade fails with attributeError Federico, Eduardo, can you provide an ETA for those? The following patches are targeted 3.3 and needs to be reviewed: http://gerrit.ovirt.org/#/q/branch:%255Eovirt*-3.3.*,n,z vdsm: support VIR_MIGRATE_ABORT_ON_ERROR Peter V. Saveliev vdsm ovirt-3.3 Oct 27 hsm: fix isoprefix KeyError for inactive domains Federico Simoncelli vdsm ovirt-3.3 Oct 20 +1 Read pool metadata once in StoragePool.getInfo() Federico Simoncelli vdsm ovirt-3.3 Oct 15 Make hsm.getVolumesList() pool independent. Federico Simoncelli vdsm ovirt-3.3 Oct 15 Adding [start|stop]MonitoringDomain(). Federico Simoncelli vdsm ovirt-3.3 Oct 15 stats: return domain lockspace status Federico Simoncelli vdsm ovirt-3.3 Oct 15 Make getRepoStats() a hsm method. Federico Simoncelli vdsm ovirt-3.3 Oct 15 Fix getStorageDomainInfo() logic. Federico Simoncelli vdsm ovirt-3.3 Oct 15 vm: add the transient disk support Federico Simoncelli vdsm ovirt-3.3 Oct 15 please review them and merge ASAP the patches meant to be in 3.3.1. I'm not aware of other blockers. If you're aware of any other blocker, please add it to the tracker bug (Bug 1019391 - Tracker: oVirt 3.3.1 release) -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

3 9

[Engine-devel] [QE] bug scrubing / triaging
by Sandro Bonazzola 13 Nov '13

13 Nov '13

Hi, Looking at bugzilla, there are 366 bugs without a target release. Some of them are in POST state but I'm pretty sure they should be in ON_QA or CLOSED state. A lot of them haven't a whiteboard set. Please review the bug list and help to scrub and triage them: https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&… Thanks -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 1

[Engine-devel] Migrating an existing installation to hosted engine
by Yedidyah Bar David 13 Nov '13

13 Nov '13

Hi all, A message with the same subject was sent to arch around a month ago, see [1]. In short, it suggested two approaches: 1. Use p2v (or v2v) 2. Clean install of OS/engine software and use backup/restore. Following that, I pushed a few changes for engine-backup and engine-setup, with the intention of doing, briefly: 1. hosted-engine --deploy on new host 2. Install OS/software on new vm 3. backup on old engine machine 4. On new vm, do restore, which only restores the database and files, followed by engine-setup, which will fix whatever else needs to be fixed. Some of the changes are still pending, and are under some controversy. See [2], [3], [4]. A more detailed description of the suggested migration path is in [5]. What do you think? Should engine-setup do as little as possible to the system, or as much as needed to save the admin from any manual work? Should engine-setup doing an upgrade do the same as a new setup, or just whatever that's needed to adapt the config/database to the new code? A specific example: if admin chose during initial setup to automatically configure the firewall (iptables/firewalld), should upgrade update it again, or not touch it? Should engine-backup do all these things when doing a restore? Should we have some other utility to do these things? Should we merely document them and let the admin do this manually? [1] http://lists.ovirt.org/pipermail/arch/2013-October/001677.html [2] https://bugzilla.redhat.com/1024707 [3] http://gerrit.ovirt.org/20736 [4] http://gerrit.ovirt.org/20737 [5] http://www.ovirt.org/Migrate_to_Hosted_Engine -- Didi

2 1

[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

[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

[Engine-devel] Major frontend refactoring landed into master
by Vojtech Szocs 04 Nov '13

04 Nov '13

Hey guys, I've just merged patch "frontend refactor phase 2" [http://gerrit.ovirt.org/#/c/17356/] into master branch. This is the second patch in a series dedicated to improving parts of frontend code responsible for communication with Engine backend: http://www.ovirt.org/Features/Design/FrontendRefactor If you find any issues related to GUI (WebAdmin, UserPortal) - just let Alex (CC'ed) or me know and we'll fix them. Regards, Vojtech

1 0