- Devel - oVirt List Archives

[QE] oVirt 3.6.0 status
by Sandro Bonazzola 25 Mar '15

25 Mar '15

Hi, here's an update on 3.6 status on integration / rel-eng side The tracker bug for 3.6.0 [1] currently shows no blockers. Repository closure is currently broken due to a missing required dependency on python-blivet, patch fixing this issue is currently under review[4]. There are 577 bugs [2] targeted to 3.6.0. NEW ASSIGNED POST Total docs 11 0 0 11 external 1 0 0 1 gluster 49 2 2 53 i18n 2 0 0 2 infra 77 6 9 92 integration 59 6 5 70 network 41 1 9 51 node 27 3 2 32 ppc 0 0 1 1 sla 51 3 2 56 spice 1 0 0 1 storage 72 5 8 85 ux 31 0 2 33 virt 74 5 10 89 Total 496 31 50 577 Features submission is still open until 2015-04-22 as per current release schedule. Maintainers: be sure to have your features tracked in the google doc[3] [1] https://bugzilla.redhat.com/1155425 [2] https://bugzilla.redhat.com/buglist.cgi?quicksearch=target_release%3A3.6.0%… [3] http://goo.gl/9X3G49 [4] https://gerrit.ovirt.org/38942 -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 0

duplicate upgrade scripts -- cannot upgrade db on master
by Greg Sheremeta 24 Mar '15

24 Mar '15

Hi Alona and Roy, These commits used the same script number, and the database cannot be upgraded on master. Thanks, Greg commit 354ebb2ac024014987c66d73aa591e749c79fd19 Author: Roy Golan <rgolan(a)redhat.com> Date: Thu Mar 5 00:50:46 2015 +0200 core: add creation_date to permissions entity Change-Id: Iedaf56522fc2af4c4cc8da9f5c1c2572fe4de706 Bug-Url: https://bugzilla.redhat.com/1080029 Signed-off-by: Roy Golan <rgolan(a)redhat.com> M backend/manager/modules/common/src/main/java/org/ovirt/engine/core/common/businessentities/Permission.java M backend/manager/modules/dal/src/main/java/org/ovirt/engine/core/dao/PermissionDAODbFacadeImpl.java M backend/manager/modules/dal/src/test/java/org/ovirt/engine/core/dao/PermissionDAOTest.java M backend/manager/modules/dal/src/test/resources/fixtures.xml M packaging/dbscripts/create_views.sql A packaging/dbscripts/upgrade/03_06_1100_add_creation_date_to_permissions.sql commit fb079a64ea6be2a5400a67cd8468e162c52f93c9 Author: Alona Kaplan <alkaplan(a)redhat.com> Date: Tue Mar 24 10:11:49 2015 +0200 engine: CRUD actions for HostNicVfsConfig Introducing new table- HostNicVfsConfig and adding crud actions for this table. Change-Id: I022a1d19d935832a8baae41c123322dff0ab779b Signed-off-by: Alona Kaplan <alkaplan(a)redhat.com> M backend/manager/modules/dal/src/main/java/org/ovirt/engine/core/dal/dbbroker/DbFacade.java A backend/manager/modules/dal/src/main/java/org/ovirt/engine/core/dao/network/HostNicVfsConfigDao.java A backend/manager/modules/dal/src/main/java/org/ovirt/engine/core/dao/network/HostNicVfsConfigDaoDbFacadeImpl.java M backend/manager/modules/dal/src/main/jdbc-resources/engine-daos.properties M backend/manager/modules/dal/src/test/java/org/ovirt/engine/core/dao/FixturesTool.java A backend/manager/modules/dal/src/test/java/org/ovirt/engine/core/dao/network/HostNicVfsConfigDaoTest.java M backend/manager/modules/dal/src/test/resources/fixtures.xml M packaging/dbscripts/network_sp.sql A packaging/dbscripts/upgrade/03_06_1100_add_host_nic_vfs_config_table.sql Greg Sheremeta Red Hat, Inc. Sr. Software Engineer, RHEV Cell: 919-807-1086 gshereme(a)redhat.com

2 2

Two upgrade scripts 03_06_1100 in master
by Vered Volansky 24 Mar '15

24 Mar '15

1 1

