- Devel - oVirt List Archives

oVirt repositories 101; or everything you wanted to know about oVirt repositories and didn't ask
by Eyal Edri 09 Apr '17

09 Apr '17

Hi oVirt developers and users, Some of you might be familiar with the oVirt repositories and all their flavors, while some of you are just familiar with the official releases. The fact is, we have plenty of them and each has its own role and a right usage. Moreover, we did a significant overhaul on all the repositories in the past months, So hopefully now it will be easier to explain which repo to use when. I'll start with reviewing each oVirt repository and give a bit of background and the logic behind it, how to consume it and the relevant usage for it. For simplicity, I'll review the repositories on the 4.1 release, but it valid for all other oVirt releases ( except 'master' which doesn't have an official or pre-release repositories ). I will also upload this information to the oVirt.org site, but since this is important, I didn't want to wait with the sending this email. *oVirt repositories* *Official repositories* *Desc:* here you can find the official signed oVirt RPMs, immediately after an official release has been done. *Path:* http://resources.ovirt.org/pub/ovirt-4.1/rpm/$distro *Update frequency:* on every oVirt release, usually happens on a monthly cadence. *Release rpm: *http://resources.ovirt.org/pub/yum-repo/ovirt-release41.rpm *Who should use it? * oVirt users, developers or anyone who wants a final and official release *Pre-release repositories* *Desc:* here you can find the pre-release bits of oVirt RC builds, just before they are released. *Path:* http://resources.ovirt.org/pub/ovirt-4.1-pre/rpm/$distro *Update frequency:* usually on a weekly or bi-weekly basis *Release rpm: *http://resources.ovirt.org/pub/yum-repo/ovirt- release41-pre.rpm *Who should use it? * oVirt users, developers or anyone who wants to try out oVirt new version before its out, Keeping in mind this isn't a fully verified release and might still have critical bugs which are not fixed yet. Packages in this repo are verified by automation and checked by humans for basic sanity before publishing. *Nightly snapshot (verified) repositories* *Desc:* here you can find the nightly snapshot of RPMs, which passed basic sanity by our 'oVirt System Tests' framework in the oVirt CI system. *Path:* http://resources.ovirt.org/pub/ovirt-4.1-snapshot/rpm/$distro *Update frequency:* Every night *Release rpm: *http://resources.ovirt.org/pub/yum-repo/ovirt- release41-snapshot.rpm *Who should use it? * oVirt users, developers or anyone who wants to try out oVirt latest bits right of the build oven! We trust our system tests, which already run more than 40 various tests such as 'add host', 'create VM', 'live migration' and more! *** Important note: the snapshot repositories are verified only in master currently, we might do the same for 4.1 soon, as we see no issues with master so far ** * *The above repos should suffice to most usres and developers, but if you feel its not enough and you still need a faster verified repo, look below! * *Advanced oVirt repositories* *Builds artifacts repo* *Desc:* This is a new feature from oVirt 'standard CI' project, where each 'build-artifacts' job is actually a yum repo as well. *Path:* http://jenkins.ovirt.org/job/ovirt-engine_4.1_ build-artifacts-on-demand-el7-x86_64/lastSuccessfulBuild/ artifact/exported-artifacts ( example ) *Update frequency:* after each commit or 'ci please build' comment *Release rpm: *N/A *Who should use it? * oVirt developers who need latest RPMs from another oVirt project and cannot or need not wait for that project`s packages to pass OST". oVirt developers running manual OST job and need to test an open Gerrit patch, using the 'ci please build' command. *Tested repositories* *Desc:* The tested repositories hold all the oVIrt packages which passed CI ( similar to snapshot repos ) and retain also version history for X versions back. *Path:* http://resources.ovirt.org/repos/ovirt/tested/4.1/rpm/$distro *Update frequency:* after each 'build artifacts' job is triggered by any oVirt project and if the packages passed sanity checks *Release rpm: *N/A *Who should use it? * If you want to have latest and greatest oVirt packages and can't wait for the nightly repo. If you are testing upgrades or need more than one version of a pacakge in your repo. *Experimental repositories * *Desc:* Internal CI repos which are a part of the 'experimental' flow which runs OST on each built package. *Path:* http://resources.ovirt.org/repos/ovirt/experimental/ 4.1/latest.tested/rpm/el7/$distro *Update frequency:* after each 'build artifacts' job is triggered by any oVirt project and if the packages passed sanity checks *Release rpm: *N/A *Who should use it? * *No one other than internal CI jobs.* These repos are constantly refreshed and RPMs are being removed from them, so they are very prone to errors, please don't use them. I hope this makes a bit of order in all the repos and how to use them. If you still have questions, please don't hesitate to contact the infra team at infra(a)ovirt.org or just reply to this thread. -- Eyal edri ASSOCIATE MANAGER RHV DevOps EMEA VIRTUALIZATION R&D Red Hat EMEA <https://www.redhat.com/> <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted> phone: +972-9-7692018 irc: eedri (on #tlv #rhev-dev #rhev-integ)

1 0

ovirt-engine dependencies and packaging plans for 4.2
by Sandro Bonazzola 08 Apr '17

08 Apr '17

In https://bugzilla.redhat.com/show_bug.cgi?id=1439518 I'm suggesting a packaging change for ovirt-engine allowing to reduce the space needed to install a minimal ovirt-engine. Martin says: We should get rid of PostgreSQL RPM dependency when we move to SCL version of PG9.5/9.6, which is planned fo 4.2 Do we have a bz to track it? How engine-setup can upgrade from a non-scl to a scl postgres setup? Who's going to handle it? Following up from https://bugzilla.redhat.com/show_bug.cgi?id=1439518#c1 Do we have plans to split userportal/backend to their own containers at some point? -- SANDRO BONAZZOLA ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D Red Hat EMEA <https://www.redhat.com/> <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>

3 2

[OST] [HC] HE VM fails to start
by Sahina Bose 06 Apr '17

06 Apr '17

The error in vdsm.log Traceback (most recent call last): File "/usr/share/vdsm/virt/vm.py", line 2016, in _setup_devices dev_object.setup() File "/usr/lib/python2.7/site-packages/vdsm/virt/vmdevices/graphics.py", line 63, in setup net_api.create_libvirt_network(display_network, self.conf['vmId']) File "/usr/lib/python2.7/site-packages/vdsm/network/api.py", line 90, in create_libvirt_network libvirt.create_network(netname, user_reference) File "/usr/lib/python2.7/site-packages/vdsm/network/libvirt.py", line 94, in create_network if not is_libvirt_network(netname): File "/usr/lib/python2.7/site-packages/vdsm/network/libvirt.py", line 159, in is_libvirt_network netname = LIBVIRT_NET_PREFIX + netname TypeError: cannot concatenate 'str' and 'NoneType' objects 2017-03-29 22:58:39,559-0400 ERROR (vm/d71bdf4e) [virt.vm] (vmId='d71bdf4e-1eb3-4762-bd0e-05bb9f5e43ef') The vm start process failed (vm:659) The tests last passed on Mar 28. Did a recent patch break this? The full build logs at http://jenkins.ovirt.org/job/ovirt_master_hc-system-tests/52/artifact/expor… thanks sahina

4 12

Firewalld migration.
by Leon Goldberg 06 Apr '17

06 Apr '17

Hey, We're looking to migrate from iptables to firewalld. We came up with a couple of possible approaches we'd like opinions on. I'll list the options first, and will 1) Replicate existing flow: As of date, iptable rules are inserted in the database via SQL config files. During host deployment, VdsDeployIptablesUnit adds the required rules (based on cluster/firewall configuration) to the deployment configuration, en route to being deployed on the host via otopi and its iptables plugin. Pros: - Reuse of existing infrastructure. Cons: - Current infrastructure is overly complex... - Many of the required services are provided by firewalld. Rewriting them is wasteful; specifying them (instead of providing actual service .xml content) will require adaptations on both (engine/host) sides. More on that later. 2) Host side based configuration: Essentially, all the required logic (aforementioned cluster/firewall configuration) to determine if/how firewalld should be deployed could be passed on to the host via ohd. Vdsm could take on the responsibility of examining the relevant configuration, and then creating and/or adding the required services (using vdsm.conf and vdsm-tool). Pros: - Engine side involvement is greatly diminished. - Simple(r). Cons: - Custom services/rules capabilities will have to be rethought and re-implemented (current infrastructure supports custom iptables rules by being specified in the SQL config file). 3) Some other hybrid approach: If we're able to guarantee all the required firewalld services are statically provided one way or the other, the current procedure could be replicated and be made more simpler. Instead of providing xml content in the form of strings, service names could be supplied. The responsibility of actual service deployment becomes easier, and could be left to otopi (with the appropriate modifications) or switched over to vdsm. -- Regardless, usage of statically provided vs. dynamically created services remains an open question. I think we'd like to avoid implementing logic that ask whether some service is provided (and then write it if it isn't...), and so choosing between the dynamic and static approaches is also needed. Using the static approach, guaranteeing *all* services are provided will be required. I do believe guaranteeing the presence of all required services is worth it, however custom services aren't going to be naively compatible, and we'll still have to use similar mechanism as described in #1 (service string -> .xml -> addition of service name to active zone). Your thoughts are welcome. Thanks, Leon

