- Devel - oVirt List Archives

Tests failure when building the latest master
by Shmuel Melamud 20 Apr '17

20 Apr '17

Hi! Just tried to build the latest Engine from master and got a lot of test failures. All related to ThreadPoolUtil. For example: onSuccessReturnValueOk(org.ovirt.engine.core.bll.pm.StartVdsCommandTest) Time elapsed: 0 sec <<< ERROR! java.lang.ExceptionInInitializerError at org.ovirt.engine.core.bll.VdsCommand.runSleepOnReboot(VdsCommand.java:103) at org.ovirt.engine.core.bll.VdsCommand.runSleepOnReboot(VdsCommand.java:99) at org.ovirt.engine.core.bll.pm.StartVdsCommand.teardown(StartVdsCommand.java:131) at org.ovirt.engine.core.bll.pm.FenceVdsBaseCommand.executeCommand(FenceVdsBaseCommand.java:118) ..... Caused by: java.lang.NullPointerException at org.ovirt.engine.core.common.config.Config.getValue(Config.java:22) at org.ovirt.engine.core.common.config.Config.getValue(Config.java:18) at org.ovirt.engine.core.utils.threadpool.ThreadPoolUtil$InternalThreadExecutor.<init>(ThreadPoolUtil.java:34) at org.ovirt.engine.core.utils.threadpool.ThreadPoolUtil.<clinit>(ThreadPoolUtil.java:110) at org.ovirt.engine.core.bll.VdsCommand.runSleepOnReboot(VdsCommand.java:103) at org.ovirt.engine.core.bll.pm.StartVdsCommand$MockitoMock$1274036240.runSleepOnReboot$accessor$RBFb71Df(Unknown Source) .... Do you know what may cause this? Shmuel

2 2

Communicate between the guest vm's hosted on different hosts on different data centres using OVS
by Linov Suresh 20 Apr '17

20 Apr '17

Hello, I have configured OVS network on oVirt 4.1.1, following the document https://www.ovirt.org/blog/2016/11/ovirt-provider-ovn/ I have created OVN Provider, and created new Logical Network for OVS using OVN Provider. I have synced the network also selected OVS when I created the cluster. I have two data centres and each data centre has one host each. Now I have created VM's selecting OVS network (not ovirtmgmt). VM's in the same data centre can talk to each other. How do i make the VM's hosted on different data centre can talk to each other? Appreciate your help in advance, Sincerely, Suresh.

1 0

Fwd: Announcing Bugzilla 5 Public Beta!
by Sandro Bonazzola 20 Apr '17

20 Apr '17

---------- Forwarded message ---------- From: Christine Freitas <cfreitas(a)redhat.com> Date: Thu, Apr 20, 2017 at 12:45 AM Subject: Announcing Bugzilla 5 Public Beta! Hello All, We are pleased to announce Red Hat's Bugzilla 5 beta [1]! We’re inviting all of you to participate. We encourage you to test your current scripts against this new version and take part in the beta discussions on the Fedora development list [2]. Partners and customers may also use their existing communications channels to share feedback or questions. We ask that you provide feedback or questions by Wednesday, May 17th. Here is a short list of some of the changes in Bugzilla 5: - Major improvements in the WebServices interface, including a new REST-like endpoint, allowing clients to access data using standard HTTP calls for easy development. - The UI has been significantly overhauled for a modern browsing experience. - Performance improvements, including caching improvements to allow faster access to certain types of data. - Red Hat Associates, Customers and Fedora Account System users can now log in using SAML. - The addition of some of the Bayoteers extensions allowing features such as inline editing of bugs in search results, team management and scrum tools, etc. - Ye Olde diff viewer has been replaced with the modern diff2html diff viewer - Improved, updated documentation including a rewrite using the reStructuredText format, which allows documentation to be more easily converted into different formats such as HTML and PDF, etc The official release date for Bugzilla 5 will be determined based on the beta feedback. We will communicate to you as the beta progresses. For more information refer to: https://beta-bugzilla.redhat.com/page.cgi?id=whats-new.html https://beta-bugzilla.redhat.com/page.cgi?id=release-notes.html https://beta-bugzilla.redhat.com/page.cgi?id=faq.html https://beta-bugzilla.redhat.com/docs/en/html/using/index.html https://beta-bugzilla.redhat.com/docs/en/html/api/index.html Cheers, the Red Hat Bugzilla team. 1: https://beta-bugzilla.redhat.com/ 2: https://lists.fedoraproject.org/archives/list/devel%40lists. fedoraproject.org/ -- 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

[ OST Failure Report ] [ oVirt 4.1 ] [ 23-03-2017 ] [ 002_bootstrap.add_secondary_storage_domains ]
by Shlomo Ben David 20 Apr '17

20 Apr '17

Hi, Test failed: [ 002_bootstrap.add_secondary_storage_domains ] Link to suspected patches: N/A Link to Job: http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_4.1/1054 Link to all logs: http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_4.1/1054/artifact… Error snippet from the log: <error> 2017-03-23 07:23:38,867-0400 ERROR (jsonrpc/2) [storage.TaskManager.Task] (Task='8347d74c-92fe-4371-bc84-1314a43a2971') Unexpected error (task:870) Traceback (most recent call last): File "/usr/share/vdsm/storage/task.py", line 877, 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 1159, 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 924, 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'127fbe66-204c-4c6d-b521-d0f431af2b6c',) </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

