I'm getting the feeling I'm not alone in this, authoring and publishing a
wiki page isn't as used to be for long time.
I want to suggest a bit lighter workflow:
1. Everyone can merge their page - (it's a wiki)
Same as with (public and open) code, no one has the motivation to publish
a badly written
wiki page under their name. True, it can have an impact, but not as with
2. Use Page-Status marker
The author first merges the draft. Its now out there and should be updated
as time goes and its
status is DRAFT. Maintainers will come later and after review would change
the status to
PUBLISH. That could be a header in on the page:
page status: DRAFT/PUBLISH
Simple I think, and should work.
Ever wanted to raise level of the engine logs and wanted to to that fast
This is a small wrapper around wildfly mgmt interface, called *log-control*
to do the trick
Example, debug the db interaction layer:
./log-control org.ovirt.engine.core.dal debug
It will first try blantly to add the log category and then will set the log
level according to what you set. It is simple and stupid.
More interesting logger categories:
business logic (commands, queries) - org.ovirt.engine.core.bll
hosts interaction - org.ovirt.engine.core.vdsbroker
various utilities - org.ovirt.engine.core.utils
aaa - org.ovirt.engine.exttool.aaa
General suggestion -
I think is is it time for *ovirt-engine-contrib* so mini-helpers like that
can exists and when they are solid can go into mainstream repo, if needed
Yes, vdsm is not able to resolve 'engine' which is used in engine's
29 kwi 2017 00:37 "Nadav Goldin" <ngoldin(a)redhat.com> napisał(a):
Can you clarify what you noticed is not resolvable - the 'engine' FQDN
On Fri, Apr 28, 2017 at 4:15 PM, Piotr Kliczewski <pkliczew(a)redhat.com>
> I started to investigate the issue  and it seems like there is an issue
> in Lago setup we use.
> During handshake we have a step to verify whether client certificate was
> issued for a specific host (no such functionality in m2crytpo code base).
> It works fine when using either ip addresses or fqdns but in this
> setup we use mixed.
> When added logging I see that in engine certificate we use 'engine' name
> which is not resolvable on the host side and the check fails.
> I posted a patch  which fixes IPv4 mapped addresses issue but we need
> fix the setup issue.
>  http://jenkins.ovirt.org/job/ovirt-system-tests_manual/326/
>  https://gerrit.ovirt.org/#/c/76197/
> On Thu, Apr 27, 2017 at 3:39 PM, Piotr Kliczewski <pkliczew(a)redhat.com>
>> On Thu, Apr 27, 2017 at 3:13 PM, Evgheni Dereveanchin
>> <ederevea(a)redhat.com> wrote:
>>> Test failed: 002_bootstrap/add_hosts
>>> Link to suspected patches:
>>> https://gerrit.ovirt.org/76107 - ssl: change default library
>>> Link to job:
>>> VDSM log:
>>> Error snippet from VDSM log, this repeats on each connection attempt
>>> Engine side:
>>> 2017-04-27 06:39:27,768-0400 INFO (Reactor thread)
>>> [ProtocolDetector.AcceptorImpl] Accepted connection from
>>> ::ffff:192.168.201.3:49530 (protocoldetector:74)
>>> 2017-04-27 06:39:27,898-0400 ERROR (Reactor thread) [vds.dispatcher]
>>> uncaptured python exception, closing channel
>>> <yajsonrpc.betterAsyncore.Dispatcher connected ('::ffff:192.168.201.3',
>>> 49530, 0, 0) at 0x1cc3b00> (<class 'socket.error'>:Address family not
>>> supported by protocol [/usr/lib64/python2.7/asyncore.py|readwrite|110]
>> This means that what we have in the certificate do not match the source
>> address we get. I suspect that we issue the certificate for 192.168.201.3
>> but when we get ::ffff:192.168.201.3.
>> The change was verified in the env when ipv4 is used. I pushed a revert
>>  for now so we can work on fixing the issue.
>>  https://gerrit.ovirt.org/#/c/76160
>>> Evgheni Dereveanchin
> Devel mailing list
Content-Type: text/plain; charset=us-ascii
We're trying to improve the debugability of Gluster backed VMs and one
of the features for this is to be able to gather "statedumps". These
statedumps include memory allocation details and other information about
the Gluster client. QEMU is one of the applications that can be
configured to use libgfapi.so Gluster client.
Gluster provides the /var/run/gluster/ directory and the libgfapi.so
library that qemu (in block/gluster.c) uses that. Would there be a
problem for the "qemu" packages to use add the "qemu" user to a
"gluster" group? I'm not sure yet how this is done for other packages
with their own users, but there would be a dependent installation order
of some kind (needs rpm triggers?).
What is your opinion on this issue, or would you recommend an other
PS: https://bugzilla.redhat.com/1445569 can be used to reply as well
On Tue, Apr 25, 2017 at 07:53:06PM +0200, Niels de Vos wrote:
> Recently a new ability to trigger statedumps through the Gluster-CLI 
> has been added. This makes it possible to get statedump from
> applications that use gfapi. By default, statedumps are saved under
> /var/run/gluster/... and this directory is only writable by root.
> Applications that use gfapi do not require root permissions (like QEMU),
> and therefore fail to write the statedump :-/
> One approach would be to create a "gluster" group and give the group
> permissions to write to /var/run/gluster/... Other 'fixes' include
> setting ACLs on the directory so that specified users can write there.
> because many daemons have a "home directory" that does not exist, it
> probably is not a good idea to use $HOME to store statedumps.
> What suggestions do others have?
> 0. https://github.com/gluster/glusterfs/blob/master/doc/debugging/statedu=
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
-----END PGP SIGNATURE-----