10 37

[ OST Failure Report ] [ oVirt master ] [ 28-03-2017 ] [ repoclosure ]
by Pavel Zhukov 06 Apr '17

06 Apr '17

Hi, Newly introduced repoclosure test is failed [1] on gdeploy package (GlusterFS) [2] As we hadn't run this test before the only suspected patch is the patch to add the test itself: 959e735c1c02a74c209fffc03d76f67ccf86606e ost: added repo closure test [1] http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/6066/ [2] 14:18:36 [basic_suit_el7] Repos looked at: 10 14:18:36 [basic_suit_el7] centos-base-el7 14:18:36 [basic_suit_el7] centos-extras-el7 14:18:36 [basic_suit_el7] centos-opstools-testing-el7 14:18:36 [basic_suit_el7] centos-ovirt-4.0-el7 14:18:36 [basic_suit_el7] centos-updates-el7 14:18:36 [basic_suit_el7] epel-el7 14:18:36 [basic_suit_el7] glusterfs-3.10-el7 14:18:36 [basic_suit_el7] internal_repo 14:18:36 [basic_suit_el7] ovirt-master-snapshot-static-el7 14:18:36 [basic_suit_el7] ovirt-master-tested-el7 14:18:36 [basic_suit_el7] Num Packages in Repos: 38045 14:18:36 [basic_suit_el7] package: ovirt-release-host-node-4.2.0-0.3.master.20170328000035.git67870d2.el7.centos.noarch from internal_repo 14:18:36 [basic_suit_el7] unresolved deps: 14:18:36 [basic_suit_el7] gdeploy -- Pavel Zhukov

