Re: [CQ]: 103548,1 (vdsm) failed "ovirt-4.3" system tests
by Nir Soffer
On Thu, Sep 26, 2019 at 3:55 PM oVirt Jenkins <jenkins(a)ovirt.org> wrote:
> Change 103548,1 (vdsm) is probably the reason behind recent system test
> failures in the "ovirt-4.3" change queue and needs to be fixed.
>
> This change had been removed from the testing queue. Artifacts build from
> this
> change will not be released until it is fixed.
>
This is a bug in the change queue, because
For further details about the change see:
> https://gerrit.ovirt.org/#/c/103548/1
this is a travis configuration change, and it cannot break system tests :-)
Do we have stats of such failures in the past?
For failed test results see:
> http://jenkins.ovirt.org/job/ovirt-4.3_change-queue-tester/2188/
Maybe we can add a simple file based condition to tell if a patch need to
run
system tests?
For example in vdsm we have this structure:
lib/
static/
tests/
automation/
.travis.ymal
...
Changes in tests/ and automation/ cannot break vdsm during runtime, so there
is no need to run system tests for patches modifying these directories.
Here are changes stats per directory since 4.2:
$ git shortlog -sn --since v4.20.0 ./tests ./automation | awk '{sum+=$1}
END {print sum}'
4579
$ git shortlog -sn --since v4.20.0 ./lib ./static | awk '{sum+=$1} END
{print sum}'
4413
So 50% of the changes cannot break the system and do not require system
tests.
SLOC Directory SLOC-by-Language (Sorted)
65205 lib python=64977,sh=228
62415 tests python=62317,sh=98
3432 vdsm_hooks python=3432
803 contrib python=740,sh=63
468 automation sh=454,python=14
313 static python=210,sh=103
289 init sh=162,python=127
112 build-aux sh=72,python=40
64 top_dir sh=64
30 doc python=30
30 helpers python=30
1 vdsm_log sh=1
0 docker (none)
0 m4 (none)
We can see that the tests are about 50% of the code. This is pretty good
for legacy
project, but if we look in a more modern project like ovirt-imageio:
common:
SLOC Directory SLOC-by-Language (Sorted)
3641 test python=3641
2365 ovirt_imageio_common python=2201,ansic=164
103 top_dir python=103
daemon:
SLOC Directory SLOC-by-Language (Sorted)
1588 test python=1588
792 ovirt_imageio_daemon python=792
18 top_dir python=18
0 data (none)
We see that test code ratio is close to 2/1.
So adding a filter per project that can tell if a patch needs system tests
very important,
and can speed our workflow by fact of 2-3.
Adding infra-support to file a bug, we need to work on this.
Nir
4 years, 7 months
oVirt and CentOS Stream
by Sandro Bonazzola
Progress cannot be made without change. As technologists, we recognize this
every day. Most of the time, these changes are iterative: progressive
additions of features to projects like oVirt. Sometimes those changes are
small, and sometimes not. And that’s, of course, just talking about our
project. But one of the biggest strengths of our community’s software is
that we are not alone, and because of that, changes to other projects have
ripple effects that can affect our own, even in positive ways.
This week, our collaborators in the CentOS Project have announced a change
<https://lists.centos.org/pipermail/centos-announce/2019-September/023449....>
in the way their software is released moving forward.
Beyond this week release of CentOS Linux 8, the CentOS team has announced
CentOS Stream, a rolling release distribution that will be the "midstream"
between Fedora and Red Hat Enterprise Linux.
To be clear, Fedora will remain as the first upstream of RHEL. But when
RHEL branches off, CentOS will be upstream for ongoing work on those RHEL
versions. This change gives public visibility into ongoing work on released
RHEL, and a place for developers and community projects like ours to
collaborate at that level.
CentOS has been heading in the direction of Stream for quite some time.
CentOS SIGs — the special interest groups for virtualization, storage,
config management, and so on — have given our project a way to provide
input into the CentOS platform. Now, though, we can actually provide direct
improvements or fixes to CentOS Stream platform that will be beneficial to
our project. Long-term, those project-specific changes can find their way
into the next release of RHEL, providing smoother transitions for those
users of our downstream projects.
We expect the positive effects to extend beyond our own project’s
ecosystem. Through CentOS Stream, developers will have early access to new
features and content that are being built into the upcoming RHEL version.
This will help to allow next-generation applications to have compatibility
with future versions of RHEL.
The benefits of these changes are clear for ecosystem developers working on
projects such as ours, writing hardware drivers, or extending protocols for
RHEL. As we push the innovations that start in Fedora through the new
CentOS Stream, the community will have a clear vision of the future of Red
Hat Enterprise Linux.
For users of oVirt, we expect CentOS Stream to be the preferred upstream
platform on which oVirt should be run, especially with the capability for
our users to now contribute changes to our software and the community-built
platform on which oVirt runs.
--
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.*
4 years, 7 months
vdsm check patch failed on loopback.py#test_with_device
by Eyal Shenitzky
Hi,
Jenkins check-patch job is failing on:
=================================== FAILURES
===================================
15:19:02 ____________________________ test_with_device[4096]
____________________________
15:19:02
15:19:02 tmpdir = local('/var/tmp/vdsm/test_with_device_4096_0'),
sector_size = 4096
15:19:02
15:19:02 @requires_root
15:19:02 @pytest.mark.parametrize("sector_size", [
15:19:02 None,
15:19:02 pytest.param(sc.BLOCK_SIZE_512,
marks=requires_loopback_sector_size),
15:19:02 pytest.param(sc.BLOCK_SIZE_4K, marks=[
15:19:02 requires_loopback_sector_size,
15:19:02 pytest.mark.xfail(
15:19:02 testing.on_ovirt_ci() and testing.on_fedora("29"),
15:19:02 reason="fails randomly to create loop device with
4k sector "
15:19:02 "size, only in ovirt CI - needs
investigation")
15:19:02 ]),
15:19:02 ])
15:19:02 def test_with_device(tmpdir, sector_size):
15:19:02 filename = str(tmpdir.join("file"))
15:19:02 prepare_backing_file(filename)
15:19:02 > with loopback.Device(filename, sector_size=sector_size)
as device:
15:19:02
15:19:02 storage/loopback_test.py:57:
15:19:02 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ _ _ _
15:19:02 storage/loopback.py:99: in __enter__
15:19:02 self.attach()
15:19:02 storage/loopback.py:66: in attach
15:19:02 out = commands.run(cmd)
15:19:02 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ _ _ _
15:19:02
I noticed that was a recent fix for that test -
https://gerrit.ovirt.org/#/c/100928/
Link to the failing job -
https://jenkins.ovirt.org/job/vdsm_standard-check-patch/12021/consoleFull
Nir, can you have a look?
--
Regards,
Eyal Shenitzky
4 years, 7 months
PROBLEM: Unable to retrieve value for MTU when default is used
by james.holohan＠oracle.com
I'm trying to automate a test which checks that the default values are being set correctly when adding a network to a host. When I create a network without specifying a value for the MTU, I can see from the web UI that the default value (1500) is being used.
When I try to retrieve this MTU value from the SDK to ensure it is set correctly, the value returned is '0'.
The same issue is not occurring if I explicitly set the MTU value when creating the network. When the MTU value is assigned, instead of using the default value, it is possible to retrieve it from the SDK correctly.
Is there any way I can retrieve the value for MTU from the SDK when the default is used?
4 years, 7 months
[ACTION REQUIRED] unicode patches merged, update otopi
by Yedidyah Bar David
Hi all,
I now merged my pending patches to make otopi use unicode strings for
"everything" (well, partially, for now) instead of "str" in python2.
There were two stacks of patches - one for the engine and one for
otopi. So if you git pull from the engine and it breaks, try to update
otopi and see if it helps. If not, ping me :-)
Best regards,
--
Didi
4 years, 7 months
planned Jenkins restart
by Evgheni Dereveanchin
Hi everyone,
I'll be performing a planned Jenkins restart within the next hour.
No new jobs will be scheduled during this maintenance period.
I will inform you once it is back online.
--
Regards,
Evgheni Dereveanchin
4 years, 7 months
