- Devel - oVirt List Archives

Connection refuse in ovirt webservice
by shubham dubey 23 Mar '17

23 Mar '17

Hello, I have recently installed the ovirt engine development enviornment using $make clean install-dev PREFIX="$HOME/ovirt-engine" BUILD_GWT_WEBADMIN=0 after that I run $HOME/ovirt-engine/bin/engine-setup. Both run successfully but when I am opening the webservice link(in my case http://localhost.localdomain:8080/) in my browser I am getting connection refused. I have my seLinux disabled and I have also done iptables -F. So any other Solution? And is this because of disabling webadmin? Thanks, Shubham

2 1

[vdsm] Engine XML: metadata and devices from XML
by Francesco Romani 23 Mar '17

23 Mar '17

Hi everyone, This is both a report of the current state of my Vdsm patches for Engine XML support, and a proposal to how move forward and solve the current open issues. TL;DR: 1. we can and IMO should reuse the current JSON schema to describe the structure (layout) and the types of the metadata section. 2. we don't need a priori validation of stuff in the metadata section. We will just raise in the creation flow if data is missing, or wrong, according to our schema. 2. we will add *few* items to the metadata section, only thing we can't express clearly-or at all in the libvirt XML. Redundancy and verbosiness will be thus kept at bay 3. I believe [3] is the best tool to do (de)serialize data to the metadata section. Existing tools fits poorly in our very specific use case Examples below +++ Long(er) discussion: I have working code[1][2] to encode any custom, picklable, python object in the metadata section. We should decide which module will do the actual python<=>XML transformation. Please note that this actually also influences how the data in the medata section look like, so the two things are a bit coupled. I'm eager to reinvent another wheel, but after initial evaluation I honestly think that my pyxmlpickle[3] is the best tool for the job over the current alternatives: plistlib[4] and xmltodict[5]. I added the initial rationale here: https://gerrit.ovirt.org/#/c/73790/4//COMMIT_MSG I have completed the initial draft of patches to make it possible to initialize devices from their XML representation [6]. This is the bare minimum we need to support the Engine XML, and we *need* this anyway to unlock the cleanup we planned and I outlined in my google doc. So we are progressing, but I'd like to speed up things. Those [6] patches are not yet complete, many flows are not covered or tested; but they are good enough to demonstrate that there *are* pieces of information wen need to properly initialize the devices, but we can't easily extract from the XML. First examples that come to my mind are the storage.Drive UUIDs; there could also be some ambiguity I'm investigating right now for displayIp/displayNetwork in Graphics devices. In [6] there are various TODO to mark more of those cases. Most likely, few more cases will pop out as I cover all the flows we support. Long story short: it is hard to correctly rebuild the device conf from the XML. This is why in [6] I added the 'meta' argument to from_xml_tree classmethod in [7]. 'meta' is supposed to be the device metadata: extra data related to a device which doesn't (yet) fit in the libvirt XML representation. For example, we can store 'displayIp' and 'displayNetwork' here and be done with that: using both per-device metadata and the XML representation of one graphic device, we will have everything we need to properly build one graphics.Graphics device. This example may (hopefully) be bogus, but I'm keeping it because it is one case easy to follow. The device metadata is going to be stored in the vm metadata for the short/mid term future. Even if the per-device metadata idea/RFE is accepted (no answer yet, but we are working on it), we will not have in 7.4, and unlikely in 7.5. As it stands today, I believe there are two open questions: 1. do we need a schema for the metadata section? 2. how do we bind the metadata to the devices? How do we know which metadata belongs to which metadata, if we don't have aliases nor addresses to match? (e.g. very first time the VM is created!) My current stance is the following 1. In general, one schema gives us two benefits: 1.a. we document how the layout of the data should be, including types; 1.b. we can validate the data we receive. So yes, we need a schema, but we don't need a *new* schema. I think we are in good enough shape with the current Vdsm schema: we can just translate the python object layout to a XML layout. One example is probably more explicative. Some actual data may look like, using my pyxmlpickle module: <domain type='kvm' id='5'> <name>a0</name> <uuid>ccd945c8-8069-4f31-8471-bbb58e9dd6ea</uuid> <metadata xmlns:ovirt-tune="http://ovirt.org/vm/tune/1.0" xmlns:ovirt-vm="http://ovirt.org/vm/1.0" xmlns:ovirt-instance="http://ovirt.org/vm/instance/1.0"> <ovirt-tune:qos/> <ovirt-vm:vm/> <ovirt-instance:instance> <ovirt-instance:value type="dict"> <ovirt-instance:item key="devices" type="list"> <ovirt-instance:item index="0" type="dict"> <ovirt-instance:item key="device" type="str">vnc</ovirt-instance:item> <ovirt-instance:item key="specParams" type="dict"> <ovirt-instance:item key="displayNetwork" type="str">ovirtmgmt</ovirt-instance:item> <ovirt-instance:item key="displayIp" type="str">192.168.1.53</ovirt-instance:item> </ovirt-instance:item> <ovirt-instance:item key="type" type="str">graphics</ovirt-instance:item> </ovirt-instance:item> <ovirt-instance:item index="1" type="dict"> <ovirt-instance:item key="device" type="str">spice</ovirt-instance:item> <ovirt-instance:item key="specParams" type="dict"> <ovirt-instance:item key="displayNetwork" type="str">ovirtmgmt</ovirt-instance:item> <ovirt-instance:item key="displayIp" type="str">192.168.1.53</ovirt-instance:item> </ovirt-instance:item> <ovirt-instance:item key="type" type="str">graphics</ovirt-instance:item> </ovirt-instance:item> <ovirt-instance:item index="2" type="dict"> <ovirt-instance:item key="poolID" type="str">5890a292-0390-01d2-01ed-00000000029a</ovirt-instance:item> <ovirt-instance:item key="imageID" type="str">66441539-f7ac-4946-8a25-75e422f939d4</ovirt-instance:item> <ovirt-instance:item key="domainID" type="str">c578566d-bc61-420c-8f1e-8dfa0a18efd5</ovirt-instance:item> <ovirt-instance:item key="device" type="str">disk</ovirt-instance:item> <ovirt-instance:item key="path" type="str">/rhev/data-center/5890a292-0390-01d2-01ed-00000000029a/c578566d-bc61-420c-8f1e-8dfa0a18efd5/images/66441539-f7ac-4946-8a25-75e422f939d4/5c4eeed4-f2a7-490a-ab57-a0d6f3a711cc</ovirt-instance:item> <ovirt-instance:item key="volumeID" type="str">5c4eeed4-f2a7-490a-ab57-a0d6f3a711cc</ovirt-instance:item> </ovirt-instance:item> </ovirt-instance:item> </ovirt-instance:value> </ovirt-instance:instance> </metadata>  </domain> Please note that yes, this is still verbose, but we don't want to add much data here, for most of information the most reliable source will be the domain XML. We will add here only the extra info we can't really fetch from that. 2. I don't think we need explicit validation: we could just raise along the way in the creation flow if we don't find some extra metadata we need. This will also solve the issue that if we reuse the current schema and we omit most of data, we will lack quite a lot of elements marked mandatory. Once we reached agreement, I will update my https://docs.google.com/document/d/1eD8KSLwwyo2Sk64MytbmE0wBxxMlpIyEI1GRcHD… accordingly. Final note: while device take the lion's share, we will likely need help from the metadata section also to store VM extra info, but all the above discussion also applies here. +++ [1] https://gerrit.ovirt.org/#/q/status:open+project:vdsm+branch:master+topic:v… - uses xmltodict [2] https://gerrit.ovirt.org/#/q/status:open+project:vdsm+branch:master+topic:v… ported the 'virt-metadata3' topic to pyxmlpickle [3] https://github.com/fromanirh/pyxmlpickle [4] https://docs.python.org/2/library/plistlib.html [5] https://github.com/martinblech/xmltodict [6] https://gerrit.ovirt.org/#/q/status:open+project:vdsm+branch:master+topic:v… [7] https://gerrit.ovirt.org/#/c/72880/15/lib/vdsm/virt/vmdevices/core.py -- Francesco Romani Red Hat Engineering Virtualization R & D IRC: fromani

4 11

[vdsm] Patches awaiting review
by Piotr Kliczewski 22 Mar '17

22 Mar '17

All, Here is bunch of patches that I would like have reviewed: https://gerrit.ovirt.org/#/q/status:open+project:vdsm+branch:master+topic:s… https://gerrit.ovirt.org/#/c/72284/ https://gerrit.ovirt.org/#/c/74005/ A draft from Nir: https://gerrit.ovirt.org/#/c/72306/ And xmlrpc removal: https://gerrit.ovirt.org/#/q/status:open+project:vdsm+branch:master+topic:x… Thanks, Piotr

1 0

Dates for This Phase of GSoC
by Brian Proffitt 22 Mar '17

22 Mar '17

I've had some questions about the Google Summer of Code, and I wanted to share with you the dates and milestones for the student/mentor onboarding phase of the event. All dates can be found on the GSoC site[1]. Right now we are in the student application phase, which goes until April 3. By that time, students should have their draft proposals in. Then we review them and turn them in to Google by April 16. On April 17, we ask for student slots, and then on April 19, slots are allocated to us. Finally, on April 24, we tell Google which students are going to take the slots, and then on May 3, Google announces all projects/students/mentors. Hopefully this helps. Please watch your inbox for notifications from Google to ensure what you are getting does not need an action item. What I get as one of the oVirt admins for GSoC is different that what you get as (potential) mentors. Peace, Brian [1] https://summerofcode.withgoogle.com/dashboard/timeline/ -- Brian Proffitt Principal Community Analyst Open Source and Standards @TheTechScribe 574.383.9BKP

1 0

planned Jenkins restart
by Evgheni Dereveanchin 21 Mar '17

21 Mar '17

Hi everyone, I'll be performing a planned Jenkins restart within the next hour. No new builds will be scheduled during this maintenance period. I will inform you once it is over. Regards, Evgheni Dereveanchin

1 1

[ OST Failure Report ] [ oVirt master ] [ 21-03-2017 ] [test-repo_ovirt_experimental_master]
by Shlomo Ben David 21 Mar '17

21 Mar '17

Hi, Test failed: [ test-repo_ovirt_experimental_master ] Link to suspected patches: N/A Link to Job: http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/5945 Link to all logs: http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/5945/artif… Error snippet from the log: <error> 2017-03-21 11:55:15,975-0400 ERROR (jsonrpc/7) [storage.TaskManager.Task] (Task='02a8b5a3-ff82-4a07-bc8a-b3a756630e8c') Unexpected error (task:871) Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/vdsm/storage/task.py", line 878, in _run return fn(*args, **kargs) File "/usr/lib/python2.7/site-packages/vdsm/logUtils.py", line 52, in wrapper res = f(*args, **kwargs) File "/usr/share/vdsm/storage/hsm.py", line 1158, in attachStorageDomain pool.attachSD(sdUUID) File "/usr/lib/python2.7/site-packages/vdsm/storage/securable.py", line 79, in wrapper return method(self, *args, **kwargs) File "/usr/share/vdsm/storage/sp.py", line 930, in attachSD dom = sdCache.produce(sdUUID) File "/usr/share/vdsm/storage/sdc.py", line 112, in produce domain.getRealDomain() File "/usr/share/vdsm/storage/sdc.py", line 53, in getRealDomain return self._cache._realProduce(self._sdUUID) File "/usr/share/vdsm/storage/sdc.py", line 136, in _realProduce domain = self._findDomain(sdUUID) File "/usr/share/vdsm/storage/sdc.py", line 153, in _findDomain return findMethod(sdUUID) File "/usr/share/vdsm/storage/sdc.py", line 178, in _findUnfetchedDomain raise se.StorageDomainDoesNotExist(sdUUID) StorageDomainDoesNotExist: Storage domain does not exist: (u'a8739fae-284f-4640-800d-016c084de7e6',) </error> Best Regards, Shlomi Ben-David | Software Engineer | Red Hat ISRAEL RHCSA | RHCVA | RHCE IRC: shlomibendavid (on #rhev-integ, #rhev-dev, #rhev-ci) OPEN SOURCE - 1 4 011 && 011 4 1

1 0

NetworkManager (was: Fwd: Question for oVirt)
by Yedidyah Bar David 21 Mar '17

21 Mar '17

On Tue, Mar 21, 2017 at 4:40 AM, jeff hsueh <jeffhsueh(a)qnap.com> wrote: > Hi Devel, > > Could you help to give me some detail information about this feature? > Thanks. > > Jeff > > ---------- Forwarded message ---------- > From: Mike Burns <mburns(a)redhat.com> > Date: 2017-03-20 20:44 GMT+08:00 > Subject: Re: Question for oVirt > To: jeff hsueh <jeffhsueh(a)qnap.com> > > > This is very old (last update 2012). I haven't worked on oVirt in a long > time either. You should redirect this and other questions to > > devel(a)ovirt.org. > > Thanks > > On Mon, Mar 20, 2017 at 4:56 AM, jeff hsueh <jeffhsueh(a)qnap.com> wrote: > >> Hi Mike, >> >> I am studying "NetworkManager Support" of oVirt project. >> Link: http://www.ovirt.org/develop/release-management/featur >> es/network/networkmanager-support/ >> >> I could not understand what does this feature want to achieve. >> Could I get more information and status about this feature from you? >> Because the information about this feature in oVirt web site is too brief. >> > (changed the subject) Please check these: https://bugzilla.redhat.com/show_bug.cgi?id=1326798 https://bugzilla.redhat.com/show_bug.cgi?id=1330138 Should work in 4.1.1 (to be released tomorrow). Best, > >> Thanks. >> >> Jeff >> >> >> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> >> 不含病毒。www.avast.com >> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> >> <#m_-8543651732826125291_m_-8795404721952800494_m_4727600564310439803_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> >> > > > > _______________________________________________ > Devel mailing list > Devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel > -- Didi

1 0

Get Involved with the oVirt Project! Spring 2017 Edition
by Sandro Bonazzola 21 Mar '17

21 Mar '17

Hi, Got some time to spare? Join us on the oVirt project! oVirt is a feature rich server virtualization management system with advanced capabilities. It also provides a crucial venue for user and developer cooperation, and is the first truly open and comprehensive data center virtualization management initiative. If you are new to oVirt, we recommend that you visit the develop <https://www.ovirt.org/develop/> page to learn more about the project, and the working with Gerrit <https://www.ovirt.org/develop/dev-process/working-with-gerrit/> page for more about our code review system. If you haven’t worked with Gerrit before, we recommend you visit the introduction to Gerrit <https://gerrit-review.googlesource.com/Documentation> page. On our community page <https://www.ovirt.org/community/> you’ll discover the many ways in which you can contribute to the project, even without programming skills. More suggestions? Below you’ll find other ways in which you can contribute to the oVirt project. Keep ‘em Fresh Like the idea of having fresh disk images of your favorite distribution in the oVirt Glance repository? You can help in two ways: First, test existing online images to ensure that they work with cloud-init. Second, create an online image and report your success to devel(a)ovirt.org. We’ll be happy to upload the images once they are ready. Get Vdsm Running on Debian If you like Debian and have programming or packaging skills, you can help with the ongoing effort to get VDSM running on Debian <https://www.ovirt.org/develop/release-management/features/debian-support-fo…>. All the current work on Debian (VDSM and related packages) can be found in the Debian git repositories <http://git.debian.org/>. You can also keep up to date on how the work is progressing by subscribing to the oVirt devel mailing list <http://lists.ovirt.org/mailman/listinfo/devel>. Fix Some Bugs These bugs are just waiting to be resolved: Bug ID Summary 1411133 Hosted-Engine: iscsi activation storage failing 1209881 [RFE] Remove iptables from hosted-engine.spec file to be able to deploy hosted-engine without firewall services installed 1353713 [RFE] - iSCSI Setup Should use different User/Password For Discovery and Portal 1130445 [TEXT] - If engine-setup asks for updates and choice is no, suggest '--offline' on re-run. 1174236 [RFE] Integrate installation with Server Roles of Fedora Server 1356425 [TEXT] 'hosted-engine --vm-start' said it destroyed the VM 1328488 The engine fails with oracle java8 Port oVirt to Your Favorite Distribution Are you sure-handed at packaging software, and using a distribution currently unsupported by oVirt? Help to get oVirt ported to any of the following distributions: Fedora <http://lists.ovirt.org/pipermail/devel/2015-September/011426.html> CentOS <https://wiki.centos.org/SpecialInterestGroup/Virtualization> Gentoo <https://wiki.gentoo.org/wiki/OVirt>. Also, check out Google Summer of Code <https://wiki.gentoo.org/wiki/Google_Summer_of_Code/2016/Ideas> to learn how you can contribute to Gentoo and get paid for it! Debian <http://www.ovirt.org/develop/release-management/features/debian-support-for…>: Archlinux <http://www.ovirt.org/develop/developer-guide/arch-linux/> OpenSUSE <https://build.opensuse.org/project/show/Virtualization:oVirt> Get into DevOps If you love DevOps and find yourself counting stable builds in Jenkins CI while trying to fall asleep, then the oVirt infrastructure team is looking for you! Join us and dive into the latest and coolest DevOps tools today! Check out these open tasks <https://ovirt-jira.atlassian.net/secure/RapidBoard.jspa?rapidView=6.>. You can also help by telling us how you use oVirt in your DevOps environment. Email us at devel(a)ovirt.org (Please use [DevOps] in the subject line. For more information on oVirt DevOps, visit oVirt infrastructure docs <http://ovirt-infra-docs.readthedocs.io/en/latest/> and oVirt infra documentation <http://www.ovirt.org/develop/infra/infrastructure-documentation/>. Improve the oVirt System Testing Make oVirt system testing <https://gerrit.ovirt.org/gitweb?p=ovirt-system-tests.git;a=summary> - and the Lago system <https://github.com/lago-project/lago> that runs it - even better. Visit Lago project documentation <http://lago.readthedocs.io/en/stable/> to learn how to run the test suite yourself. More Bugs, No Coding Required No time for DevOps and you are not a programer? You can still contribute. Here are some easy bugs to fix <https://bugzilla.redhat.com/buglist.cgi?quicksearch=classification%3Aovirt%…> that don’t require a single line of code. Tests to Run Do you prefer to test things? Here are some test cases you can try <http://www.ovirt.org/develop/infra/testing/>, using nightly snapshots <http://www.ovirt.org/develop/dev-process/install-nightly-snapshot/>. Switching to Fedora 25 For oVirt 4.2, support for Fedora will be based on Fedora 25. You can help to get it ready by running nightly snapshots <http://www.ovirt.org/develop/dev-process/install-nightly-snapshot/> and reporting any issues. Create Your Own Test Cases We’d love you to contribute some much needed test cases for oVirt features <http://www.ovirt.org/develop/release-management/features/>. Get Creative You are welcome to contribute artwork, such as oVirt live backgrounds and covers, release banners, stickers, and t-shirt designs. Check out Fedora artworks <https://fedoraproject.org/wiki/Artwork#Resources> for inspiration. Get Alternative Into alternative architectures? Test ppc64le <https://cbs.centos.org/repos/virt7-ovirt-41-release/ppc64le/> and aarch64 <https://cbs.centos.org/repos/virt7-ovirt-41-release/aarch64/> packages from CentOS Virt SIG. Talk to Us! Feel free to ask any other question about development by emailing us at devel(a)ovirt.org, or by reaching out on the IRC channel <https://www.ovirt.org/community/>. Spread the Good News Help to spread the word about oVirt! We are the complete virtual machine management system that’s free and comes with an impressive list of enterprise capabilities <http://www.zdnet.com/article/how-much-longer-can-red-hats-ovirt-remain-cove…> including live migration, high availability, load balancing, a self-hosted engine, an intuitive user-interface, and much more. How to Contribute If you’d like to get involved, we’d love to hear from you! Simply shoot us an email at devel(a)ovirt.org and tell us how you’d like to contribute. We look forward to hearing from you!. The oVirt Development Team oVirt: Better technology. Faster Innovation. Powered by community innovation.

1 0

UI dialog visual update
by Alexander Wels 20 Mar '17

20 Mar '17

Hi, I just merged a large patch that does a complete visual update of all dialogs in oVirt. All the dialogs should now follow the standard patternfly modal dialog visuals and layout. One of the consequences of this is that you can no longer move the dialogs around in the application like before. This is by design. I tried very hard to make sure I updated every dialog in the application to match the look and feel as needed, or at the very least did not display any major issues like missing content or extra scrollbars where none were needed. Please report any issues you find to me, and I will try to make sure they get fixed ASAP. Alexander ps. attached are some screenshots from my development environment.

1 0

[ OST Failure Report ] [ oVirt master ] [ 20-03-2017 ] [007_sd_reattach.reattach_storage_domain]
by Shlomo Ben David 20 Mar '17

20 Mar '17

Hi, Test failed: [ 007_sd_reattach.reattach_storage_domain ] Link to suspected patches: N/A Link to Job: http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/5915/conso… Link to all logs: http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/5915/artif… Error snippet from the log: <error> 12:01:51 [basic_suit_el7] @ Run test: 007_sd_reattach.py: ERROR (in 0:00:44) 12:01:51 [basic_suit_el7] Error occured, aborting 12:01:51 [basic_suit_el7] Traceback (most recent call last): 12:01:51 [basic_suit_el7] File "/usr/lib/python2.7/site-packages/ovirtlago/cmd.py", line 267, in do_run 12:01:51 [basic_suit_el7] self.cli_plugins[args.ovirtverb].do_run(args) 12:01:51 [basic_suit_el7] File "/usr/lib/python2.7/site-packages/lago/plugins/cli.py", line 184, in do_run 12:01:51 [basic_suit_el7] self._do_run(**vars(args)) 12:01:51 [basic_suit_el7] File "/usr/lib/python2.7/site-packages/lago/utils.py", line 495, in wrapper 12:01:51 [basic_suit_el7] return func(*args, **kwargs) 12:01:51 [basic_suit_el7] File "/usr/lib/python2.7/site-packages/lago/utils.py", line 506, in wrapper 12:01:51 [basic_suit_el7] return func(*args, prefix=prefix, **kwargs) 12:01:51 [basic_suit_el7] File "/usr/lib/python2.7/site-packages/ovirtlago/cmd.py", line 96, in do_ovirt_runtest 12:01:51 [basic_suit_el7] raise RuntimeError('Some tests failed') 12:01:51 [basic_suit_el7] RuntimeError: Some tests failed </error> Best Regards, Shlomi Ben-David | Software Engineer | Red Hat ISRAEL RHCSA | RHCVA | RHCE IRC: shlomibendavid (on #rhev-integ, #rhev-dev, #rhev-ci) OPEN SOURCE - 1 4 011 && 011 4 1

4 3