2 1

[ OST Failure Report ] [ oVirt master ] [ 5/4/2017 ] [ add_non_vm_network ]
by Barak Korren 05 Apr '17

05 Apr '17

Test failed: [ add_non_vm_network ] Link to suspected patches: - https://gerrit.ovirt.org/75020 - https://gerrit.ovirt.org/75010 - https://gerrit.ovirt.org/75065 - https://gerrit.ovirt.org/75021 - https://gerrit.ovirt.org/75067 - https://gerrit.ovirt.org/74916 Link to Job: http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/6208/ Link to all logs: http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/6208/artif… Error snippet from log: <error> status: 400 reason: Bad Request detail: Internal Engine Error </error> -- Barak Korren bkorren(a)redhat.com RHCE, RHCi, RHV-DevOps Team https://ifireball.wordpress.com/

2 1

[ ACTION REQUIRED ] ABORTED jobs in Jenkins
by Barak Korren 05 Apr '17

05 Apr '17

Hi, We are having a Jenkins malfunction ATM that makes it necessary to abort some CI jobs. If the jobs it your patch get aborted, please re-trigger them, they should pass fine now. -- Barak Korren bkorren(a)redhat.com RHCE, RHCi, RHV-DevOps Team https://ifireball.wordpress.com/

1 0