searching by tags
by Einav Cohen 24 Mar '15

24 Mar '15

Hi, AFAIR, we used to support a hierarchical search by tag. i.e. if I had a parent tag "Europe", and it had child-tags "Italy" and "UK", a search such as: "VMs: tag=Europe" would have returned VMs that are tagged with "Europe" as well as VMs tagged with any child-tags of "Europe" (i.e. VMs that are tagged with "UK" or "Italy"); however, this doesn't seem to be the case anymore [see http://i.imgur.com/85rZbZj.png] [I am running master from ~3 weeks ago] Any idea why? Thanks. ---- Regards, Einav

3 4

Default virt lock manager and Sanlock for Hosted Engine HA
by Sandro Bonazzola 24 Mar '15

24 Mar '15

Hi, while working on a patch for hosted engine[1] it has been raised an objection about limiting the use of sanlock as lock manager to the Hosted Engine VM only. "the ha should dynamically set libvirt if possible, or we need to also revert this part if disabled. also, if ever vdsm will require to configure this file we will have a race which is not healthy. it seems that you can define domain and per domain setting and assign your vm to that domain instead of effecting entire host." But looking at Fedora Virt Lock Manager feature[2] looks like we should configure libvirt for using sanlock by default and not only for Hosted Engine HA. If we decide that we should keep the default lockd manager instead of the sanlock one I wpuld like to ask virt team which is the best way for setting sanlock only for the hosted engine VM. I've seen I can change the libvirt xml using a vdsm hook and pass command line options to qemu[3] but I can't see an option to pass to qemu-kvm for that. There was also an ongoing discussion about locking per disk / per vm on the storage team part, so maybe this is not the best way to get this done after all. What do you think / suggest? [1] https://gerrit.ovirt.org/38547 [2] https://fedoraproject.org/wiki/Features/VirtLockManager [3] http://blog.vmsplice.net/2011/04/how-to-pass-qemu-command-line-options.html -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

3 4

oVirt Node Weekly Meeting Minutes -- 2015-03-23
by Fabian Deutsch 23 Mar '15

23 Mar '15

