- Devel - oVirt List Archives

Push notifications in 4.0 backend
by Martin Betak 26 Nov '15

26 Nov '15

Hi All, I would like to take this opportunity to start a discussion about the possibility of implementing a user facing change notifications. The benefit of this would be to remove the need for periodic polling from frontends and other services that consume our REST API. Also implmenting a common infrastructure on the backend for event notifications (e.g. CDI events) would further reduce the internal need for polling the DB by the backend itself, maybe even reducing the need to use DB for some things and just keep them in memory and updated by CDI event observers. There are many solutions how to provide the user-facing part of the notifications: Doctor Rest, MQTT, websocket, server-sent events, ... . Ideally these notifications should be consumable both by web browser (webadmin/userportal) but also by other services (such as ManageIQ), or other REST clients such as moVirt android client. But regardless of the chosen user-facing transport, I believe a common infrastructure can be implemented on the BLL layer with the usage of CDI events fired from commands. I see 2 major sources of changes in the engine (please correct me if this is wrong): 1) CRUD & management commands 2) Vms/Hosts monitoring the changes originating from 2) are AFAIK very localized and not so numerous so a manual firing of appropriate events for VMs and Hosts could be added here. The 1) case is more extensive in terms of required code changes. While a manual solution would still be feasible, I believe there is place for a more automated/declarative way. One solution for 1) that comes to my mind are simple command-level annotations covering the Created, Updated, Removed (C, U, and D from CRUD) cases. The goal here is to fire the appropriate CDI events when an entity is created/updated/deleted. Since commands usually contain getters for entities they work with (such as getVm(), getVds(), getStorageDomain() ...) It should be sufficient for the most common simple cases (of course this will not cover everything) to use annotation @Creates, @Updates, @Removes on the commands classes, where parameters of the annotation should specify the getter method that returns the affected entity (VM/VDS/StorageDomain...). This could be specified by the entity class token or method name (depending on the level of "magic" one prefers :-) and the CommandBase infrastructure would then collect those annotations and upon successful completion of the command fire the appropriate events. Example #1: @Updates('getVm') // or @Updates(VM.class)? public class UpdateVmCommand<...> extends VmManagementComandBase ... Note that since Java 8 we have repeatable annotations so we can have more complex commands that affect more entities. Example #2: @Updates(Vm.class) @Updates(VmTemplate.class) // possibly also some @Creates and @Removes annotations or their combination public class ContrivedExampleCommand extends SomeCommandBase the infrastructure would then look upon successful completion of the command on the getVm() and getVmTemplate() methods, invoke them, determine the resulting types of entities VM and VmTemplate and since the annotations used were @Updates fire CDI event equivalent to @Inject @Updated // our custom CDI qualifier Event<VM> vmChangedEvent; and anologously for VmTemplate. But regardless of the exact implementation of the CDI event firing: whether manual, the above proposal, or some crazy usage of AspectJ - the interface for the rest of the code should always be the like this: public void onVmChanged(@Observes @Updated VM vm) { // .... } On top of this, I believe, we can build the user-facing part of push notifications and also improve our existing backend code. Thank you for reading this long email and I welcome any comments or counter-proposals you might have on this topic :-) Best regards, Martin

6 8

[ANN] oVirt 3.6.1 First Release Candidate is now available for testing
by Sandro Bonazzola 25 Nov '15

25 Nov '15