2 1

[ OST Failure Report ] [ oVirt master ] [ 20.4.17 ] [ add_secondary_storage_domains ]
by Gil Shinar 20 Apr '17

20 Apr '17

Test failed: add_secondary_storage_domains Link to suspected patches: Link to Job: http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/6403 Link to all logs: http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/6403/artif… Error seems to be: *2017-04-19 18:58:58,774-0400 ERROR (jsonrpc/2) [storage.TaskManager.Task] (Task='8f9699ed-cc2f-434b-aa1e-b3c8ff30324a') 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 2709, in getStorageDomainInfo dom = self.validateSdUUID(sdUUID) File "/usr/share/vdsm/storage/hsm.py", line 298, in validateSdUUID sdDom = sdCache.produce(sdUUID=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'ac3bbc93-26ba-4ea8-8e76-c5b761f01931',)2017-04-19 18:58:58,777-0400 INFO (jsonrpc/2) [storage.TaskManager.Task] (Task='8f9699ed-cc2f-434b-aa1e-b3c8ff30324a') aborting: Task is aborted: 'Storage domain does not exist' - code 358 (task:1176)2017-04-19 18:58:58,777-0400 ERROR (jsonrpc/2) [storage.Dispatcher] {'status': {'message': "Storage domain does not exist: (u'ac3bbc93-26ba-4ea8-8e76-c5b761f01931',)", 'code': 358}} (dispatcher:78)*

4 9

Announcing VM Portal 0.1.4
by Marek Libra 20 Apr '17

20 Apr '17

Hello All, Let me announce availability of the VM Portal v0.1.4 for preliminary testing. We are looking forward to your feedback which we will try to incorporate into oncoming stable 1.0.0 version. The VM Portal aims to be a drop-in replacement of the existing Basic User Portal. Revised list of Extended User Portal features will be implemented to ideally replace it as well. The VM Portal is installed by default since oVirt 4.1. *The simplest way to try latest version is via Docker by [1].* Once oVirt credentials are entered and initialization is finished, you can access it on [2]. If you prefer to stay as closest to the production setup as possible, the latest rpms are available on project's yum repo [3]. Then you can access the portal from [4]. Prerequisites: The VM Portal requires ovirt-engine 4.0+, so far mostly tested on 4.1. Please note, the docker image is so far meant to just simplify user testing and is not ready for production setup. Unless decided otherwise in the future, stable releases are still planed to be deployed via rpms. For issue reporting or enhancement ideas, please use project's github issue tracker [5]. Thank you for your feedback, Marek [1] docker run --rm -it -e ENGINE_URL=https://[OVIRT.ENGINE.FQDN]/ovirt-engine/ -p 3000:3000 mareklibra/ovirt-web-ui:latest [2] http://localhost:3000 [3] https://people.redhat.com/mlibra/repos/ovirt-web-ui [4] https://[OVIRT.ENGINE.FQDN]/ovirt-engine/web-ui [5] https://github.com/oVirt/ovirt-web-ui/issues -- Marek Libra senior software engineer Red Hat Czech <https://www.redhat.com>

3 2

Fwd: F27 Self Contained Change: Java 9
by Sandro Bonazzola 19 Apr '17

19 Apr '17

FYI ---------- Forwarded message ---------- From: Jan Kurik <jkurik(a)redhat.com> Date: Wed, Apr 19, 2017 at 2:13 PM Subject: F27 Self Contained Change: Java 9 To: Development discussions related to Fedora <devel(a)lists.fedoraproject.org>, devel-announce(a)lists.fedoraproject.org = Proposed Self Contained Change: Java 9 = https://fedoraproject.org/wiki/Changes/Java9TechPreview Change owner(s): * Jiri Vanek <jvanek at redhat dot com> Add a tech preview preview of the the upcoming version of Java (OpenJDK9) to Fedora 27 == Detailed Description == The current Java implementation in Fedora comes from OpenJDK. Java 9 (and OpenJDK9) are tentatively scheduled for release in 2017-07-27. Fedora 27 will most likely be out just a few months after that, and is therefore positioned to receive a tech preview version of the latest OpenJDK9 candidates. This preview should be released version of Java 9, will contain new Java 9 APIs, but may not be supported by many applications directly, therefore it have to warm up as techpreview. == Scope == The current version of OpenJDK 9 will be packaged and added to Fedora. It will be a stand alone package and will not impact existing OpenJDK 8 packages. Since this will be a tech preview, the primary JDK in Fedora 27 will continue to be OpenJDK8. OpenJDK9 is not expected to be the primary Java until Fedora 28 at least. Two problems would generally be expected with a major JDK update based on past experience: FTFBS failures due to packages having a hard-coded JDK version dependency. This was dealt with when both OpenJDK8 and OpenJDK7 were introduced over Fedora 16/17 and Fedora 19/21. Now all Java dependent packages should require java >= 1.6.0, and therefore this issue will not be a problem any more. There may be packages that rely on API that is deprecated in Java 9 Such packages cannot be identified until we actually start to build with Java 9. Since Java 8 will continue to remain the primary version of Java in Fedora 26, any API deprecation issues will be a secondary problem as the main JVM will continue to be able to run everything correctly. We expect to have everything resolved well before Java 9 is to become the primary Java version in Fedora (F28 or later). * Proposal owners: providing java-9-openjdk package to main repositories * Other developers: N/A (not a System Wide Change) * Release engineering: only the inclusion of new package is needed * List of deliverables: N/A (not a System Wide Change) * Policies and guidelines: N/A (not a System Wide Change) * Trademark approval: N/A (not needed for this Change) -- Jan Kuřík Platform & Fedora Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic _______________________________________________ devel mailing list -- devel(a)lists.fedoraproject.org To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org -- 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