Minutes: http://ovirt.org/meetings/ovirt/2015/ovirt.2015-03-23-15.00.html Minutes (text): http://ovirt.org/meetings/ovirt/2015/ovirt.2015-03-23-15.00.txt Log: http://ovirt.org/meetings/ovirt/2015/ovirt.2015-03-23-15.00.log.html ================================= #ovirt: oVirt Node Weekly Meeting ================================= Meeting started by fabiand at 15:00:44 UTC. The full logs are available at http://ovirt.org/meetings/ovirt/2015/ovirt.2015-03-23-15.00.log.html . Meeting summary --------------- * Agenda (fabiand, 15:00:59) * oVirt 3.5 (fabiand, 15:01:24) * oVirt 3.6 planning (fabiand, 15:01:32) * Jenkins and CI progress (fabiand, 15:01:38) * Other Items (fabiand, 15:01:40) * oVirt 3.5 (fabiand, 15:03:05) * Node team provided some stabilizatin patches for 3.5.2, all merged in 3.5 branch (fabiand, 15:04:01) * Issue wih the current 3.5 release: No ovirt-node rpms were published, is bad and makes building isos a little bit harder (at least when they should be specific to some release) (fabiand, 15:06:26) * livecd-tools dependency was missing (fabiand, 15:06:38) * Builders for the ovirt-node related rpms were added (fabiand, 15:07:30) * 3.5 builders cover el6 el7 and f20 (fabiand, 15:09:24) * Not all publishers for buidlers are ready yet (fabiand, 15:09:36) * ACTION: tlitovsk and dougsland to collaborate to add the remaining publishers for the remiaining unpublished rpms (fabiand, 15:13:13) * the remaining plugin which is not published on a daily basis is the ovirt-node-plugin-vdsm (fabiand, 15:16:26) * Pure 3.5 and master isos will be the result of the builder and publisher cleanup (fabiand, 15:19:46) * oVirt 3.6 (fabiand, 15:20:15) * The hackathon covered importnat items for 3.6 (fabiand, 15:20:46) * Cockpit migration (fabiand, 15:20:54) * Part of 3.6 is to move to web management instead of the TUI, done via Cockpit (fabiand, 15:23:14) * Creating wrappers around the existing configuration classes seemed to be very "hacky" and wouldn't get us away from some of the problems we have now (fabiand, 15:25:28) * Additionally, calling out to the shell doesn't provide any reasonable feedback to the web UI (fabiand, 15:26:08) * Config classes are offered over native dbus now (fabiand, 15:28:37) * Upstream repository got created for the ovirt-node-dbus-backend (fabiand, 15:28:48) * ovirt-node-dbus-backend is some unit file, with some python code consuming the existing ovirt-node config classes (fabiand, 15:29:36) * rbarry took care of ovirt-node-dbus-acbkend (fabiand, 15:31:07) * dougsland factored out the python files related to performing host configuration into a subpackage, which is required by ovirt-node-dbus-backend (fabiand, 15:31:40) * dbus backend has the automation files, but is missing the yaml job specififcation (fabiand, 15:37:46) * ACTION: rbarry to finish builders/publishers for the ovirt-node-dbus-backend package (fabiand, 15:38:39) * fabiand created a Node appliance basedon CentOS 7, and changed the Engine ppliance to also be based on CentOS 7 (fabiand, 15:40:59) * Node appliance is planned to provide all the node bits for 3.6 - cockpit, ovirt-node-lib-config … (fabiand, 15:41:28) * Jenkins and CI progress (fabiand, 15:42:46) * no visual progress on CI, but it' s not forgotten. (fabiand, 15:44:10) * Other Items (fabiand, 15:45:05) Meeting ended at 15:46:09 UTC. Action Items ------------ * tlitovsk and dougsland to collaborate to add the remaining publishers for the remiaining unpublished rpms * rbarry to finish builders/publishers for the ovirt-node-dbus-backend package Action Items, by person ----------------------- * dougsland * tlitovsk and dougsland to collaborate to add the remaining publishers for the remiaining unpublished rpms * rbarry * rbarry to finish builders/publishers for the ovirt-node-dbus-backend package * tlitovsk * tlitovsk and dougsland to collaborate to add the remaining publishers for the remiaining unpublished rpms * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * fabiand (111) * tlitovsk (33) * rbarry (22) * dougsland (20) * ovirtbot (2) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot

1 0

[ACTION REQUESTED] new tooltips! don't use title='tooltip' anymore
by Greg Sheremeta 22 Mar '15

22 Mar '15

Hi, TL;DR: there are new tooltip classes. Please only use the new stuff going forward. ... A bunch of patches were merged this week that converted every tooltip in ovirt-engine to use PatternFly (Bootstrap3) tooltips. Examples: [1] Since we want to keep all of the tooltips looking the same, please don't use DecoratedPanels or title attributes for tooltips anymore. Going forward, you must use the WidgetTooltip class (if you're putting a tooltip on a Widget), or the built in getTooltip() template method if you're providing a tooltip in a grid. [2] As part of this effort, I did some cleanup / refactoring to the Cell and Column infrastructure. A few noteworthy things: * All custom Cells that simply provided some variation of tooltip behavior were removed. Tooltips are now provided for free by the root objects in the Cell and Column hierarchy. * Almost all Columns use the template-method pattern for rendering a tooltip. Simply override the getTooltip method with tooltip contents. 'null' is ok (means no tooltip). * Cells also use the same template-method pattern for supporting a tooltip render, but tooltips should render in Columns wherever possible. Only use direct Cell rendering if absolutely necessary -- for example, in CompositeCells. * Text truncation behavior now lives in TextCell. There are two truncation methods -- fixed length limit, or CSS overflow-based. Text that is truncated will show in a tooltip, unless a manual tooltip is provided on that Column. (In other words, if text is too long to fit in a column, '...' will appear and a tooltip will show the full contents. Unless you override that behavior by setting your own tooltip in getTooltip().) * The Element ID Framework is fully integrated now. All Cell render methods are passed a unique ID. Please use it in your render. This helps with automated tests. Some code examples: in UIBinder: <t:WidgetTooltip ui:field="tooltip"> <g:SomeWidget ...> </t:WidgetTooltip> ... @UiField WidgetTooltip tooltip; ... tooltip.setHtml(someToolipValue); tooltip.reconfigure(); in a Column: @Override public SafeHtml getTooltip(XXXX object) { String tooltipContent = object.someProperty(); return SafeHtmlUtils.fromString(tooltipContent); } or, if a constant tooltip: @Override public SafeHtml getTooltip(XXXX object) { return SafeHtmlUtils.fromTrustedConstant(constants.someConstant()); } Let me know if there are any questions, or if you see any bugs! Thanks, Greg [1] http://i.imgur.com/rZ5oIIb.png http://i.imgur.com/6lpKuSD.png http://i.imgur.com/hYcZSuT.png http://i.imgur.com/9oKZnK4.png [2] you can also put a tooltip on an Element, but try to use a Widget if you can. See TooltipMixin::addTooltipToElement() Greg Sheremeta Red Hat, Inc. Sr. Software Engineer, RHEV Cell: 919-807-1086 gshereme(a)redhat.com

