- Devel - oVirt List Archives

oVirt metrics
by Yaniv Bronheim 14 Jul '16

14 Jul '16

Hi, In oVirt-4.0 we introduced integration with metrics collectors, In [1] you will find a guide for utilizing your environment to retrieve visualized reports about hosts and vms statistics. I encourage to try that out and send us requests for additional valuable metrics that you think vdsm should publish. This area is still work in progress and we plan to support more technologies and different architectures for metrics collections as describes in the post. This will follow by additional links in the post ([1]) that describe how to do so.. stay tuned. [1] https://bronhaim.wordpress.com/2016/06/26/ovirt-metrics <https://bronhaim.wordpress.com/2016/06/26/ovirt-metrics/>-- *Yaniv Bronhaim.*

4 3

[ACTION REQUIRED] broken dependency with vdsm git6e84643
by Sandro Bonazzola 13 Jul '16

13 Jul '16

DEBUG util.py:417: Error: Package: vdsm-4.18.999-232.git6e84643.el7.centos.x86_64 (ovirt-master-snapshot) DEBUG util.py:417: Requires: safelease >= 1.0-7 DEBUG util.py:417: Available: safelease-1.0-5.el7.x86_64 (centos-epel) DEBUG util.py:417: safelease = 1.0-5.el7 -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

5 7

[ANN] oVirt 4.0.1 Second Release candidate is now available for testing
by Sandro Bonazzola 13 Jul '16

13 Jul '16

The oVirt Project is pleased to announce the availability of the Second Release Candidate of oVirt 4.0.1 for testing, as of July 13th, 2016. This is pre-release software. Please take a look at our community page[1] to know how to ask questions and interact with developers and users. All issues or bugs should be reported via oVirt Bugzilla[2]. This pre-release should not to be used in production. This release is available now for: * Fedora 23 (tech preview) * Red Hat Enterprise Linux 7.2 or later * CentOS Linux (or similar) 7.2 or later This release supports Hypervisor Hosts running: * Red Hat Enterprise Linux 7.2 or later * CentOS Linux (or similar) 7.2 or later * Fedora 23 (tech preview) * oVirt Next Generation Node 4.0 See the release notes draft [3] for installation / upgrade instructions and a list of new features and bugs fixed. Notes: * A new oVirt Live ISO is already available [4]. * A new oVirt Next Generation Node will be available soon [4] * A new oVirt Engine Appliance wil be available soon. * Mirrors[5] might need up to one day to synchronize. Additional Resources: * Read more about the oVirt 4.0.1 release candidate highlights: http://www.ovirt.org/release/4.0.1/ * Get more oVirt Project updates on Twitter: https://twitter.com/ovirt * Check out the latest project news on the oVirt blog: http://www.ovirt.org/blog/ [1] https://www.ovirt.org/community/ [2] https://bugzilla.redhat.com/enter_bug.cgi?classification=oVirt [3] http://www.ovirt.org/release/4.0.1/ [4] http://resources.ovirt.org/pub/ovirt-4.0-pre/iso/ [5] 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

1 0

[ACTION REQUIRED] oVirt 4.0.1 RC2 build starting
by Sandro Bonazzola 12 Jul '16

12 Jul '16

Fyi oVirt products maintainers, An oVirt build for an official release is going to start right now. If you're a maintainer for any of the projects included in oVirt distribution and you have changes in your package ready to be released please: - bump version and release to be GA ready - tag your release within git (implies a GitHub Release to be automatically created) - build your packages within jenkins / koji / copr / whatever - verify all bugs on MODIFIED have target release and target milestone set. - add your builds to releng-tools/releases/ovirt-4.0.1_rc2.conf within releng-tools project Thanks, -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 0

Caching of data from the database done properly
by Roman Mohr 12 Jul '16

12 Jul '16

Hi Everyone, I wanted to discuss a practice which seems to be pretty common in the engine which I find very limiting, dangerous and for some things it can even be a blocker. There are several places in the engine where we are using maps as cache in singletons to avoid reloading data from the database. Two prominent ones are the QuotaManager[1] and the MacPoolPerCluster[2]. While it looks tempting to just use a map as cache, add some locks around it and create an injectable singleton, this has some drawbacks: 1) We have an autoritative source for our data and it offers transactions to take care of inconsistencies or parallel updates. Doing all that in a service again duplicates this. 2) Caching on the service layer is definitely not a good idea. It can introduce unwanted side effects when someone invokes the DAOs directly. 3) The point is more about the question if a cache is really needed: Do I just want that cache because I find it convenient to do a #getMacPoolForCluster(Guid clusterId) in a loop instead of just loading it once before the loop, or do my usage requirements really force me to use a cache? If you really need a cache, consider the following: 1) Do the caching on the DAO layer. This guarantees the best consistency across the data. 2) Yes this means either locking in the DAOs or a transactional cache. But before you complain, think about what in [1] and [2] is done. We do exactly that there, so the complexity is already introduced anyway. 3) Since we are working with transactions, a custom cache should NEVER cache writes (really just talking about our use case here). This makes checks for existing IDs before adding an entity or similar checks unnecessary, don't duplicate constraint checks like in [2]. 4) There should always be a way to disable the cache (even if it is just for testing). 5) If I can't convince you to move the cache to the DAO layer, still add a way to disable the cache. For as long as there is no general caching solution with something like ehcache or infinispan, in my eyes such small things matter a lot to keep a project maintainable. That are some of the best practices I have seen around caching database data. It would be great if we could agree on something like that. Maybe there is already an agreement on something and I am just not aware of it. Looking forward to hear your feedback. Roman [1] https://github.com/oVirt/ovirt-engine/blob/master/backend/manager/modules/b… [2] https://github.com/oVirt/ovirt-engine/blob/master/backend/manager/modules/b…

