Alternatives to automatically move bugs to MODIFIED
by Yedidyah Bar David
Hi all,
We currently have a bot that automatically moves bugs from POST to MODIFIED
if all linked patches on gerrit are merged.
It happened to me personally several times that this was a wrong thing to do,
either because a new patch was still needed but not pushed yet, or because
an existing patch should have been back-ported to another branch and wasn't
yet. Since I usually pay more attention to my bug in POST, I sometimes missed
this and handled the missing patches (backports, usually) later than I could
if left on POST.
I have a feeling I am not the only one. So I suggest to stop doing this.
I can think of several alternatives:
1. Do nothing. I think that's reasonable - I think most people pay more
attention to POST bugs anyway.
2. Set needinfo on bug owner.
3. Send some alert email to relevant people (bug owner, existing patches owners,
perhaps others - e.g. reviewers of existing patches, perhaps those
that actually reviewed, etc.). Need to think how to make it not too
annoying for others but
still effective also if owner is on long PTO or something like that. New flag
doesn't have to be very specific - can be called something like 'attention
needed' or something like that.
4. Add a new flag for that and set it. This will allow easier
filtering/reporting.
What do you think?
--
Didi
7 years, 7 months
possible bug in libgovirt or oVirt 4.0.2
by i iordanov
Hello,
I just tested oVirt 4.0.2 with Opaque, and when I try to make the
following call:
ovirt_vm_start(vm, proxy, &error);
I get an error->message: "Could not find 'state' node".
Further on, when I attempt to make a call to:
ovirt_vm_get_ticket(vm, proxy, &error)
I get the same error message "Could not find 'state' node".
Indeed, on oVirt 4.0.2, when I browse to:
https://livecd.localdomain/ovirt-engine/api/vms/VM_ID_HERE
I see no "state" node, only "<status>up</status>"
On the other hand, when I browse to the same part of the API on oVirt
3.4, I see:
"<status><state>up</state></status>"
Seems to me the API changed but the libgovirt, the client C library did not.
I hope you can correct this soon, and thanks in advance!
Cheers,
iordan
--
The conscious mind has only one thread of execution.
7 years, 7 months
[ANN] oVirt 4.0.4 First Release Candidate is now available
by Sandro Bonazzola
The oVirt Project is pleased to announce the availability of the First
Release Candidate of oVirt 4.0.4 for testing, as of August 31st, 2016.
This release is available now for:
* Fedora 23 (tech preview)
* Red Hat Enterprise Linux 7.2 or later
* CentOS Linux (or similar) 7.2 or later
This release supports Hypervisor Hosts running:
* Red Hat Enterprise Linux 7.2 or later
* CentOS Linux (or similar) 7.2 or later
* Fedora 23 (tech preview)
* oVirt Next Generation Node 4.0
This is pre-release software. Please take a look at our community page[1]
to know how to ask questions and interact with developers and users.
All issues or bugs should be reported via oVirt Bugzilla[2].
This pre-release should not to be used in production.
This update is the first release candidate of the fourth in a series of
stabilization updates to the 4.0 series.
4.0.4 brings 7 enhancements and 93 bugfixes, including 33 high
or urgent severity fixes, on top of oVirt 4.0 series
See the release notes [3] for installation / upgrade instructions and a
list of new features and bugs fixed.
Notes:
* A new oVirt Live ISO is available. [4]
* A new oVirt Next Generation Node is available [4].
* A new oVirt Engine Appliance is available for Red Hat Enterprise Linux
and CentOS Linux (or similar)
* Mirrors[5] might need up to one day to synchronize.
Additional Resources:
* Read more about the oVirt 4.0.4 release highlights:
http://www.ovirt.org/release/4.0.4/
* Get more oVirt Project updates on Twitter: https://twitter.com/ovirt
* Check out the latest project news on the oVirt blog:
http://www.ovirt.org/blog/
[1] https://www.ovirt.org/community/
[2] https://bugzilla.redhat.com/enter_bug.cgi?classification=oVirt
[3] http://www.ovirt.org/release/4.0.4/
[4] http://resources.ovirt.org/pub/ovirt-4.0-pre/iso/
[5] http://www.ovirt.org/Repository_mirrors#Current_mirrors
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
7 years, 7 months
oVirt Engine 4.0.4 branched
by Tal Nisan
Hi everyone,
We've created ovirt-engine-4.0.4 branch this morning from the 4.0.3 branch.
>From now on 4.0.4 Engine patches will have to be backported to the new
branch after being backported to the ovirt-engine-4.0 branch.
Engine 4.0.5 patches can now be backported to ovirt-engine-4.0 branch.
Tal.
7 years, 7 months
repos down
by Gary Pedretty
--Apple-Mail=_A85252B1-0D2F-4BC6-948C-BDA2E4E5E66B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=utf-8
I am unable to do any installs, yum cannot access the mirrors list
=E2=80=9CCould not retrieve mirrorlist =
http://resources.ovirt.org/pub/yum-repo/mirrorlist-ovirt-4.0-el7=E2=80=9D =
error was
12: Timeout on =
http://resources.ovirt.org/pub/yum-repo/mirrorlist-ovirt-4.0-el7: (28, =
=E2=80=98Connection timed out after 30001 milliseconds=E2=80=99)"
Tried from various locations on different ISPs.
Gary
------------------------------------------------------------------------
Gary Pedretty gary(a)ravnalaska.net =
<mailto:gary@eraalaska.net>
Systems Manager www.flyravn.com =
<http://www.flyravn.com/>
Ravn Alaska /\ 907-450-7251
5245 Airport Industrial Road / \/\ 907-450-7238 fax
Fairbanks, Alaska 99709 /\ / \ \ Second greatest commandment
Serving All of Alaska / \/ /\ \ \/\ =E2=80=9CLove your =
neighbor as
Really loving the record green up date! Summmer!! yourself=E2=80=9D =
Matt 22:39
------------------------------------------------------------------------
--Apple-Mail=_A85252B1-0D2F-4BC6-948C-BDA2E4E5E66B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=utf-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D"">I am unable to do any installs, yum cannot access the mirrors =
list<div class=3D""><br class=3D""></div><div class=3D"">=E2=80=9CCould =
not retrieve mirrorlist <a =
href=3D"http://resources.ovirt.org/pub/yum-repo/mirrorlist-ovirt-4.0-el7" =
class=3D"">http://resources.ovirt.org/pub/yum-repo/mirrorlist-ovirt-4.0-el=
7</a>=E2=80=9D error was</div><div class=3D"">12: Timeout on <a =
href=3D"http://resources.ovirt.org/pub/yum-repo/mirrorlist-ovirt-4.0-el7:"=
=
class=3D"">http://resources.ovirt.org/pub/yum-repo/mirrorlist-ovirt-4.0-el=
7:</a> (28, =E2=80=98Connection timed out after 30001 =
milliseconds=E2=80=99)"</div><div class=3D""><br class=3D""></div><div =
class=3D"">Tried from various locations on different ISPs.</div><div =
class=3D""><br class=3D""></div><div class=3D"">Gary</div><div =
class=3D""><br class=3D""><div class=3D"">
<div style=3D"color: rgb(0, 0, 0); letter-spacing: normal; orphans: =
auto; text-align: start; text-indent: 0px; text-transform: none; =
white-space: normal; widows: auto; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D""><div style=3D"color: rgb(0, 0, 0); letter-spacing: normal; =
orphans: auto; text-align: start; text-indent: 0px; text-transform: =
none; white-space: normal; widows: auto; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D""><div style=3D"orphans: auto; text-align: start; text-indent: =
0px; widows: auto; word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space;" class=3D""><div style=3D"orphans: =
auto; text-align: start; text-indent: 0px; widows: auto; word-wrap: =
break-word; -webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space;" class=3D""><div style=3D"orphans: auto; text-align: =
start; text-indent: 0px; widows: auto; word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D""><div style=3D"orphans: auto; text-align: start; text-indent: =
0px; widows: auto; word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space;" class=3D""><div style=3D"orphans: =
auto; text-align: start; text-indent: 0px; widows: auto; word-wrap: =
break-word; -webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space;" class=3D""><div style=3D"orphans: auto; text-align: =
start; text-indent: 0px; widows: auto; word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D""><div style=3D"orphans: auto; text-align: start; text-indent: =
0px; widows: auto; word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space;" class=3D""><font face=3D"Menlo" =
style=3D"color: rgb(0, 0, 0); font-size: 12px; letter-spacing: normal; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px;" class=3D""><div =
class=3D"">---------------------------------------------------------------=
---------</div><div class=3D"">Gary Pedretty =
=
<a =
href=3D"mailto:gary@eraalaska.net" =
class=3D"">gary(a)ravnalaska.net</a></div><div class=3D"">Systems Manager =
=
=
<a href=3D"http://www.flyravn.com" =
class=3D"">www.flyravn.com</a></div><div class=3D"">Ravn Alaska =
=
/\ =
907-450-7251</div><div class=3D"">5245 Airport Industrial =
Road / \/\ =
907-450-7238 fax</div><div class=3D"">Fairbanks, Alaska =
99709 /\ / \ \ =
Second greatest commandment</div></font><font face=3D"Monaco" =
class=3D""><span style=3D"font-size: 12px;" class=3D"">Serving All of =
Alaska / \/ /\ \ \/\ =
=E2=80=9CLove your neighbor as</span></font><br =
style=3D"font-family: Monaco;" class=3D""><font face=3D"Menlo" =
style=3D"color: rgb(0, 0, 0); letter-spacing: normal; text-transform: =
none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: =
0px;" class=3D""><span style=3D"font-size: 12px;" class=3D"">Really =
loving the record green up date! Summmer!! yourself=E2=80=9D M=
att 22:39</span></font><div style=3D"color: rgb(0, 0, 0); =
letter-spacing: normal; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px; font-family: Menlo;" =
class=3D""></div><font face=3D"Menlo" style=3D"font-size: 12px;" =
class=3D""></font><span style=3D"color: rgb(0, 0, 0); letter-spacing: =
normal; text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; font-size: 12px;" class=3D""><font =
face=3D"Menlo" class=3D""><div =
class=3D"">---------------------------------------------------------------=
---------</div></font></span><div style=3D"color: rgb(0, 0, 0); =
letter-spacing: normal; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""><font =
face=3D"Menlo" style=3D"font-size: 12px;" class=3D""><br =
class=3D""></font></div></div><span style=3D"color: rgb(0, 0, 0); =
letter-spacing: normal; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px; font-size: 12px;" =
class=3D""><br class=3D"Apple-interchange-newline"></span></div><span =
style=3D"color: rgb(0, 0, 0); letter-spacing: normal; text-transform: =
none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: =
0px; font-size: 12px;" class=3D""><br =
class=3D"Apple-interchange-newline"></span></div><span style=3D"color: =
rgb(0, 0, 0); letter-spacing: normal; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; font-size: =
12px;" class=3D""><br class=3D"Apple-interchange-newline"></span></div><br=
class=3D"Apple-interchange-newline"></div><br =
class=3D"Apple-interchange-newline"></div><br =
class=3D"Apple-interchange-newline"></div><br =
class=3D"Apple-interchange-newline"></div><br =
class=3D"Apple-interchange-newline"></div><br =
class=3D"Apple-interchange-newline"><br =
class=3D"Apple-interchange-newline">
</div>
<br class=3D""></div></body></html>=
--Apple-Mail=_A85252B1-0D2F-4BC6-948C-BDA2E4E5E66B--
7 years, 7 months
broken master: removal of release in spec requirements
by Yaniv Bronheim
Hi,
In https://gerrit.ovirt.org/#/c/62672 we removed the release from vdsm*
requirements. Although it sounds reasonable and quite safe, it was not.
In development env it causes mixup of versions when upgrading.
"yum install vdsm" will eventually cause this mixup as vdsm won't require
the newer vdsm-python
I think this change should be reverted and the solution should be in the
build process. Newer release is equal to higher version, requirement should
include the release number.
so for example, 4.18.7-1 was shipped and for ppc we built 4.18.7-2 so
4.18.7-2 is newer. can't see how this can be different.
e.g for the bug:
===================================================================================================================================================================================================================
Package Arch
Version
Repository Size
===================================================================================================================================================================================================================
Removing:
vdsm x86_64
4.18.999-457.gitcde215c.el7.centos
@ovirt-master-snapshot 2.7 M
vdsm-api noarch
4.18.999-342.git40c3bbb.el7.centos
@ovirt-master-snapshot 325 k
vdsm-cli noarch
4.18.999-457.gitcde215c.el7.centos
@ovirt-master-snapshot 342 k
vdsm-hook-vmfex-dev noarch
4.18.999-457.gitcde215c.el7.centos
@ovirt-master-snapshot 21 k
vdsm-jsonrpc noarch
4.18.999-342.git40c3bbb.el7.centos
@ovirt-master-snapshot 81 k
vdsm-python noarch
4.18.999-342.git40c3bbb.el7.centos
@ovirt-master-snapshot 2.4 M
vdsm-xmlrpc noarch
4.18.999-342.git40c3bbb.el7.centos
@ovirt-master-snapshot 109 k
vdsm-yajsonrpc noarch
4.18.999-342.git40c3bbb.el7.centos
@ovirt-master-snapshot 95 k
Problem.
--
*Yaniv Bronhaim.*
7 years, 7 months
Re: [ovirt-devel] [libvirt] RFC: Limited dynamic ownership
by Martin Kletzander
--R3G7APHDIzY6R/pk
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
On Tue, Aug 23, 2016 at 07:25:56PM -0400, Daniel P. Berrange wrote:
>On Tue, Aug 23, 2016 at 06:17:44PM -0400, Martin Kletzander wrote:
>> On Tue, Aug 23, 2016 at 05:54:29PM -0400, Daniel P. Berrange wrote:
>> > On Tue, Aug 23, 2016 at 05:06:20PM -0400, Martin Kletzander wrote:
>> > > Hi everyone,
>> > >
>> > > so there was an idea about limiting the relabelling of images that
>> > > libvirt does. And I'm taking the liberty of pitching my idea how to
>> > > approach this. I feel like it's pretty simple thing and there's not
>> > > much to talk about, but a) I could've missed something and b) you might
>> > > hate the way I approach it.
>> > >
>> > > The idea is to extend the seclabel XML, for example:
>> > >
>> > > <seclabel type='dynamic' model='dac' relabel='whitelist'>
>> > > <path>/var/lib/libvirt/images</path>
>> > > <path>/data/virt-stuff</path>
>> > > </seclabel>
>> > >
>> > > Either we allow 'relabel' to be set to 'whitelist' or add a new
>> > > attribute with a name like 'mode' or something, which will control how
>> > > we relabel the files (actually relabel='no' can mean 'whitelist' and
>> > > relabel='yes' can mean blacklist without adding anything there). After
>> > > that you can specify what paths are (dis)allowed to be labelled.
>> > >
>> > > Actually thinking about it I like the following the most:
>> > >
>> > > <seclabel type='dynamic' model='dac' relabel='no'>
>> > > <whitelist path='/data'/>
>> > > <blacklist path='/data/private/non-virt/stuff'/>
>> > > </seclabel>
>> > >
>> > > which I believe is pretty explanatory. Feel free to ask if it's not.
>> > > And let me know what you think.
>> >
>> > I don't think we need to get involved in the <seclabel> configuration.
>> >
>>
>> I forgot to mention that I like that because you would be able to
>> specify this per-disk as well as for the whole VM.
>
>Of course using info in <disk> directly achieves the same thing
>
>> > We've already got the ability in the <disk> config to provide the
>> > full backing chain explicitly. If a management app provides a full
>> > backing chain in the XML, we could validate the app provided chain
>> > against the chain we probe and report error if they mis-match. (Maybe
>> > we in fact already report this?)
>> >
>>
>> Not yet:
>>
>> "It is currently ignored on input and only used for output to describe
>> the detected backing chains of running domains."
>>
>> It would help with this, but I don't feel like it's that usable. Also
>> I feel like everyone will overuse that while misunderstanding what it
>> actually does. Also if you do some block-merge or whatever, you need to
>> update the backing chain and everyone will just re-probe it because no
>> management layer likes keeping more information than needed.
>
>If you provide the <seclabel> whitelist though, you're essentially
>going to want to provide the same info that you would provide with
>the <backing> data, as the whitelist you're providing there is
>essentially trying to whitelist only the expected backing file.
>
>I don't feel like we should be inventing new seclabel elements to
>duplicate info we could already provide via existing backing data
>elements.
>
It just introduces more complexity that might result in more bugs, but
yes, it is information duplication.
>> > Thinking bout this in the context of a recent OpenStack Nova CVE,
>> > where Nova mistakenly set format=qcow2, instead of format=raw, allowing
>> > a malicious guest to write a qcow2 header with backing file. If Nova
>> > had provided the full backing chain it expected (no backing chain at
>> > all), then libvirt would have seen the maliciously created backing
>> > chain, and caught the problem despite Nova giving the wrong format.
>> >
>> >
>> > Separately from this, in the context of storage pools, when giving
>> > a <disk type=pool> in the domain XML, we could do validation to
>> > ensure the backing file of the volume always pointed to a volume
>> > that was also inside a storage pool. This would allow us to have
>> > backing files pointing to volumes in different storage pools, but
>> > would prevent them pointing to arbitrary files that were not in
>> > storage pools at all (eg /etc/password, or /dev/root, etc).
>> >
>>
>> That is good idea, but it won't cover all the cases, for example if
>> you're not using storage pools.
>
>Yep, at least from OpenStack POV our goal is to switch 100% to using
>storage pools.
>
>For non-storage pool deployments though, I think it is common that
>the mgmt app will have a specific place where it will always put
>disks. eg on OpenStack file based disks will always live under
>/var/lib/nova/instances.
>
>So if there was a qemu.conf setting to whitelist allowed disk image
>locations, we could lock down where we permit relabelling for the
>openstack host as a whole, and not need to change anything on a per
>guest basis.
>
I like the per-guest approach better, but qemu.conf is satisfactory
enough, I guess.
>> It could be nice to get feedback from upper mgmt layers, any idea where
>> else to post this questions?
>
>ovirt might have feedback i guess
>
Cc'd ovirt-devel, even though I don't think they use it (or at least not
yet). If you feel like it, don't hesitate to Cc appropriate OpenStack
list as well (if that's not much cross-posting).
Martin
>Regards,
>Daniel
>--
>|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
>|: http://libvirt.org -o- http://virt-manager.org :|
>|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
>|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
--R3G7APHDIzY6R/pk
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCAAGBQJXw/4jAAoJEAgfwp8kF4bdEV4P/1JP07oQ2ug+sGs5CImqbJak
6eajVCCcobapZgT7rDWbla5e2G5XMdzbV1vVzuIl2OVo4rGmcLuZjozVH8dewg0M
tEjWLenbciXnUcqIrEA8PTP5qAdEAdVUZ/7kwFT3shRjTUOEYk46BM+fiRWz/pQM
DI/xaPpXcZarfohLOGUgdRv+00shQPVZFg786FXBL+aYNFwTfbFDOnboYEYwKhq2
WGHG0PWLF3iIBlJWBFs4Nz1pQ48cw4CGWmXcOGtusIiqud5FsbKjNX+s64PDY1Yz
8UzC4c9+4LyqobUJp5EulsAmXedKK0bTxs4GI/eePkHZfBaRuOJtshbY2iETljsS
Ce1s9Y3gpfP6UzAZImOa67F2rms9Fgv8Mm4pRnG2l/FTCvFSq7Grn8pPKL12jWAN
Ti6hOQGCX45h8lN17zfERlWWPBFk3Mtw3L8bbh8Ja0xhYgsH0qS1mdeE/VmjKKFC
OqZvT9GgtwFg4t77nHCIhFBSTEc3DoV6lNMrPxaTVswXCKSlYJAz2IUd8DFN5FFF
71WlKgvCKWl6iqo2FpxklhqfsUNSL6J31Kgh29r54qYcNZc1oobWsyJAqyeQcpER
3nHyY14QhIDc2LojcEisGXyPErtHZiVfexlB++Ap2O5W3tkxH08yWnV0Cd2J+CK2
MLB3K7JjrEt84oY8EGP8
=JNYW
-----END PGP SIGNATURE-----
--R3G7APHDIzY6R/pk--
7 years, 7 months