[ANN] oVirt 4.1.1 Async release candidate
by Sandro Bonazzola 05 Apr '17

05 Apr '17

Hi, following oVirt 4.1.1 GA the oVirt team identified some bugs worth to be addressed out of the usual release cycle. For this reason an async release including these fixes is under preparation. An update to the following packages have been pushed to the pre-release repository for testing. - cockpit-ovirt-0.10.7-0.0.16 - imgbased-0.9.20 - ovirt-engine-4.1.1.8 - ovirt-engine-metrics-1.0.2 - ovirt-release41-4.1.1.1 - ovirt-web-ui-0.1.2-4 - vdsm-jsonrpc-java-1.3.10 - vdsm v4.19.10.1 In order to test it, you'll need pre-release repository enabled: yum install http://resources.ovirt.org/pub/yum-repo/ovirt-release41-pre.rpm An update to release notes including bugs related to above packages and updates applied in bugzilla documentation texts has been pushed tohttps://github.com/oVirt/ovirt-site/pull/888 for review. On behalf of the oVirt team, -- SANDRO BONAZZOLA ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D Red Hat EMEA <https://www.redhat.com/> <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>

1 0

Engine error: No enum constant ProviderType.http://localhost:9696
by Jakub Niedermertl 04 Apr '17

04 Apr '17

Hi, anyone else is experiencing following error message in engine log? 2017-04-04 17:38:48,988+02 ERROR [org.ovirt.engine.core.bll.provider.GetAllProvidersQuery] (default task-101) [b421c4c1-1602-4c41-88f6-b5ff20888713] Query 'GetAllProvidersQuery' failed: No enum constant org.ovirt.engine.core.common.businessentities.ProviderType.http://localhost:9696 2017-04-04 17:38:48,989+02 ERROR [org.ovirt.engine.core.bll.provider.GetAllProvidersQuery] (default task-101) [b421c4c1-1602-4c41-88f6-b5ff20888713] Exception: java.lang.IllegalArgumentException: No enum constant org.ovirt.engine.core.common.businessentities.ProviderType.http://localhost:9696 at java.lang.Enum.valueOf(Enum.java:238) [rt.jar:1.8.0_121] at org.ovirt.engine.core.common.businessentities.ProviderType.valueOf(ProviderType.java:11) [common.jar:] at org.ovirt.engine.core.dao.provider.ProviderDaoImpl$ProviderRowMapper.mapRow(ProviderDaoImpl.java:134) [dal.jar:] at org.ovirt.engine.core.dao.provider.ProviderDaoImpl$ProviderRowMapper.mapRow(ProviderDaoImpl.java:119) [dal.jar:] ... I filed an issue for that https://bugzilla.redhat.com/show_bug.cgi?id=1438883. Jakub

2 1

Live demo session on how to debug oVirt GWT applications
by Vojtech Szocs 04 Apr '17

04 Apr '17

Hello UI devs, with oVirt master UI using the latest GWT SDK [1], I'd like to host a live demo session with two goals in mind: a, explain how the (Java IDE based) Classic Dev Mode works and mention its limitations b, explain how the (browser based) Super Dev Mode works and encourage people to start using it to boost their productivity [1] http://www.mail-archive.com/devel@ovirt.org/msg08558.html The Classic vs. Super Dev Mode are two possible ways to debug GWT applications. This session will give you the knowledge to decide which one to use in a specific situation. Proposed time: Mon, Apr 3 @ 5pm CET / 6pm TLV / 11am US EST. (This can be changed as needed.) Let me know if this kind of session interests you or if the above time doesn't fit you but you'd still like to join. Thanks, Vojtech

2 5