August 2019 - Devel - Ovirt List Archives

Nominate Sharon and Michal as ovirt-engine-nodejs-modules maintainers

by Vojtech Szocs

Hi everyone, I'd like to nominate Sharon and Michal as ovirt-engine-nodejs-modules <https://gerrit.ovirt.org/#/admin/projects/ovirt-engine-nodejs-modules> project maintainers. This project is a build-time dependency of oVirt web-related projects, providing the required npm (JavaScript) dependencies via single RPM package. Projects that depend on ovirt-engine-nodejs-modules include (see here <https://gerrit.ovirt.org/gitweb?p=ovirt-engine-nodejs-modules.git;a=blob_...> for details): - ovirt-web-ui <https://github.com/oVirt/ovirt-web-ui> (next-gen User Portal) - ovirt-engine-ui-extensions <https://gerrit.ovirt.org/#/admin/projects/ovirt-engine-ui-extensions> (UI plugin for Admin Portal) - cockpit-ovirt <https://gerrit.ovirt.org/#/admin/projects/cockpit-ovirt> (plugins for Cockpit) Both Sharon and Michal are familiar with these projects and having them as maintainers would help with resolving any issues related to oVirt JS dependencies. Thanks, Vojtech

5 years, 2 months

6
5
0 / 0

OST upgrade-from-release-suite-master update_cluster_versions failing

by Dominik Holler

