- Devel - oVirt List Archives

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

Broken dependency for VDSM
by Sandro Bonazzola 19 Mar '15

19 Mar '15

Hi, a recent change introduced a dependency on python-blivet >= 0.61.14 which is not available at least on Fedora 20 Please provide the required package or ask fedora maintainer to backport to Fedora 20. http://koji.fedoraproject.org/koji/packageinfo?packageID=15389 -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

5 6

Updates on the oVirt Appliances (installation of engine and node)
by Fabian Deutsch 19 Mar '15

19 Mar '15

Hey, lately I've updated the oVirt Engine appliance image to be based on CentOS 7, to get away from breakage which came from the fast moving forward Fedora (previously the appliance was based on Fedora). Besides of that I've simplified the kickstart and Tolik added support for cloud-init, which will hopefully help to pave the way for a better integration into hosted-engine. Another thing I've been working was to simplify the installation of the appliance in use cases outside of hosted-engine. Why? Because the Engine appliance image is a good way to start testing and using Engine. It is an installed OS (CentOS 7) with all the necessary repos set up, and engine installed. Ready to run `engine-setup --offline --config-append=ovirt-engine-answers` to get engine set up. So why not simplify the consumption of this nice image for everybody? This small job [0] builds an ISO [1] with a boot menu, which can be used to install the Engine appliance [2] directly into a VM or onto a real host. During the installation you can set a root password which you can then use after installation to log in. Please note that all the relevant files (installer + os image) are pulled from Jenkins, so the time to install heavily depends on your internet connection. For me it takes ~20min to get from a fresh VM until Engine is running. When you run the ISO [1] you might also see the option to install Node. It's not the classical Node, it's rather a Node appliance [3], based on CentOS 7, containing vdsm, glusterfs and cockpit (all from the upstream sources with the latest bits). The appliance was simple to create is mainly a way to get the latest upstream bit's in a clean environment, to test our Node team cockpit move. For me it took also roughly ~20min to get this appliance up and running. You can mirror/cache the images locally if you want to speed up this process. Theoretically that appliance can be used as a host for Engine, but in my initial trials I failed to attach the node to Engine. But we can probably fix that in future. This is more research and work in progress. But I am surely interested to make this mature in future. One important step is to get the anaconda installer images from CentOS 7.1. The CentOS 7.0 installer images are very outdated [4] and I can not use them. Temporarily I'm using the Fedora anaconda images, but that has other drawbacks [5]. As a last note I can tell that at least the node appliance has some testing (installation), but should gain more. So take all of this with care, but feel free to experiment with the boot iso and roll out your own Engine instances. Help to fix the node appliance and feedback in general is welcome. - fabian -- [0] http://jenkins.ovirt.org/job/fabiand_boo_build_testing/ [1] http://jenkins.ovirt.org/job/fabiand_boo_build_testing/lastSuccessfulBuild/… [2] http://jenkins.ovirt.org/job/ovirt-appliance_engine-3.5_master_merged/ [3] http://jenkins.ovirt.org/job/ovirt-appliance_node-3.5_master_merged/ [4] http://bugs.centos.org/view.php?id=8239 [5] https://bugzilla.redhat.com/show_bug.cgi?id=1145130

1 0