[VDSM] [ENGINE] [RFC] A configuration verb for contexual vdsm operation mode
by Roy Golan 19 Apr '17

19 Apr '17

I'm working on a POC lately on a change to stats collection and retrieval by VDSM. The moto is to cut all we can from host/vm stats (possibly caps) and report only core-business stuff to the engine. Engine will retrieve the rest through a 3rd party provider (nevermind what is it atm) Being backward compatible by design, I have to support 2 API versions for Host.getStats , '4.1' and '4.2'. Except from supplying less parameters, I want VDSM to do less stuff. It doesn't need to sample what it doesn't report. In other words I want '4.1-sampling' and '4.2-sampling' # Introducing 'configuration' Verb: As engine knows always(Hosted Engine as well) what cluster version this host belongs to, it can configure VDSM to operate in cluster version mode. Host.configure(config={version: 4.2} Consider this verb, pre-activating using 'Host.getCaps' to set the context. It will set the righjt sampling method, and other stuff if needed then API endpoints will have the right permutation of the api to answer it. 4.2 host can operate in 4.1 mode: Host.configure(config={version: 4.1} Issue: moving a 4.2 host from 4.2 cluster to 4.1 is a problem since engine needs to know this is a new vdsm that has the verb available. One way to overcome that is to fire the verb for every host regardless of the version and disregard an error that implies the verb doesn't exist. # Engine: Engine will have a handling of the verb per version. Host/Vms monitoring should be changed - I suggest to move out of the monitoring code the whole stats collection as it is a different task which is orthogonal to 'monitoring' and in 4.2 more than before. I know configuration for VDSM has been discussed before and there are probably tons of ways to do it. When you share your thoughts please remember that configuration is a by-product of the effort. Nevertheless it can be potentially beneficial to more functions in vdsm. Thanks, Roy

6 14

Feedback from oVirt community survey
by Sandro Bonazzola 14 Apr '17

14 Apr '17

Hi, from oVirt survey, here are the suggestion from community: - I want oVirt built reporting for hosts and VMs performance analyze - Please add some more fancy icons to the Engine. Also, if possible add icons to the menus when you click with right button. Helps A LOT with User Experience. - Improve where there options are to make easy to find them. Two examples: a Storage Migration option (not only a Live Migration) in the main VM menu and an easier way to manage Snapshots as for example revert back to previous snapshot when something goes wrong within the Guest. - I think the project need some more enterprise features like: - performance monitoring - alerting - more robust import/export tools from other enterprise virtualization solutions - direct Ceph support. - The killer feature can be SDN like VMware NSX - I use a lot of scripts based on ovirtsdk3 and ovirtshell and It's a matter that there is no adaptation of the CLI to sdk4 - Need a stable backup implementation - Node cannot have shared storage and local storage on one host. - Please improve ceph support -- 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

How do you oVirt? Here the answers!
by Sandro Bonazzola 14 Apr '17

14 Apr '17

Hi, a few weeks ago I opened a survey asking oVirt users about how they use oVirt. Here are the analytics of the survey: https://docs.google.com/forms/d/1s3k4pq_U4vHTuUUKr6dOosGj_EGFxqEisansHlqnyy… Most notable facts: - 197 responses, two times the responses we got with the 3.6 survey! - CentOS confims as the most used distribution for running oVirt engine (89.8%) and Hypervisors (74.3% which become 94.2% including oVirt Node which is a CentOS spin) - Fedora is the second distribution (4.6%) mostly used only for runnig oVirt engine - oVirt Node jumped from 7.1% on 3.6 survey to 19.9% in 4.1! - Surprisingly we have someone running both engine and hypervisor on Ubuntu based system, within VMs. I'd like to hear more about this use case. - Within other OS we had Red Hat Enterprise Linux 6 and 7 and Scientific Linux (I guess 7, wasn't specified) - Within the storage, there isn't a "winner" between NFS, Gluster and iSCSI. Within Other Storage, Fiber Channel is the most used. We had also: Ceph, DAS, EMC ScaleIO, GPFS - Hosted Engine is the most used deployment choice with 58.4% (was 50.0% in 3.6) - 65.8% of Hosted Engine users use it in Hyperconverged setup. Thank you for your feedback and appreciation, we'll look into suggestions you sent in the survey. -- 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