Hi, for me OST upgrade-from-release-suite-master update_cluster_versions is failing with 004_basic_sanity.update_cluster_versions (from nosetests) Failing for the past 1 build (Since Failed#5442 ) Took 1 min 16 sec. add description Error Message Fault reason is "Operation Failed". Fault detail is "[Update of cluster compatibility version failed because there are VMs/Templates [vm-with-iface, vm-with-iface-template, vm0, vm1] with incorrect configuration. To fix the issue, please go to each of them, edit, change the Custom Compatibility Version of the VM/Template to the cluster level you want to update the cluster to and press OK. If the save does not pass, fix the dialog validation. After successful cluster update, you can revert your Custom Compatibility Version change.]". HTTP response code is 500. Stacktrace Traceback (most recent call last): File "/usr/lib64/python2.7/unittest/case.py", line 369, in run testMethod() File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/usr/lib/python2.7/site-packages/ovirtlago/testlib.py", line 142, in wrapped_test test() File "/usr/lib/python2.7/site-packages/ovirtlago/testlib.py", line 60, in wrapper return func(get_test_prefix(), *args, **kwargs) File "/usr/lib/python2.7/site-packages/ovirtlago/testlib.py", line 79, in wrapper prefix.virt_env.engine_vm().get_api(api_ver=4), *args, **kwargs File "/home/jenkins/workspace/ovirt-system-tests_manual/ovirt-system-tests/upgrade-from-release-suite-master/test-scenarios-after-upgrade/004_basic_sanity.py", line 184, in update_cluster_versions minor=minor File "/home/jenkins/workspace/ovirt-system-tests_manual/ovirt-system-tests/upgrade-from-release-suite-master/test-scenarios-after-upgrade/004_basic_sanity.py", line 130, in _update_cluster_version version=new_version File "/usr/lib64/python2.7/site-packages/ovirtsdk4/services.py", line 3943, in update return self._internal_update(cluster, headers, query, wait) File "/usr/lib64/python2.7/site-packages/ovirtsdk4/service.py", line 253, in _internal_update return future.wait() if wait else future File "/usr/lib64/python2.7/site-packages/ovirtsdk4/service.py", line 55, in wait return self._code(response) File "/usr/lib64/python2.7/site-packages/ovirtsdk4/service.py", line 250, in callback self._check_fault(response) File "/usr/lib64/python2.7/site-packages/ovirtsdk4/service.py", line 132, in _check_fault self._raise_error(response, body) File "/usr/lib64/python2.7/site-packages/ovirtsdk4/service.py", line 118, in _raise_error raise error Error: Fault reason is "Operation Failed". Fault detail is "[Update of cluster compatibility version failed because there are VMs/Templates [vm-with-iface, vm-with-iface-template, vm0, vm1] with incorrect configuration. To fix the issue, please go to each of them, edit, change the Custom Compatibility Version of the VM/Template to the cluster level you want to update the cluster to and press OK. If the save does not pass, fix the dialog validation. After successful cluster update, you can revert your Custom Compatibility Version change.]". HTTP response code is 500. Please find an example run in https://jenkins.ovirt.org/view/oVirt system tests/job/ovirt-system-tests_manual/5442 Is this a known error, or is someone already addressing this issue? Thanks Dominik

5 years, 2 months

3
10
0 / 0

mailing list

by Hetz Ben Hamo

Hi, Any chance that someone will take a look at the ovirt mailing list server? Trying to access https://lists.ovirt.org/archives/list/devel%40ovirt.org/ gives error 500 Thanks תודה, *חץ בן חמו* אתם מוזמנים לבקר בבלוג היעוץ <http://linvirtstor.net/> או בבלוג הפרטי שלי <http://benhamo.org>

5 years, 2 months

2
1
0 / 0

ovirt-engine has been tagged (ovirt-engine-4.3.6.4)

by Tal Nisan

5 years, 2 months

1
0
0 / 0

CI fails - tox error

by Pavel Bar

Hi, We experience problems with failed CI on VDSM patches. Examples: http://jenkins.ovirt.org/job/vdsm_standard-check-patch/10633/ http://jenkins.ovirt.org/job/vdsm_standard-check-patch/10634/ http://jenkins.ovirt.org/job/vdsm_standard-check-patch/10635/ This is what we see in logs: out=`tox --version`; \ if [ $? -ne 0 ]; then \ echo "Error: cannot run tox, please install tox \ 2.9.1 or later"; \ exit 1; \ fi; \ version=`echo $out | cut -d' ' -f1`; \ if python2.7 build-aux/vercmp $version 2.9.1; then \ echo "Error: tox is too old, please install tox \ 2.9.1 or later"; \ exit 1; \ fi Traceback (most recent call last): File "/usr/bin/tox", line 7, in <module> from tox import cmdline File "/usr/lib/python2.7/site-packages/tox/__init__.py", line 4, in <module> from .hookspecs import hookimpl File "/usr/lib/python2.7/site-packages/tox/hookspecs.py", line 4, in <module> from pluggy import HookimplMarker File "/usr/lib/python2.7/site-packages/pluggy/__init__.py", line 16, in <module> from .manager import PluginManager, PluginValidationError File "/usr/lib/python2.7/site-packages/pluggy/manager.py", line 6, in <module> import importlib_metadata File "/usr/lib/python2.7/site-packages/importlib_metadata/__init__.py", line 9, in <module> import zipp File "/usr/lib/python2.7/site-packages/zipp.py", line 12, in <module> import more_itertools File "/usr/lib/python2.7/site-packages/more_itertools/__init__.py", line 1, in <module> from more_itertools.more import * # noqa File "/usr/lib/python2.7/site-packages/more_itertools/more.py", line 340 def _collate(*iterables, key=lambda a: a, reverse=False): ^ SyntaxError: invalid syntax Error: cannot run tox, please install tox 2.9.1 or later make: *** [tox] Error 1 + teardown + res=2 + '[' 2 -ne 0 ']' + echo '*** err: 2' *** err: 2 + collect_logs + tar --directory /var/log --exclude 'journal/*' -czf /home/jenkins/workspace/vdsm_standard-check-patch/vdsm/exported-artifacts/mock_varlogs.tar.gz . + tar --directory /var/host_log --exclude 'journal/*' -czf /home/jenkins/workspace/vdsm_standard-check-patch/vdsm/exported-artifacts/host_varlogs.tar.gz . + teardown_storage + python2 tests/storage/userstorage.py teardown Can someone look at it? Thank you in advance! Pavel

5 years, 2 months

3
3
0 / 0

[oVirt] [CQ weekly status] [25-08-2019]

by Dusan Fodor

Hi, This mail is to provide the current status of CQ and allow people to review status before and after the weekend. Please refer to below colour map for further information on the meaning of the colours. *CQ-4.2*: GREEN (#2) Last failure was on 20-08 for ovirt-ansible-hosted-engine-setup. It was caused by random network issue (fetching repo from github), retriggered job for the change passed well. *CQ-4.3*: GREEN (#2) Last failure was on 20-08 for ovirt-ansible-hosted-engine-setup. It was caused by random network issue, retriggered job for the change passed well. *CQ-Master:* RED (#1) Last failure was on 25-08 for ovirt-engine, caused by failed cloning of engine repo (even with lately increased timeout value 20min). Related ticket from last time was reopened. Current running jobs for 4.2 [1], 4.3 [2] and master [3] can be found here: [1] http://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt -4.2_change-queue-tester/ [2] https://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt -4.3_change-queue-tester/ [3] http://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt -master_change-queue-tester/ Have a nice week! Dusan ------------------------------------------------------------------------------------------------------------------- COLOUR MAP Green = job has been passing successfully ** green for more than 3 days may suggest we need a review of our test coverage 1. 1-3 days GREEN (#1) 2. 4-7 days GREEN (#2) 3. Over 7 days GREEN (#3) Yellow = intermittent failures for different projects but no lasting or current regressions ** intermittent would be a healthy project as we expect a number of failures during the week ** I will not report any of the solved failures or regressions. 1. Solved job failures YELLOW (#1) 2. Solved regressions YELLOW (#2) Red = job has been failing ** Active Failures. The colour will change based on the amount of time the project/s has been broken. Only active regressions would be reported. 1. 1-3 days RED (#1) 2. 4-7 days RED (#2) 3. Over 7 days RED (#3) _______________________________________________ Devel mailing list -- devel(a)ovirt.org To unsubscribe send an email to devel-leave(a)ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt .org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/devel@ovirt .org/message/YCNCKRK3G4EJXA3OCYAUS4VMKRDA67F4/

5 years, 3 months

1
0
0 / 0

[feedback needed] CentOS guest images with pre-installed ovirt-guest-agent

by Sandro Bonazzola

Hi, please help CentOS Virtualization SIG testing https://buildlogs.centos.org/centos/images/ovirt/ if we can confirm they're working fine we'll have them built regularly with new CentOS releases. You can just reply here or directly to me with your feedback. Thanks, -- Sandro Bonazzola MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://www.redhat.com/>*Red Hat respects your work life balance. Therefore there is no need to answer this email out of your office hours.*

5 years, 3 months

1
0
0 / 0

Relaunching the website migration project

by Marc Dequènes (Duck)

Quack, ### A pinch of history As a short introduction for those who do not know me as I rarely post here: I'm part of Red Hat OSPO Comminfra Team (previously OSPO was called OSAS) and currently hosting and taking care of the website. This topic has been discussed many times: neither people writing the site neither us for the maintenance are happy with the current state of affair. But we had not real plan and picking a random tool which might lead to similar problems and without any way to support it properly was not very appealing. Moreover we tried migrating to Middleman 4, the obvious path to modernization, but this happened to be more complicated than expected and this new version had terrible performance problems. As you now version 3 is already slow, and that's quite an understatement. In the meanwhile a few things have changed, and people taking care of the website too, so let's talk about the current situation. (very short version of the history around this) ### Why now? What has changed: * several projects moved to Jekyll, a software we were already investigating at the time and is being used by Google Pages (they created it in fact), and they were very happy with the result; we believe it has the necessary features, it is well maintained because Google uses it heavily, and it's very fast * we've tried Jekyll ourselves, we're happy too, and we do have the Ansible playbooks and tooling to deploy it now * over time the website had some waves of cleanup (still needs quite some love though) and recently the blog moved to WordPress to get comment support and a more friendly interface (see OVIRT-2652) which allowed more cleanup (see #2030) With the blog separated and a lot of custom Ruby code removed, the tooling ready, I believe we can now work on migrating the content. We may realize Jekyll is not the right tool, but people seemed to like the idea at the time and current experience seem to indicate it should improve things and be maintainable. The goal here is to experiment and switch to production only if we're happy with it. ### Early work I have started a branch called 'jekyll_migration' to put my work on it. This is very early work (I just started), I already hit various difficulties, and I can't commit 100% of my time on it so it will require some time. Several of my changes happened to not be really specific to the migration, and the current site would benefit from these fixes/cleanups/simplifications… thus I'll extracts these changes and create separate PRs for master. If you wish to help, then you can contact me directly or reply to this thread. You may also create PRs to this topic branch, but please do not push anything directly. Regards. \_o<

5 years, 3 months

5
9
0 / 0

jenkins CI failing to fetch repo

by Miguel Duarte de Mora Barroso

Hi, Since yesterday I can't get ovirt-provider-ovn builds to run, each manifesting the error below: error: index-pack died of signal 15 09:27:35 fatal: index-pack failed 09:27:35 09:27:35 at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:2042) 09:27:35 at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1761) 09:27:35 at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$400(CliGitAPIImpl.java:72) 09:27:35 at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:442) 09:27:35 at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$2.execute(CliGitAPIImpl.java:655) 09:27:35 at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:153) 09:27:35 at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:146) 09:27:35 at hudson.remoting.UserRequest.perform(UserRequest.java:212) 09:27:35 at hudson.remoting.UserRequest.perform(UserRequest.java:54) 09:27:35 at hudson.remoting.Request$2.run(Request.java:369) 09:27:35 at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) 09:27:35 at java.util.concurrent.FutureTask.run(FutureTask.java:266) 09:27:35 at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) 09:27:35 at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) 09:27:35 at java.lang.Thread.run(Thread.java:748) 09:27:35 Suppressed: hudson.remoting.Channel$CallSiteStackTrace: Remote call to vm0038.workers-phx.ovirt.org 09:27:35 at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1743) 09:27:35 at hudson.remoting.UserRequest$ExceptionResponse.retrieve(UserRequest.java:357) 09:27:35 at hudson.remoting.Channel.call(Channel.java:957) 09:27:35 at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.execute(RemoteGitImpl.java:146) 09:27:35 at sun.reflect.GeneratedMethodAccessor793.invoke(Unknown Source) 09:27:35 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) 09:27:35 at java.lang.reflect.Method.invoke(Method.java:498) 09:27:35 at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.invoke(RemoteGitImpl.java:132) 09:27:35 at com.sun.proxy.$Proxy118.execute(Unknown Source) 09:27:35 at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1152) 09:27:35 at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1192) 09:27:35 at org.jenkinsci.plugins.workflow.steps.scm.SCMStep.checkout(SCMStep.java:124) 09:27:35 at org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:93) 09:27:35 at org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:80) 09:27:35 at org.jenkinsci.plugins.workflow.steps.SynchronousNonBlockingStepExecution.lambda$start$0(SynchronousNonBlockingStepExecution.java:47) 09:27:35 at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 09:27:35 ... 4 more It can be seen on: - https://jenkins.ovirt.org/job/ovirt-provider-ovn_standard-check-patch/247...

5 years, 3 months

2
2
0 / 0

Re: Is only master branch of ovirt-engine analyzed on coverity scan?

by Nasif Imtiaz

Hi Martin, We finished a paper on open source projects' Coverity usage in May which will be published in ISSRE'19 <http://2019.issre.net/>. (Attached) Thanks for your help in giving me access to Coverity data. I'd love to hear your feedback on this whenever you have time. Also, based on your experience of using static analysis tools, I'd love to hear if you have any future research suggestions. Thanks again, Nasif

5 years, 3 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Devel August 2019