March 2015 - Devel - oVirt List Archives

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

introduce AssetProvider (huge refactor)
by Greg Sheremeta 19 Mar '15

19 Mar '15

Hi all, [1] just landed in master. This patch introduces an AssetManager that should always be used to get access to messages, constants, templates, and resources. No more GWT.creating or @Injecting them into constructors and passing them around. If you need access to an asset in a class, use one of the following lines of code to get at the singleton: (in webadmin and userportal) private final static ApplicationTemplates templates = AssetProvider.getTemplates(); private final static ApplicationResources resources = AssetProvider.getResources(); private final static ApplicationConstants constants = AssetProvider.getConstants(); private final static ApplicationMessages messages = AssetProvider.getMessages(); (in gwt-common) private final static CommonApplicationTemplates templates = AssetProvider.getTemplates(); private final static CommonApplicationResources resources = AssetProvider.getResources(); private final static CommonApplicationConstants constants = AssetProvider.getConstants(); private final static CommonApplicationMessages messages = AssetProvider.getMessages(); (Please keep these standard variable names -- i.e., don't name them "TEMPLATES" or "commonConstants", etc. If you have a frontend patch pending, your rebase probably won't be clean. This patch touches over 700 files :) Thanks! Greg [1] https://gerrit.ovirt.org/#/c/38724/ (userportal, webadmin: introduce AssetProvider) Greg Sheremeta Red Hat, Inc. Sr. Software Engineer, RHEV Cell: 919-807-1086 gshereme(a)redhat.com

1 0

[ANN] oVirt 3.5.2 Second Release Candidate is now available for testing
by Sandro Bonazzola 18 Mar '15

18 Mar '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The oVirt team is pleased to announce that the 3.5.2 Second Release Candidate is now available for testing as of Mar 18th 2015. The release candidate is available now for Fedora 20, Red Hat Enterprise Linux 6.6, CentOS 6.6 (or similar) and Red Hat Enterprise Linux 7.1, CentOS 7 (or similar). This release of oVirt includes numerous bug fixes. See the release notes [1] for a list of the new features and bugs fixed. Please refer to release notes [1] for Installation / Upgrade instructions. New oVirt Live and oVirt Node ISO will be available soon as well[2]. Please note that mirrors[3] may need usually one day before being synchronized. Please refer to the release notes for known issues in this release. [1] http://www.ovirt.org/OVirt_3.5.2_Release_Notes [2] http://resources.ovirt.org/pub/ovirt-3.5-pre/iso/ [3] http://www.ovirt.org/Repository_mirrors#Current_mirrors - -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJVCZq1AAoJEHw3u57E4QAOmj8P/2Nn3OcRKErMFXJLXeqZHaEi vhk9MEiaSKMuPSLAfigvhAX5133czXlv1qmcLP8zQ4yqXdbkBXHptFQXWGRsFmH5 zhmy9bqUUlDFIcepMWw5Rm+LZRWKWwUVQUijnpah1l6d6w0YJoqy8hZxgeFtaFna ytDlVBHpvLCubbjmCWRibOFd80P+z2pSk31/Y4k0vi/UIwMGnXO74vkBU+mzLuZO mHVLueQjJORe6jEwoBeFFnen1QI/+uCpCCSm+inHoiSGxISnujhoZT1T9DmOPFJT 2i0cd7QnxmMo/aY8EoIEagCGXsIravgSW6NmrAXbJfKQ4NrylaAD/mfDhQy0tZLt fRnANlDV2aHqdE0Cfw5LjzgOHgLrtG8cSCXL40tQI+/HGh1Av4OjnJQDbWL7dMIR rxXn4t/hicIYPy17SM/+qo/2/2BSgR1jro17WgIn6nxAsV3YiXbHghRJ+uJRxFCJ a8fT4vReHExRASdjjw+KMF0O3o4sqjd7ldX4aTDtuaEojYc3ducZVZDIT/L3SFPP o+S6cWggWL/VZ7Ormts3Fkz6Il/pMAAre7NEuAk8gtARukmrMoBTz88TvvTQlNXg ttynkryL/bPE6xsQ6nQbR0c7Iks3cYyg1T1VF7rbQyjD56X2wKJPCe+lX7Id0KqT sJ5UIcdDI5VCHCElWzih =QuV3 -----END PGP SIGNATURE-----

1 0

[ACTION REQUIRED] Packages changed since oVirt 3.5.2 RC1
by Sandro Bonazzola 18 Mar '15

18 Mar '15

# Package changed since oVirt 3.5.2 RC1 # oVirt Engine: # hash: e839f03 - core: frontend: Fix Permissions.id value on instance creattion http://jenkins.ovirt.org/job/manual-build-tarball/491/ #Python SDK: https://jhernand.fedorapeople.org/rpms/ovirt-engine-sdk-python/3.5.2.1-1/ #Java SDK: https://jhernand.fedorapeople.org/rpms/ovirt-engine-sdk-java/3.5.2.1-1/ #oVirt Optimizer http://jenkins.ovirt.org/job/ovirt-optimizer_master_create-rpms_merged/61/ # VDSM: # hash: * f57be0f - network: persistence: skip bonds owned and used by vdsm http://jenkins.ovirt.org/job/manual-build-tarball/493/ Please review and raise any issue as soon as possible. We're starting to compose the repository. -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 0

[ACTION REQUIRED] oVirt 3.5.2 and 3.5.3 status (building RC2 today!)
by Sandro Bonazzola 18 Mar '15

18 Mar '15