4 6

oVirt 4.0.1 rc2 merge / branch / tag / bugzilla reminder
by Sandro Bonazzola 11 Jul '16

11 Jul '16

All stable branch maintainers, please make sure to - merge all relevant open bugs until Tuesday morning 11:00 AM TLV time. For each package that need to be built (i.e oVirt product) please make sure every bug in MODIFIED has the right Target Release and Target Milestone. A Target release should state the version of the package you're building and should include the same version you used for the tag you just used for this build. (e.g. for ovirt-engine, tag: ovirt-engine-4.0.1.1, tr: 4.0.1.1) A list of bugs that require attention is here: - https://bugzilla.redhat.com/buglist.cgi?quicksearch=target_milestone%3A4.0.… Thanks, -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 0

oVirt 4.0.1 RC2 build planned
by Sandro Bonazzola 11 Jul '16

11 Jul '16

Fyi oVirt developers, An oVirt build is planned for this Tuesday 11:00 AM TLV time (10:00 AM CEST). Taking into consideration the time it takes for Jenkins to run a full CI everything need to be backported by Monday 11PM. Please make sure to mark as verified and CR +2 so it will be ready for merging Tuesday morning. A list of pending blockers is available here: https://bugzilla.redhat.com/buglist.cgi?quicksearch=target_milestone%3A4.0.… -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 0

Weekly bug status for ovirt-system-tests (using Lago) [ 11/07/16 ]
by Eyal Edri 11 Jul '16

11 Jul '16

*Open bugs:* https://goo.gl/eUaPUY *Open issues:* HE 4.0 support - patch under review - https://gerrit.ovirt.org/#/c/59717/ Initial documentation in progress - https://gerrit.ovirt.org/#/c/59870/ *Open patches:* (reviews are welcome) https://gerrit.ovirt.org/#/q/project:ovirt-system-tests+status:open *Jenkins jobs:* http://jenkins.ovirt.org/view/oVirt%20system%20tests/ * Jobs were failing on add host, most failures were due to missing support on new F24 slaves, fixed. * There was an issue with using 3.6 ovirt stable repo in some tests, seems it was leftover from early days, replacing repo with 3.6 nighties as we do in 4.0 and master solved it. * 4 more slaves added to run tests, running F24 * We hit a libvirt bug [1] that forced us to manually enable the service for now. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1290357 *Recently merged patches:* https://gerrit.ovirt.org/#/q/project:ovirt-system-tests+status:merged+since… -- Eyal Edri Associate Manager RHEV DevOps EMEA ENG Virtualization R&D Red Hat Israel phone: +972-9-7692018 irc: eedri (on #tlv #rhev-dev #rhev-integ)

1 0

python-paramiko availability
by Paul Dyer 11 Jul '16

11 Jul '16

Hi, I am trying to install the ovirt-4.0 engine to a fresh install of RHEL 7.2. There is a dependency for python-paramiko, but it appears that rpm was removed from RHEL between 6 and 7... The dependency appears when I install ovirt-engine: Error: Package: ovirt-engine-setup-base-4.0.0.6-1.el7.centos.noarch (ovirt-4.0) Requires: python-paramiko This doc notes the package removal: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/ht… Does anyone know where to source this package? Thanks, Paul -- Paul Dyer, Mercury Consulting Group, RHCE 504-302-8750

3 6

gerrit.ovirt.org migration
by Shlomo Ben David 10 Jul '16

10 Jul '16

Hi All, Today we are planning to migrate gerrit.ovirt.org server to a new bigger instance on Amazon to improve performance. - The migration will start at 18:00 IDT - Estimate migration end time 19:00 IDT. - During the migration the server will not be available (you won't be able to send patches or review code) - The server will be down for about an hour, but if we'll be able to restore it before we'll let you know. - An email will be sent at the end of the migration process. Best Regards, Shlomi Ben-David | Software Engineer | Red Hat ISRAEL Phone: +972-54-8008858 IRC: shlomibendavid (on #rhev-integ, #rhev-dev, #rhev-ci) OPEN SOURCE - 1 4 011 && 011 4 1

6 7