Mailing-Lists upgrade
by Marc Dequènes (Duck)
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--IfGqXrbgT9wNNdIsvS8kI8WdhEQHlgkiq
Content-Type: multipart/mixed; boundary="AUFHCWPQQknM84fF2kF4uGjIv4blC9bMv";
protected-headers="v1"
From: =?UTF-8?B?TWFyYyBEZXF1w6huZXMgKER1Y2sp?= <duck(a)redhat.com>
To: oVirt Infra <infra(a)ovirt.org>, users <users(a)ovirt.org>,
devel <devel(a)ovirt.org>
Message-ID: <c5c71fce-0290-e97a-ddd0-eab0e6fccea4(a)redhat.com>
Subject: Mailing-Lists upgrade
--AUFHCWPQQknM84fF2kF4uGjIv4blC9bMv
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Quack,
On behalf of the oVirt infra team, I'd like to announce the current
Mailing-Lists system is going to be upgraded to a brand new Mailman 3
installation on Monday during the slot 11:00-12:00 JST.
It should not take a full hour to migrate as we already made incremental
synchronization with the current system but better keep some margin. The
system will then take over delivery of the mails but might be a bit slow
at first as it needs to reindex all the archived mails (which might take
a few hours).
To manage your subscriptions and delivery settings you can do this
easily on the much nicer web interface (https://lists.ovirt.org). There
is a notion of account so you don't need to login separately for each ML.=
You can Sign In using Fedora, GitHub or Google or create a local account
if you prefer. Please keep in mind signing in with a different method
would create separate accounts (which cannot be merged at the moment).
But you can easily link your account to other authentication methods in
your settings (click on you name in the up-right corner -> Account ->
Account Connections).
As for the original mail archives, because the previous system did not
have stable URLs, we cannot create mappings to the new pages. We decided
to keep the old archives around on the same URL (/pipermail), so the
Internet links would still work fine.
Hope you'd be happy with the new system.
\_o<
--AUFHCWPQQknM84fF2kF4uGjIv4blC9bMv--
--IfGqXrbgT9wNNdIsvS8kI8WdhEQHlgkiq
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEcpcqg+UmRT3yiF+BVen596wcRD8FAlmwx0MACgkQVen596wc
RD9LTQ/+LtUncsq9K8D/LX8wqUTd6VyPwAD5UnAk5c3H/2tmyVA0u7FIfhEyPsXs
Z//LE9FEneTDqDVRi1Dw9I54K0ZwxPBemi71dXfwgBI7Ay0ezkbLWrA168Mt9spE
tHAODEuxPt2to2aqaS4ujogrkp/gvEP8ILoxPEqoTPCJ/eDTPAu/I1a2JzjMPK3n
2BBS6D8z0TLAf7w1n72TsgX2QzJW57ig/0HELyjvat2/K8V3HSrkwiKlsdULQDWe
zB+aMde7r6UoyVKHqlu4asTl2tU/lGZ+e31Hd9Bnx1/oZOJdzslGOhEo9Qoz6763
AHWU9LKiK4NtxYHj2UQTWhndr8PiTtTmR73eIDmkb0cuRXxzjl9VQbwYJ0Kbrmfp
attTqpc2CnEojTNXUUNSmNxotZoYXZiX8ZvjPfSgRVr15TUYujzlOfG+lUynbQMV
9rQ9/m58wgwYUymMpOIsRGaIcAKzjm+WpuuVnO+bS2AfmcBkGMQRoIhfV+3SkS8q
kT9cDXgcDZOzVFcnZZB4EjbycMcPgZDcoHxU88VdYH+jFJYvvb21esgswVF/wJ2Z
uEI/chp4+ADaQhl8ehZNWMSZq125v6SeirPhBNgLG7zFVZI1S9Tm/6qFmH+ajQY7
nCk1X9HZlB1ubex1X+HibRz9QKOilkMgkADyJ4yMDckwYj93sx0=
=l6uN
-----END PGP SIGNATURE-----
--IfGqXrbgT9wNNdIsvS8kI8WdhEQHlgkiq--
5 years, 12 months
Re: [ovirt-devel] [virt-tools-list] Project for profiles and defaults for libvirt domains
by Martin Kletzander
--ieNMXl1Fr3cevapt
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
[ I fixed up ovirt-devel(a)redhat.com to be devel(a)ovirt.org since the
former is deprecated. I'm also not trimming down much of the reply so
that they can get the whole picture. Sorry for the confusion ]
On Tue, Mar 20, 2018 at 03:10:12PM +0000, Daniel P. Berrang=E9 wrote:
>On Tue, Mar 20, 2018 at 03:20:31PM +0100, Martin Kletzander wrote:
>> 1) Default devices/values
>>
>> Libvirt itself must default to whatever values there were before any
>> particular element was introduced due to the fact that it strives to
>> keep the guest ABI stable. That means, for example, that it can't just
>> add -vmcoreinfo option (for KASLR support) or magically add the pvpanic
>> device to all QEMU machines, even though it would be useful, as that
>> would change the guest ABI.
>>
>> For default values this is even more obvious. Let's say someone figures
>> out some "pretty good" default values for various HyperV enlightenment
>> feature tunables. Libvirt can't magically change them, but each one of
>> the projects building on top of it doesn't want to keep that list
>> updated and take care of setting them in every new XML. Some projects
>> don't even expose those to the end user as a knob, while others might.
>
>This gets very tricky, very fast.
>
>Lets say that you have an initial good set of hyperv config
>tunables. Now sometime passes and it is decided that there is a
>different, better set of config tunables. If the module that is
>providing this policy to apps like OpenStack just updates itself
>to provide this new policy, this can cause problems with the
>existing deployed applications in a number of ways.
>
>First the new config probably depends on specific versions of
>libvirt and QEMU, and you can't mandate to consuming apps which
>versions they must be using. So you need a matrix of libvirt +
>QEMU + config option settings.
>
>Even if you have the matching libvirt & QEMU versions, it is not
>safe to assume the application will want to use the new policy.
>An application may need live migration compatibility with older
>versions. Or it may need to retain guaranteed ABI compatibility
>with the way the VM was previously launched and be using transient
>guests, generating the XML fresh each time.
>
>The application will have knowledge about when it wants to use new
>vs old hyperv tunable policy, but exposing that to your policy module
>is very tricky because it is inherantly application specific logic
>largely determined by the way the application code is written.
>
The idea was for updating XML based on policy, which is something you
want for new machines. You should then keep the XML per domain and only
do changes to if requested by the user or when libvirt fills in new
values in a guest ABI compatible fashion.
>
>> One more thing could be automatically figuring out best values based on
>> libosinfo-provided data.
>>
>> 2) Policies
>>
>> Lot of the time there are parts of the domain definition that need to be
>> added, but nobody really cares about them. Sometimes it's enough to
>> have few templates, another time you might want to have a policy
>> per-scenario and want to combine them in various ways. For example with
>> the data provided by point 1).
>>
>> For example if you want PCI-Express, you need the q35 machine type, but
>> you don't really want to care about the machine type. Or you want to
>> use SPICE, but you don't want to care about adding QXL.
>>
>> What if some of these policies could be specified once (using some DSL
>> for example), and used by virtuned to merge them in a unified and
>> predictable way?
>>
>> 3) Abstracting the XML
>>
>> This is probably just usable for stateless apps, but it might happen
>> that some apps don't really want to care about the XML at all. They
>> just want an abstract view of the domain, possibly add/remove a device
>> and that's it. We could do that as well. I can't really tell how much
>> of a demand there is for it, though.
>
>It is safe to say that applications do not want to touch XML at all.
>Any non-trivial application has created an abstraction around XML,
>so that they have an API to express what they want, rather than
>manipulating of strings to format/parse XML.
>
Sure, this was just meant to be a question as to whether it's worth
pursuing or not. You make a good point on why it is not (at least for
existing apps).
However, since this was optional, the way this would look without the
XML abstraction is that both input and output would be valid domain
definitions, ultimately resulting in something similar to virt-xml with
the added benefit of applying a policy from a file/string either
supplied by the application itself. Whether that policy was taken from
a common repository of such knowledge is orthogonal to this idea. Since
you would work with the same data, the upgrade could be incremental as
you'd only let virtuned fill in values for new options and could slowly
move on to using it for some pre-existing ones. None of the previous
approaches did this, if I'm not mistaken. Of course it gets more
difficult when you need to expose all the bits libvirt does and keep
them in sync (as you write below).
[...]
>If there was something higher level that gets more interesting,
>but the hard bit is that you still need a way to get at all the
>low level bits becuase a higher level abstracted API will never
>cover every niche use case.
>
Oh, definitely not every, but I see two groups of projects that have a
lot in common between themselves and between the groups as well. On the
other hand just templating and defaults is something that's easy enough
to do that it's not worth outsourcing that into another one's codebase.
>> 4) Identifying devices properly
>>
>> In contrast to the previous point, stateful apps might have a problem
>> identifying devices after hotplug. For example, let's say you don't
>> care about the addresses and leave that up to libvirt. You hotplug a
>> device into the domain and dump the new XML of it. Depending on what
>> type of device it was, you might need to identify it based on different
>> values. It could be <target dev=3D''/> for disks, <mac address=3D''/> f=
or
>> interfaces etc. For some devices it might not even be possible and you
>> need to remember the addresses of all the previous devices and then
>> parse them just to identify that one device and then throw them away.
>>
>> With new enough libvirt you could use the user aliases for that, but
>> turns out it's not that easy to use them properly anyway. Also the
>> aliases won't help users identify that device inside the guest.
>
>NB, relating between host device config and guest visible device
>config is a massive problem space in its own right, and not very
>easy to address. In OpenStack we ended up defining a concept of
>"device tagging" via cloud-init metadata, where openstack allows
>users to set opaque string tags against devices their VM has.
>OpenStack that generates a metadata file that records various
>pieces of identifying hardware attributes (PCI address, MAC
>addr, disk serial, etc) alongside the user tag. This metadata
>file is exposed to the guest with the hope that there's enough
>info to allow the user to decide which device is to be used for
>which purpose
>
This is good point, but I was mostly thinking about identifying devices
=66rom the host POV between two different XMLs (pre- and post- some
XML-modifying action, like hotplug).
>https://specs.openstack.org/openstack/nova-specs/specs/mitaka/approved/vir=
t-device-role-tagging.html
>https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/1=
0/html/networking_guide/use-tagging
>
>> <rant>
>> We really should've gone with new attribute for the user alias instead
>> of using an existing one, given how many problems that is causing.
>> </rant>
>>
>> 5) Generating the right XML snippet for device hot-(un)plug
>>
>> This is kind of related to some previous points.
>>
>> When hot-plugging a device and creating an XML snippet for it, you want
>> to keep the defaults from point 1) and policies from 2) in mind. Or
>> something related to the already existing domain which you can describe
>> systematically. And adding something for identification (see previous
>> point).
>>
>> Doing the hot-unplug is easy depending on how much information about
>> that device is saved by your application. The less you save about the
>> device (or show to the user in a GUI, if applicable) the harder it might
>> be to generate an XML that libvirt will accept. Again, some problems
>> with this should be fixed in libvirt, some of them are easy to
>> workaround. But having a common ground that takes care of this should
>> help some projects.
>>
>> Hot-unplug could be implemented just based on the alias. This is
>> something that would fit into libvirt as well.
>>
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>
>> To mention some pre-existing solutions:
>>
>> - I understand OpenStack has some really sensible and wisely chosen
>> and/or tested default values.
>
>In terms of default devices and OS specific choices, OpenStack's
>decisions have been largely inspired by previous work in oVirt
>and / or virt-manager. So there's obviously overlap in the
>conceptual area, but there's also plenty that is very specific
>to OpenStack - untangling the two extract the common bits from
>the app specific bits is hard.
>
It definitely is, but do you think it's so difficult it's worthless to
pursuit? I did a tiny PoC based on the code from virt-manager, which
was trivial mainly thanks to the XMLBuilder for the domain objects.
Maybe exposing an easy way to work with the XML would be enough for some
projects.
Little birdie from oVirt told me that they would like some of sort of
thing that does what you can achieve with virt-xml if we, for example,
made it work on pure XML definitions without connecting to libvirt.
>> - I know KubeVirt has VirtualMachinePresets. That is something closely
>> related to points 1) and 2). Also their abstraction of the XML might
>> be usable for point 3).
>>
>> - There was an effort on creating policy based configuration of libvirt
>> objects called libvirt-designer. This is closely related to points 2)
>> and 3). Unfortunately there was no much going on lately and part of
>> virt-manager repository has currently more features implemented with
>> the same ideas in mind, just not exported for public use.
>
>This is the same kind of problem we faced wrt libvirt-gconfig and
>libvirt-gobject usage from virt-manager - it has an extensive code
>base that already works, and rewriting it to use something new
>is alot of work for no short-term benefit. libvirt-gconfig/gobject
>were supposed to be the "easy" bits for virt-manager to adopt, as
>they don't really include much logic that would step on virt-manager's
>toes. libvirt-designer was going to be a very opinionated library
>and in retrospective that makes it even harder to consider adopting
>it for usage in virt-manager, as it'll have signficant liklihood
>of making functionally significant changes in behaviour.
>
The initial idea (which I forgot to mention) was that all the decisions
libvirt currently does (so that it keeps the guest ABI stable) would be
moved into data (let's say some DSL) and it could then be switched or
adjusted if that's not what the mgmt app wants (on a per-definition
basis, of course). I didn't feel very optimistic about the upstream
acceptance for that idea, so I figured that there could be something
that lives beside libvirt, helps with some policies if requested and
then the resulting XML could be fed into libvirt for determining the
rest.
>There's also the problem with use of native libraries that would
>impact many apps. We only got OpenStack to grudgingly allow the
By native you mean actual binary libraries or native to the OpenStack
code as in python module? Because what I had in mind for this project
was a python module with optional wrapper for REST API.
>use of libosinfo native library via GObject Introspection, by
>promising to do work to turn the osinfo database into an approved
>stable format which OpenStack could then consume directly, dropping
>the native API usage :-( Incidentally, the former was done (formal
>spec for the DB format), but the latter was not yet (direct DB usage
>by OpenStack)
>
>
>BTW, I don't like that I'm being so negative to your proposal :-(
>I used to hope that we would be able to build higher level APIs on
>top of libvirt to reduce the overlap between different applications
>reinventing the wheel. Even the simplest bits we tried like the
>gconfig/gobject API are barely used. libvirt-designer is basically
>a failure. Though admittedly it didn't have enough development resource
>applied to make it compelling, in retrospect adoption was always going
>to be a hard sell except in greenfield developments.
>
I'm glad for the knowledge you provided. So maybe instead of focusing
on de-duplication of existing codebases we could _at least_ aim at
future mgmt apps. OTOH improving documentation on how to properly build
higher level concepts on top of libvirt would benefit them as well.
>Libosinfo is probably the bit we've had most success with, and has
>most promise for the future, particularly now that we formally allow
>apps to read the osinfo database directly and bypass the API. It is
>quite easy to fit into existing application codebases which helps alot.
>Even there I'm still disappointed that we only have GNOME Boxes using
>the kickstart generator part of osinfo - oVirt and Oz both still have
>their own kickstart generator code for automating OS installs.
>
>In general though, I fear anything API based is going to be a really
>hard sell to get wide adoption for based on what we've seen before.
>
>I think the biggest bang-for-buck is identifying more areas where we
>can turn code into data. There's definitely scope for recording more
>types of information in the osinfo database. There might also be
>scope for defining entirely new databases to complement the osinfo
>data, if something looks out of scope for libosinfo.
>
>Regards,
>Daniel
>--=20
>|: https://berrange.com -o- https://www.flickr.com/photos/dberrang=
e :|
>|: https://libvirt.org -o- https://fstop138.berrange.co=
m :|
>|: https://entangle-photo.org -o- https://www.instagram.com/dberrang=
e :|
--ieNMXl1Fr3cevapt
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEiXAnXDYdKAaCyvS1CB/CnyQXht0FAlqzw4kACgkQCB/CnyQX
ht0G+xAAnvv+RKtfL7aDX7nVWclilDw7XYt+0a01KuLoF7a9FZ0emZgRr2tiX8NO
iTU1t68Ch62vni+FY77cuPM7eixUdYEwUaVybptJvWKzAgladXpA93ZfsT0wGxpi
qIrkpgbJmiAULogBrc8ia2bqy2MpFDIFAPzsMDTsznJH/cJMErA+Hg5A8VVOt0Cl
j6uwGCT7MYRBK2/th3Q0POVLtnj6MnXbuTda3sl45aNMnOEDmxKNW+zNdgUfbAxO
0GdjfypwJyFIz4FZRrVvlnMEHlqkZyJcDF6BQN+lVKsTizcDAYV6QM3snNLTFgsF
huIcrMsWNnDG/GsbkFyc6XkvPeZ6xonMW0LEYHP6pLTyg1CGIJ7E6VaPNlEVRU+J
aJjqHEW14oTc6ttuf8m7El972ATXgY6l1W4FiQisIy7PpwpGb896zoaEyYryGJT4
WWXFW60QoDPNmjHgA4S0PdefEuKrD1u5BUYVExpVW7ud8uyggssKz6id7mv+4J6Y
Jv0WaaIA/l53mInyEzOpTHT6tMExH64tHF2RdghQ+r7tzNxtCmBDmj3QcwHzaa97
+R0txkevMqJ57l2QvWKc2z7CJHsuZqolDrGpMUJ35PFOqAeq2elj9F4fmUlV+nt5
Ju4qL3mrJ4AdhtXBACcQLNqUsbgGs1E99gY2v9mpJOPvSyVD5O0=
=L9yQ
-----END PGP SIGNATURE-----
--ieNMXl1Fr3cevapt--
6 years
oVirt log analyzer
by Milan Zamazal
Hi, during last year Outreachy internship a tool for analyzing oVirt
logs was created. When it is provided with oVirt logs (such as SOS
reports, logs gathered by Lago, single or multiple log files) it tries
to identify and classify important lines from the logs and present them
in a structured form. Its primary purpose is to get a quick and easy
overview of actions and errors.
The tool analyses given logs and produces text files with the extracted
information. There is an Emacs user interface that presents the output
in a nice way with added functionality such as filtering. Emacs haters
can use the plain text files or write another user interface. :-)
You can get ovirt-log-analyzer from
https://github.com/mz-pdm/ovirt-log-analyzer
README.md explains how to use it.
Note that ovirt-log-analyzer has been created within the limited
resources of an Outreachy internship with some additional work and not
everything is perfect. Feel free to make improvements.
Regards,
Milan
6 years
Failed To Build ovirt-node following the guide
by sundw
This is a multi-part message in MIME format.
------=_001_NextPart058565458615_=----
Content-Type: text/plain;
charset="GB2312"
Content-Transfer-Encoding: base64
SGVsbG8sZ3V5c6OhDQoNCkkgYnVpbHQgb3ZpcnQtbm9kZSBmb2xsb3dpbmcgdGhpcyBndWlkZSho
dHRwczovL3d3dy5vdmlydC5vcmcvZGV2ZWxvcC9wcm9qZWN0cy9ub2RlL2J1aWxkaW5nLykuDQpC
dXQgSSBmYWlsZWQuDQpJIGdvdCB0aGUgZm9sbG93aW5nIEVycm9yIG1lc3NhZ2UgYWZ0ZXIgcnVu
bmluZyAibWFrZSBpc28gcHVibGlzaCI6DQoNCkVycm9yIGNyZWF0aW5nIExpdmUgQ0QgOiBGYWls
ZWQgdG8gZmluZCBwYWNrYWdlICdvdmlydC1ub2RlLXBsdWdpbi12ZHNtJyA6IE5vIHBhY2thZ2Uo
cykgYXZhaWxhYmxlIHRvIGluc3RhbGwNCg0KQ291bGQgeW91IHBsZWFzZSBnaXZlIHNvbWUgYWR2
aWNlPw0KDQpCVFc6IElzIHRoZSBjb250ZW50IG9mIHRoaXMgdXJsICJodHRwczovL3d3dy5vdmly
dC5vcmcvZGV2ZWxvcC9wcm9qZWN0cy9ub2RlL2J1aWxkaW5nLyIgT1VUIE9GIERBVEU/DQoNCg0K
DQrL77TzzqENCrGxvqm/xtL4vqmzyby8yvXT0M/euavLvi/QwrL6xrfR0Leisr8NCjEzMzc4MTA1
NjI1DQo=
------=_001_NextPart058565458615_=----
Content-Type: text/html;
charset="GB2312"
Content-Transfer-Encoding: quoted-printable
<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charse=
t=3DGB2312"><style>body { line-height: 1.5; }body { font-size: 10.5pt; fon=
t-family: =CE=A2=C8=ED=D1=C5=BA=DA; color: rgb(0, 0, 0); line-height: 1.5;=
}</style></head><body>=0A<div><span></span><span style=3D"color: rgb(0, 0=
, 0); background-color: rgba(0, 0, 0, 0);">Hello,guys=A3=A1</span></div><d=
iv><span style=3D"color: rgb(0, 0, 0); background-color: rgba(0, 0, 0, 0);=
"><br>I built ovirt-node following this guide(htt=
ps://www.ovirt.org/develop/projects/node/building/).<br>But I fa=
iled.<br>I got the following Error message after =
running "make iso publish":<br><br>Error creating =
;Live CD : Failed to find package 'ovir=
t-node-plugin-vdsm' : No package(s) available to&=
nbsp;install<br><br>Could you please give some ad=
vice?</span></div><div><span style=3D"color: rgb(0, 0, 0); background-colo=
r: rgba(0, 0, 0, 0);"><br></span></div><div><b><span style=3D"color: rgb(0=
, 0, 0); background-color: rgba(0, 0, 0, 0);">BTW: Is the content of this =
url "</span><span style=3D"font-size: 10.5pt; line-height: 1.5; background=
-color: window;">https://www.ovirt.org/develop/projects/node/building/</sp=
an><span style=3D"background-color: rgba(0, 0, 0, 0); font-size: 10.5pt; l=
ine-height: 1.5;">" OUT OF DATE?</span></b></div><div><br></div><hr style=
=3D"width: 210px; height: 1px;" color=3D"#b5c4df" size=3D"1" align=3D"left=
">=0A<div><span><div style=3D"margin: 10px; font-size: 21px;"><b><font fac=
e=3D"=BB=AA=CE=C4=D0=C2=CE=BA">=CB=EF=B4=F3=CE=A1</font></b></div><div sty=
le=3D"MARGIN: 10px; FONT-FAMILY: verdana; FONT-SIZE: 10pt">=B1=B1=BE=A9=BF=
=C6=D2=F8=BE=A9=B3=C9=BC=BC=CA=F5=D3=D0=CF=DE=B9=AB=CB=BE/=D0=C2=B2=FA=C6=
=B7=D1=D0=B7=A2=B2=BF</div><div style=3D"MARGIN: 10px; FONT-FAMILY: verdan=
a; FONT-SIZE: 10pt">13378105625</div></span></div>=0A</body></html>
------=_001_NextPart058565458615_=------
6 years
Build virt-node on fedora26 failed
by sundw
This is a multi-part message in MIME format.
------=_001_NextPart018013562620_=----
Content-Type: text/plain;
charset="GB2312"
Content-Transfer-Encoding: base64
SGkhDQpJIGJ1aWxkIHZpcnQtbm9kZSBiYXNlIG9uIHRoaXMgZ3VpZGUoaHR0cHM6Ly93d3cub3Zp
cnQub3JnL2RldmVsb3AvcHJvamVjdHMvbm9kZS9idWlsZGluZy8pLg0KSSBnb3QgdGhlIGZvbGxv
d2luZyBlcnJvciBtZXNzYWdlcyBhZnRlciBJIHJ1biAibWFrZSBwdWJsaXNoIjoNCg0KSW5zdGFs
bGluZyB0bXAucmVwb3MvU1JQTVMvb3ZpcnQtbm9kZS0zLjcuMC0wLjAubWFzdGVyLmZjMjcuc3Jj
LnJwbQ0KZXJyb3I6IEZhaWxlZCBidWlsZCBkZXBlbmRlbmNpZXM6DQovdXNyL3NoYXJlL3NlbGlu
dXgvZGV2ZWwvcG9saWN5aGVscCBpcyBuZWVkZWQgYnkgb3ZpcnQtbm9kZS0zLjcuMC0wLjAubWFz
dGVyLmZjMjcubm9hcmNoDQptYWtlWzFdOiAqKiogW01ha2VmaWxlOjgxMzogcnBtXSBFcnJvciAx
DQptYWtlWzFdOiBMZWF2aW5nIGRpcmVjdG9yeSAnL2hvbWUvY29yZXRlay9naXQvb3ZpcnQtbm9k
ZScNCm1ha2U6ICoqKiBbTWFrZWZpbGU6ODI3OiBwdWJsaXNoXSBFcnJvciAyDQoNCkNhbiBhbnlv
bmUgZ2l2ZSBtZSBzb21lIHN1Z2dlc3Rpb25zPyANClRoYW5rcyENCg0KDQoNCg0Ky++0886hDQqx
sb6pv8bS+L6ps8m8vMr109DP3rmry74v0MKy+sa30dC3orK/DQoxMzM3ODEwNTYyNQ0K
------=_001_NextPart018013562620_=----
Content-Type: text/html;
charset="GB2312"
Content-Transfer-Encoding: quoted-printable
<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charse=
t=3DGB2312"><style>body { line-height: 1.5; }body { font-size: 10.5pt; fon=
t-family: =CE=A2=C8=ED=D1=C5=BA=DA; color: rgb(0, 0, 0); line-height: 1.5;=
}</style></head><body>=0A<div><span></span>Hi!</div><div>I build virt-nod=
e base on this guide(<span style=3D"background-color: rgba(0, 0, 0, 0); fo=
nt-size: 10.5pt; line-height: 1.5;">https://www.ovirt.org/develop/projects=
/node/building/</span><span style=3D"font-size: 10.5pt; line-height: 1.5; =
background-color: window;">).</span></div><div>I got the following error m=
essages after I run "make publish":</div><div><br></div><div><span style=
=3D"color: rgb(0, 0, 0); background-color: rgba(0, 0, 0, 0);">Installing&n=
bsp;tmp.repos/SRPMS/ovirt-node-3.7.0-0.0.master.fc27.src.rpm<br>error:&nbs=
p;Failed build dependencies:<br><span style=3D"white-space: pre;=
"> </span>/usr/share/selinux/devel/policyhelp is needed by&=
nbsp;ovirt-node-3.7.0-0.0.master.fc27.noarch<br>make[1]: *** [Ma=
kefile:813: rpm] Error 1<br>make[1]: Leaving dire=
ctory '/home/coretek/git/ovirt-node'<br>make: *** [Makefile=
:827: publish] Error 2</span></div><div><span style=3D"colo=
r: rgb(0, 0, 0); background-color: rgba(0, 0, 0, 0);"><br></span></div><di=
v><span style=3D"color: rgb(0, 0, 0); background-color: rgba(0, 0, 0, 0);"=
>Can anyone give me some suggestions? </span></div><div><span style=
=3D"color: rgb(0, 0, 0); background-color: rgba(0, 0, 0, 0);">Thanks!</spa=
n></div><div><br></div>=0A<div><br></div><hr style=3D"width: 210px; height=
: 1px;" color=3D"#b5c4df" size=3D"1" align=3D"left">=0A<div><span><div sty=
le=3D"margin: 10px; font-size: 21px;"><b><font face=3D"=BB=AA=CE=C4=D0=C2=
=CE=BA">=CB=EF=B4=F3=CE=A1</font></b></div><div style=3D"MARGIN: 10px; FON=
T-FAMILY: verdana; FONT-SIZE: 10pt">=B1=B1=BE=A9=BF=C6=D2=F8=BE=A9=B3=C9=
=BC=BC=CA=F5=D3=D0=CF=DE=B9=AB=CB=BE/=D0=C2=B2=FA=C6=B7=D1=D0=B7=A2=B2=BF<=
/div><div style=3D"MARGIN: 10px; FONT-FAMILY: verdana; FONT-SIZE: 10pt">13=
378105625</div></span></div>=0A</body></html>
------=_001_NextPart018013562620_=------
6 years
[ OST Failure Report ] [ oVirt Master (ovirt-engine) ] [ 27-03-2018 ] [ 004_basic_sanity.disk_operations ]
by Dafna Ron
Hi,
We have a failure on 004_basic_sanity.disk_operations. the reported change
seems to me to be connected to the failure.
*Link and headline of suspected patches: core: introduce
CreateSnapshotForVm - https://gerrit.ovirt.org/#/c/87671/
<https://gerrit.ovirt.org/#/c/87671/>Link to
Job:http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/6564/
<http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/6564/>Link
to all
logs:http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/6564/a...
<http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/6564/artifa...>(Relevant)
error snippet from the log: <error>2018-03-27 11:30:16,167-04 WARN
[org.ovirt.engine.core.bll.snapshots.CreateSnapshotForVmCommand] (default
task-11) [9f713a3d-82a9-4db8-8207-bb69a0a2c550] Validation of action
'CreateSnapshotForVm' failed for user admin@internal-authz. Reasons:
VAR__ACTION__CREATE,VAR__TYPE__SNAPSHOT,ACTION_TYPE_FAILED_SNAPSHOT_IS_BEING_TAKEN_FOR_VM,$VmName
vm12018-03-27 11:30:16,176-04 DEBUG
[org.ovirt.engine.core.common.di.interceptor.DebugLoggingInterceptor]
(default task-11) [9f713a3d-82a9-4db8-8207-bb69a0a2c550] method: runAction,
params: [CreateSnapshotForVm,
CreateSnapshotForVmParameters:{commandId='d8bfdb0e-5ae4-4fed-8852-a0b29e377708',
user='null', commandType='Unknown',
vmId='65e7fea5-8b7d-4281-bd0d-6a84de207a00'}], timeElapsed: 57ms2018-03-27
11:30:16,186-04 ERROR
[org.ovirt.engine.api.restapi.resource.AbstractBackendResource] (default
task-11) [] Operation Failed: [Cannot create Snapshot. Snapshot is
currently being created for VM vm1.]2018-03-27 11:30:16,820-04 INFO
[org.ovirt.engine.core.bll.SerialChildCommandsExecutionCallback]
(EE-ManagedThreadFactory-engineScheduled-Thread-100)
[16c08ce6-9a73-489f-a1f2-56e21699f14a] Command 'CopyImageGroupVolumesData'
(id: '4c4023b4-21e8-4a98-8ac3-aba51967d160') waiting on child command id:
'3d96b933-6e3b-4838-94bc-db3ff0cadcdc' type:'CopyData' to
complete2018-03-27 11:30:16,833-04 DEBUG
[org.ovirt.engine.core.common.di.interceptor.DebugLoggingInterceptor]
(EE-ManagedThreadFactory-engineScheduled-Thread-100)
[16c08ce6-9a73-489f-a1f2-56e21699f14a] method: get, params:
[a85992e9-40b8-4c80-9c93-3bf767f6efa4], timeElapsed: 8ms</error>*
6 years
[VDSM] Network test failing randomly - needs un-ordered compare?
by Nir Soffer
We have this failure in unrelated patch:
http://jenkins.ovirt.org/job/vdsm_master_check-patch-el7-x86_64/22723/con...
The issue seems to comparing strings instead of sets.
The next run was successful. I did not check if it run on the same slave.
http://jenkins.ovirt.org/job/vdsm_master_check-patch-el7-x86_64/22724/
*00:08:51.242* =================================== FAILURES
===================================
*00:08:51.243* ________________
LinkBondTests.test_bond_set_two_arp_ip_targets
________________*00:08:51.243* *00:08:51.243* self =
<network.integration.link_bond_test.LinkBondTests
testMethod=test_bond_set_two_arp_ip_targets>*00:08:51.244*
*00:08:51.244* def
test_bond_set_two_arp_ip_targets(self):*00:08:51.244* OPTIONS
= {*00:08:51.244* 'mode': '1',*00:08:51.245*
'arp_interval': '1000',*00:08:51.245* 'arp_ip_target':
'10.1.3.1,10.1.2.1'}*00:08:51.245* *00:08:51.245* with
bond_device() as bond:*00:08:51.245*
bond.set_options(OPTIONS)*00:08:51.246*
bond.refresh()*00:08:51.246* >
self.assertEqual(bond.options, OPTIONS)*00:08:51.246* E
AssertionError: {'mode': '1', 'arp_interval': '1000', 'arp_ip_target':
'10.1.2.1,10.1.3.1'} != {'mode': '1', 'arp_interval': '1000',
'arp_ip_target': '10.1.3.1,10.1.2.1'}*00:08:51.248* E -
{'arp_interval': '1000', 'arp_ip_target': '10.1.2.1,10.1.3.1', 'mode':
'1'}*00:08:51.248* E ?
---------*00:08:51.249* E *00:08:51.249* E
+ {'arp_interval': '1000', 'arp_ip_target': '10.1.3.1,10.1.2.1',
'mode': '1'}*00:08:51.249* E ?
+++++++++*00:08:51.250* *00:08:51.250*
network/integration/link_bond_test.py:159:
AssertionError*00:08:51.250* ------------------------------ Captured
log call -------------------------------*00:08:51.251* sysfs_driver.py
57 INFO Bond bond_ge9DfJ has been
created.*00:08:51.251* cmdutils.py 150 DEBUG
/sbin/ip link set dev bond_ge9DfJ down (cwd None)*00:08:51.252*
cmdutils.py 158 DEBUG SUCCESS: <err> = ''; <rc> =
0*00:08:51.252* sysfs_driver.py 102 INFO Bond
bond_ge9DfJ options set: {'mode': '1', 'arp_interval': '1000',
'arp_ip_target': '10.1.3.1,10.1.2.1'}.*00:08:51.253* sysfs_driver.py
67 INFO Bond bond_ge9DfJ has been
destroyed.*00:08:51.254* =============== 1 failed, 36 passed, 12
skipped in 10.57 seconds ===============
6 years
new time-based test randomly failing
by Dan Kenigsberg
I suppose this test should be reworked, or at least, have its constants tweaked.
FAIL: test_slow_handler_sync (common.logutils_test.TestThreadedHandler)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/home/jenkins/workspace/vdsm_master_check-patch-fc27-x86_64/vdsm/tests/common/logutils_test.py",
line 319, in test_slow_handler_sync
self.assertGreater(max(workers_time), 0.9)
AssertionError: 0.8714249134063721 not greater than 0.9
6 years
OST Failure - Weekly update [24/03/2018-29/03/2018]
by Dafna Ron
Hello,
I would like to update on this week's failures and OST current status.
This week I am sending the report a bit earlier due to the holidays.
We had a few failures this week but I am glad to report that the issues
were fixed quickly.
on 23-03-2018 we started getting a random failure which seems to be an
issue with the ost test hotplug_cpu
This fix was submitted by Milan to fix the issue:
https://gerrit.ovirt.org/89589
On the 27-03-2018 we had a failure on basic_sanity.disk_operations
This seems to be related to locking race and was fixed by Benny on 3
different fixes:
https://gerrit.ovirt.org/#/c/89534/
https://gerrit.ovirt.org/#/c/89537/
https://gerrit.ovirt.org/#/c/89577/
There was an issue with build-artifacts on the vdsm project which was an
infra failure as well as a code issue (2 different builds). this was also
resolved quickly.
Infra issues:
The ci team discovered and fixed a failure in container cleanup on the the
hosts. Daniel submitted this patch: https://gerrit.ovirt.org/#/c/89402/ and
it seemed to have resolved the issue.
Gal has been investigating an issue which causes failure due to lack of
memory on the host. for now, Gal submitted a fix:
https://gerrit.ovirt.org/#/c/89588/
Lastly we had a packaging issue on 4.2 which was resolved as well.
*Below you can see the chart for this week's resolved issues but cause of
failure:Code* = regression of working components/functionalities
*Infra* = infrastructure/OST Infrastructure/Lago related issues/Power
outages
*OST* Tests - package related issues, failed build artifacts
*Below is a chart of resolved failures based on ovirt version*
*Below is a chart showing failures by suite type: *
*Thanks, *
*Dafna*
6 years