2 1

Adding dependency on glusterfs-3.7dev for vdsm-gluster patch.
by Darshan Narayana Murthy 20 Mar '15

20 Mar '15

Hi All, In the vdsm-gluster patch [1] we will be adding a dependency on glusterfs-3.7dev(alfa) as the dependent feature was added to glusterfs recently and its not present in any release of glusterfs. Since glusterfs-3.7dev is alfa, vdsm-gluster package installation will not directly pull this package. Users have to manually add the repo for getting this package. Repo for glusterfs-3.7dev can be added by installing suitable (depending on your os and its version) rpm located at [2]. For example install the rpm dgo-nightly-master-1.0-0.1.fc20.noarch.rpm located at [2] if your os is fedora-20. [1] https://gerrit.ovirt.org/#/c/38444/ [2] http://download.gluster.org/pub/gluster/glusterfs/nightly/glusterfs/ Regards, Darshan N

2 1

New QEMU package landing on master snapshot
by Sandro Bonazzola 20 Mar '15

20 Mar '15

Hi, qemu-kvm-ev-2.1.2-23 for EL7 from RHOS is landing on ovirt-master-snapshot repository today. It will obsolete qemu-kvm-rhev-1.5.3-60 currently provided by CentOS. The package has been requested for fixing Bug 1199014 - RHEV [RHEL7.1] - Require qemu fix for "Cannot start VMs that have more than 23 snapshots" The package is also available from CentOS Virt SIG repository: http://cbs.centos.org/repos/virt7-testing/x86_64/os/ Help testing the new rpm is welcome. -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 0

Database layout for vm icons
by Jakub Niedermertl 19 Mar '15

19 Mar '15