Hi, we still have 5 open blockers for 3.5.2[1]: Bug ID Whiteboard Status Summary 1161012 infra POST task cleaning utility should erase commands that have running tasks 1187244 network POST [RHEL 7.0 + 7.1] Host configure with DHCP is losing connectivity after some time - dhclient is not running 1177220 storage ASSIGNED [BLOCKED] Failed to Delete First snapshot with live merge 1196327 virt ASSIGNED [performance] bad getVMList output creates unnecessary calls from Engine 1202360 virt POST [performance] bad getVMList output creates unnecessary calls from Engine And 2 dependency on libvirt not yet fixed: Bug ID Status Summary 1199182 POST 2nd active commit after snapshot triggers qemu failure 1199036 POST Libvirtd was restarted when do active blockcommit while there is a blockpull job running ACTION: Assignee to provide ETA for the blocker bug. Despite the blockers bug count, we're going to build RC2 today 2015-03-18 at 12:00 UTC for allowing the verification of fixed bugs and testing on CentOS 7.1. If you're going to test this release candidate on CentOS please be sure to have the CR[2] repository enabled and system fully updated to CentOS 7.1. We still have 7 bugs in MODIFIED and 31 on QA[3]: MODIFIED ON_QA Total infra 2 10 12 integration 0 2 2 network 0 2 2 node 0 1 1 sla 2 1 3 storage 3 11 14 virt 0 4 4 Total 7 31 38 ACTION: Testers: you're welcome to verify bugs currently ON_QA. All remaining bugs not marked as blockers have been moved to 3.5.3. A release management entry has been added for tracking the schedule of 3.5.3[4] A bug tracker [5] has been created for 3.5.3. We have 32 bugs currently targeted to 3.5.3[6]: Whiteboard NEW ASSIGNED POST Total docs 2 0 0 2 external 1 0 0 1 gluster 4 0 1 5 infra 2 2 0 4 node 2 0 1 3 ppc 0 0 1 1 sla 4 0 0 4 storage 8 0 0 8 ux 1 0 1 2 virt 1 0 1 2 Total 25 2 5 32 ACTION: Maintainers / Assignee: to review the bugs targeted to 3.5.3 ensuring they're correctly targeted. ACTION: Maintainers: to fill release notes for 3.5.2, the page has been created and updated here [7] ACTION: Testers: please add yourself to the test page [8] 7 Patches have been merged for 3.5.3 and not backported to 3.5.2 branch according to Change-Id commit 6b5a8169093357656d3e638c7018ee516d1f44bd Author: Maor Lipchuk <mlipchuk(a)redhat.com> Date: Thu Feb 19 14:40:23 2015 +0200 core: Add validation when Storage Domain is blocked. Change-Id: I9a7c12609b3780c74396dab6edf26e4deaff490f commit 7fd4dca0a7fb15d3e9179457f1f2aea6c727d325 Author: Maor Lipchuk <mlipchuk(a)redhat.com> Date: Sun Mar 1 17:17:16 2015 +0200 restapi: reconfigure values on import data Storage Domain. Change-Id: I2ef7baa850bd6da08ae27d41ebe9e4ad525fbe9b commit 4283f755e6b77995247ecb9ddd904139bc8c322c Author: Maor Lipchuk <mlipchuk(a)redhat.com> Date: Tue Mar 10 12:05:05 2015 +0200 restapi: Quering FCP unregistered Storage Domains Change-Id: Iafe2f2afcd0e6e68adbbbb2054c857388acc30a7 commit a3d8b687620817b38a64a3917f4440274831bca3 Author: Maor Lipchuk <mlipchuk(a)redhat.com> Date: Wed Feb 25 17:00:47 2015 +0200 core: Add fk constraint on vm_interface_statistics Change-Id: I53cf2737ef91cf967c93990fcb237f6c4e12a8f8 commit c8caaceb6b1678c702961d298b3d6c48183d9390 Author: emesika <emesika(a)redhat.com> Date: Mon Mar 9 18:01:58 2015 +0200 core: do not use distinct if sort expr have func Change-Id: I7c036b2b9ee94266b6e3df54f2c50167e454ed6a commit 4332194e55ad40eee423e8611eceb95fd59dac7e Author: Vered Volansky <vvolansk(a)redhat.com> Date: Thu Mar 12 17:38:35 2015 +0200 webadmin: Fix punctuation in threshold warnings Change-Id: If30f094e52f42b78537e215a2699cf74c248bd83 commit 773f2a108ce18e0029f864c8748d7068b71f8ff3 Author: Maor Lipchuk <mlipchuk(a)redhat.com> Date: Sat Feb 28 11:37:26 2015 +0200 core: Add managed devices to OVF Change-Id: Ie0e912c9b2950f1461ae95f4704f18b818b83a3b ACTION: Authors please verify they're not meant to be targeted to 3.5.2. [1] https://bugzilla.redhat.com/1186161 [2] http://mirror.centos.org/centos/7/cr/x86_64/ [3] http://goo.gl/UEVTCf [4] http://www.ovirt.org/OVirt_3.5.z_Release_Management#oVirt_3.5.3 [5] https://bugzilla.redhat.com/1198142 [6] https://bugzilla.redhat.com/buglist.cgi?quicksearch=product%3Aovirt%20targe… [7] http://www.ovirt.org/OVirt_3.5.2_Release_Notes [8] http://www.ovirt.org/Testing/oVirt_3.5.2_Testing -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

3 2

openstack-java-sdk - version 3.1.1 availability
by Daniel Erez 18 Mar '15

18 Mar '15

Hi, oVirt engine is now using openstack-java-sdk version 3.1.1 [1]. The new version RPM packages are available as part of the 'ovirt-master-snapshot-static' repository [2]. The new jars can be found at the maven central repository [3]. [1] https://gerrit.ovirt.org/#/c/38741/ [2] http://resources.ovirt.org/pub/ovirt-master-snapshot-static/rpm/fc20/noarch/ [3] http://central.maven.org/maven2/com/woorea/ Regards, Daniel

3 2