The oVirt Project is pleased to announce the availability of the First Release Candidate of oVirt 3.6.1 for testing, as of November 25th, 2015. This release is available now for Fedora 22, Red Hat Enterprise Linux 6.7, CentOS Linux 6.7 (or similar) and Red Hat Enterprise Linux >= 7.1, CentOS Linux >= 7.1 (or similar). This release supports Hypervisor Hosts running Red Hat Enterprise Linux >= 7.1, CentOS Linux >= 7.1 (or similar) and Fedora 22. Highly experimental support for Debian 8.1 Jessie has been added too. This release of oVirt 3.6.1 includes numerous bug fixes. See the release notes [1] for an initial list of the new features and bugs fixed. Please refer to release notes [1] for Installation / Upgrade instructions. A new oVirt Live ISO is also available[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.6_Release_Notes [2] http://resources.ovirt.org/pub/ovirt-3.6-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

1 1

oVirt Node roadmap
by Fabian Deutsch 25 Nov '15

25 Nov '15

Hey, in the last few months the Node team spent a lot of efforts in stabilizing Node by closing tons of bugs, rebasing Node onto CentOS 7.2, and in addition adding features like Hosted-Engine - to get Node in shape for the recently released oVirt 3.6.0. But we were also seeing how Node is showing it's age. It becomes more and more challenging to solve bugs and implement features in Node's current architecture. To address these problems, and let Node adjust better to new changes, a few months ago we started to look at how we can change Node, to make it easier to develop, test, and use. This comparison [1] shows a brief summary of our investigations. We especially looked at Atomic and containers [2]. At the bottom line both of them provided us an architecture which would help us to achieve something like 70% of what we need. But during early trials we quickly ran into issues which we experience in similar ways with today's Node. Finally we settled an approach - the idea was around since right from the beginning - which aligns very well with existing technologies which we already use in the oVirt and Fedora/CentOS scope. The new Node will be using anaconda for installation, LVM for upgrades and rollbacks, and Cockpit [3] for administration. The future design is taking care that packages don't need to take special care to work on Node - which was a major obstacle in the past. Node will rather behave (mostly) like a regular host - but with the advantages of an easy & ready to use image, image based delivery and a robust rollback. The current design principles and links to some additional resources are in the wiki [4]. Stay tuned, we are just getting started. On behalf of the Node Team fabian -- [1] http://www.ovirt.org/Node/Specs#Comparison:_Possible_Implementations [2] http://www.projectatomic.io/ ~ http://docker.com/ [3] http://cockpit-project.org/ [4] http://www.ovirt.org/Node/4.0

1 0

[ANN] oVirt 3.5.6 Third Release Candidate is now available for testing
by Sandro Bonazzola 24 Nov '15

24 Nov '15

The oVirt Project is pleased to announce the availability of the Third oVirt 3.5.6 Release Candidate for testing, as of November 24th, 2015. This release is available now for Red Hat Enterprise Linux 6.7, CentOS Linux 6.7 (or similar) and Red Hat Enterprise Linux 7.1, CentOS Linux 7.1 (or similar). This release supports Hypervisor Hosts running Red Hat Enterprise Linux 6.7, CentOS Linux 6.7 (or similar) and Red Hat Enterprise Linux 7.1, CentOS Linux 7.1 (or similar). This release includes updated packages for: - VDSM See the release notes [1] for a list of fixed bugs. Please refer to release notes [1] for Installation / Upgrade instructions. a new oVirt Live ISO is already available[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. Please add yourself to the test page[4] if you're testing this release. [1] http://www.ovirt.org/OVirt_3.5.6_Release_Notes [2] http://resources.ovirt.org/pub/ovirt-3.5-pre/iso/ovirt-live/ [3] http://www.ovirt.org/Repository_mirrors#Current_mirrors [4] http://www.ovirt.org/Testing/oVirt_3.5.6_Testing -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 0

oVirt 3.6.1 branch has been created
by Sandro Bonazzola 24 Nov '15

24 Nov '15

Hi, just an heads up we branched for 3.6.1 stabilization this morning. If you have patches targeted to 3.6.1 you now need to cherry-pick them to 3.6.1 branch too. A build is scheduled for today at 2 PM TLV time. -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

6 11

[oVirt 3.6 Localization Question #37] "In this cluster version only one graphics is supported"
by Yuko Katabami 24 Nov '15

24 Nov '15

Hi all, Could anyone please help us with the following question? File: AppErrors Resource ID: ACTION_TYPE_FAILED_ONLY_ONE_GRAPHICS_SUPPORTED_IN_THIS_CLUSTER_LEVEL String: Cannot ${action} ${type}. In this cluster version only one graphics is supported Question: Is "graphics" referring to "graphics device" or "graphics console"? Kind regards, Yuko

2 1

[Need help] Want to write my graduate thesis related to ovirt
by John Hunter 24 Nov '15

24 Nov '15

Hi guys, I am college student who is going to graduate next year, major in CS, I want to work on my graduate thesis related to ovirt. For now I need a project which I can work on for the next 6 month, so I need an idealist which I can reference to write a proposal. I have contributed to #dri-devel during my Google Summer of Code project, so I know how opensource groups works, though workflow are kind of different. I am appreciate if anyone could help, and I hope some one could be my mentor. BR, Zhao Junwang -- Best regards Junwang Zhao Department of Computer Science &Technology Peking University Beijing, 100871, PRC

3 5

FOSDEM16 Virt & IaaS Devroom CFP Extension, Speaker Mentoring, CoC
by Mikey Ariel 23 Nov '15

23 Nov '15

The CFP for the Virtualization & IaaS devroom at FOSDEM 2016 is in full swing, and we'd like to share a few updates with you: ------------------------- Speaker Mentoring Program ------------------------- As a part of the rising efforts to grow our communities and encourage a diverse and inclusive conference ecosystem, we're happy to announce that we'll be offering mentoring for newcomer speakers. Our mentors can help you with tasks such as reviewing your abstract, reviewing your presentation outline or slides, or practicing your talk with you. You may apply to the mentoring program as a newcomer speaker if you: * Never presented before or * Presented only lightning talks or * Presented full-length talks at small meetups (<50 ppl) Submission guidelines: * Mentored presentations will have 25-minute slots, where 20 minutes will include the presentation and 5 minutes will be reserved for questions. * The number of newcomer session slots is limited, so we will probably not be able to accept all applications. * You must submit your talk and abstract to apply for the mentoring program, our mentors are volunteering their time and will happily provide feedback but won't write your presentation for you! If you are experiencing problems with Pentabarf, the proposal submission interface, or have other questions, you can email iaas-virt-devroom at lists.fosdem.org and we will try to help you. How to apply: * Follow the same procedure to submit an abstract in Pentabarf as standard sessions. Instructions can be found in our original CFP announcement: http://community.redhat.com/blog/2015/10/call-for-proposals-fosdem16-virtua… * In addition to agreeing to video recording and confirming that you can attend FOSDEM in case your session is accepted, please write "speaker mentoring program application" in the "Submission notes" field, and list any prior speaking experience or other relevant information for your application. Call for mentors! Interested in mentoring newcomer speakers? We'd love to have your help! Please email iaas-virt-devroom at lists.fosdem.org with a short speaker bio and any specific fields of expertise (for example, KVM, OpenStack, storage, etc) so that we can match you with a newcomer speaker from a similar field. Estimated time investment can be as low as a 5-10 hours in total, usually distributed weekly or bi-weekly. Never mentored a newcomer speaker but interested to try? Our mentoring program coordinator will be happy to answer your questions and give you tips on how to optimize the mentoring process. Email us and we'll be happy to answer your questions! ------------------------- CFP Deadline Extension ------------------------- To help accommodate the newcomer speaker proposals, we have decided to extend the deadline for submitting proposals by one week. The new deadline is **TUESDAY, DECEMBER 8 @ midnight CET**. ------------------------- Code of Conduct ------------------------- Following the release of the updated code of conduct for FOSDEM[1], we'd like to remind all speakers and attendees that all of the presentations and discussions in our devroom are held under the guidelines set in the CoC and we expect attendees, speakers, and volunteers to follow the CoC at all times. If you submit a proposal and it is accepted, you will be required to confirm that you accept the FOSDEM CoC. If you have any questions about the CoC or wish to have one of the devroom organizers review your presentation slides or any other content for CoC compliance, please email iaas-virt-devroom at lists.fosdem.org and we will do our best to help you out. [1] https://www.fosdem.org/2016/practical/conduct/ -- Mikey Ariel Community Lead, oVirt www.ovirt.org "To be is to do" (Socrates) "To do is to be" (Jean-Paul Sartre) "Do be do be do" (Frank Sinatra) Mobile: +420-702-131-141 IRC: mariel / thatdocslady Twitter: @ThatDocsLady

1 0

Scripts for Engine development
by Shmuel Melamud 23 Nov '15

23 Nov '15

Hi! These are scripts that I'm using for development. Maybe they will save your time or at least will be helpful for newbies. Please, let me know if you find something useful. They assume the following setup: there is a directory for the Engine (set by ENGINE_ROOT conf var). Subdirectories under it correspond to revisions (master, 3.6, 3.5 etc.). You can freely add suffixes (e.g. 3.6-upgr). There is always a current revision you're working on and ~/bin/engine-bin is set to the corresponding bin/ directory. I've added ~/bin/engine-bin to PATH and now if I run, for example, engine-setup, it runs engine-setup of the revision I need currently. Config file: engine-scripts-conf - review it shortly just in case you need to change something to fit your setup Scripts: engine - run the Engine engine-autosetup - run engine-setup (taking into account additional options that should be passed for 3.5, for example) engine-build - build the Engine (this script has many options) engine-dao-tests - run DAO tests engine-gwt-debug - run the frontend in GWT debugging mode (there are also several options in engine-build for GWT debugging) engine-root - print current Engine root directory name engine-setrevision - set or print the current revision And one script for VDSM - it should be run on a host: vdsm-deploy - removes old VDSM rpms, builds and installs the new ones, puts ssl=false into vdsm.conf and restarts VDSM. If restart fails, runs vdsm-tool configure --force and tries to start again. Maybe some of these operations are redundant, but at the end I always get working VDSM ;) vdsm-fix-firewall - fixes /etc/sysconfig/iptables to open non-TLS libvirtd port. It is run automatically from vdsm-deploy, but may be run separately. Shmuel

2 2

[vdsm] merge rights on master branch
by Dan Kenigsberg 23 Nov '15

23 Nov '15

Nir Soffer has been contributing to Vdsm for more than two years now. Beyond his storage-related expertise, he is well-known for his thorough code reviews and his pains when the master branch is broken. It's time for him to take even bigger responsibility. David, please grant Nir Soffer with merge rights on the master branch of Vdsm. I'll keep merging network, virt, and infra patches myself, but much less than before. Adam keeps his merge right as before (he tends to use them on emergencies only). Regards, Dan.

7 6