Hi all, I post a conversation with Eli regarding vm icons (and screenhots) there to find wide agreement on database layout. Requirements are summarized in conversation below. Based on discussion with Eli and later with Tomas and Michal the current proposal corresponds to option (3) at https://www.lucidchart.com/documents/view/b6dbbcde-d2f5-4594-b265-6c70918ac… . Mapping to business entities: VmIcon class corresponding to vm_icons table, icon_info and vm_static tables are transparently joined to VmBase class. Reasoning: * there are no loop references that developer don't like and my perform badly in case only small (i.e. not directly referenced) icon is required (no for option (2)) * it is clean, easy to maintain, saves number of columns in vm_static table (compared to option (1)), related things are grouped together * icon_info is joined into VmBase in order to avoid complicated caching and invalidation using timestamps (if it depends on timstamp of vm_static then unnecessary refreshes can happen, if it depends on extra timestamp in vm_static extra column is needed; and besides it brings unnecessary complexity) I'll be glad for any comments. Best regards Jakub ----- Forwarded Message ----- From: "Jakub Niedermertl" <jniederm(a)redhat.com> To: "Eli Mesika" <emesika(a)redhat.com> Sent: Wednesday, March 18, 2015 4:44:50 PM Subject: Re: Database layout for vm icons I assume, based on your answer, that list of requirements was not complete (sorry for that). Other requirements are: * if screenshot is not availble: basic userportal list shows large icons of all available VMs * if screenshot is availble: basic userportal list shows small icons and small screenshots of all available VMS * each of 'New VM', 'Edit VM', 'Edit Template', 'New Pool', 'Edit Pool' dialog requests one or two large icons during its opening - these dialogs contains (sometimes disabled yet visible) icon editor widget, dialogs can be invoked form extended userportal or webadmin * icons are large (about 20kB each for png format), hence images (icons and screenshots) are cached using their guid as a key. Each image is requested at most once. * images are downloaded on demand * ids of predefined (associated wit operating systems) icons are precached on clients because they can't be changed while engine is running Plus there are general assumptions: * queries to server (= engine) are expensive (especially sequence of dependent queries) * database joins are expensive So: * each update of basic userportal requires to resolve large icon ids of all available icons or (small icon ids plus small screenshot ids) * each update of extended userportal reuqires to resolve all small icon ids * graphics needs to be downloaded anyway, the problem is how to get ids of images * the overall performance can depend on what users do: how many VMs have custom id, how many VMs has screenshot * I'd like to extend my question from db layout to also how db layouts should be mapped to BE. ----- Original Message ----- > From: "Eli Mesika" <emesika(a)redhat.com> > To: "Jakub Niedermertl" <jniederm(a)redhat.com> > Cc: "Oved Ourfali" <oourfali(a)redhat.com> > Sent: Wednesday, March 18, 2015 2:14:05 PM > Subject: Re: Database layout for vm icons > > > > ----- Original Message ----- > > From: "Jakub Niedermertl" <jniederm(a)redhat.com> > > To: "Eli Mesika" <emesika(a)redhat.com> > > Sent: Tuesday, March 17, 2015 7:28:13 PM > > Subject: Database layout for vm icons > > > > Hi Eli, > > > > I'm working on VM icons feature (http://www.ovirt.org/Features/VM_Icons) > > customizable icons for userportal. This feature should by followed by vm > > screenshots. I'd like to discuss db layout for storing icons (and > > screenshots) since you will probably review the db related part. > > > > Requirements are approximately following: > > * there are default icons (provided by us, undeletable) derived from > > selected > > operating system (like Tux, Windows, ...) and custom icons (uploaded by > > users) > > * all icons are stored in db > > * there are two sizes for each icon (small and large), small one is > > generally > > different image from large one, not just a scale > > * there are screenshots stored in same table as icons > > * there are two sizes of each screenshot (small and large) - just scaled > > image > > * each vm has exactly one icon pair (small and large): default (derived > > from > > os) or custom (uploaded by user) > > * each vm has at most one screenshot pair (small and large) > > * data in vm_icons table has to be > > - either referenced from other table, i.e. used > > - or marked as default_for_os by operating system identifier > > i.e. table doesn't contain any library of unused icons > > > > What would you suggest as most suitable layout? > > > > I prepared three options at > > https://www.lucidchart.com/documents/view/b6dbbcde-d2f5-4594-b265-6c70918ac… > > > > 1) The most natural one. It consumes many columns in vm_static table. > > I don't like adding that which imply adding that to the VM BE and returning > those fields also from the web admin. > This performs best. No need for db joins or additional queries to get image ids. > > > > 2) Only large icons (and screenshots) are referenced from vm_static, small > > versions are referenced from the large version. The advantage is that > > information about the pair is contained in one table, disadvantage is that > > many developers doesn't like loop references. > > This is a hybrid solution that uses loops as you stated and I am not a hybrid > not loops (which performs bad) in the database It performs as (1) i.e. well for opening dialogs, basic userportal without screenshot. For extended userportal or basic userportal with many screenshots it requires one additional bulk query to resolve small icon ids (such query generally can't be cached until assumption that small icon can't be changed without changing large icon is accepted). Or VmBase entity can be mapped using joins to vm_static and vm_icons - no additional query but join for VmBase retireve. > > > > > 3) Optimization of multiple columns used in version 1, it breaks 3. normal > > form. > > I would go for that, only additional field in vm_static that points to the > info , web admin stayed as is and only in user portal you will pay for > getting the additional information. > If icon_info table has separate BE then there is additional query to resolve image ids all the time. If icon_info table is joined into VmBase entity then there is an additional join all the time. > > > > Thanks for advice. > > > > Best regards. > > Jakub > > > Taking into account aforementioned facts, what solution do you consider the best. Thanks for advice. Best regards Jakub

1 0