IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
This can help us find object leaks within the code. virConnectClose
is just a deference and will return 1 if other references are still
floating around.
A new Python checker was added to warn about using a + operator inside
call of logging methods when one of the operands is a literal string.
https://pylint.readthedocs.io/en/latest/whatsnew/1.8.html
Signed-off-by: Radostin Stoyanov <rstoyanov1@gmail.com>
In python3 exceptions aren't defined outside the except block. Leading
to 'UnboundLocalError: local variable 'e' referenced before assignment'
errors.
To work around this, store the local variable into one that will have a
longer life.
Fix all E125:
Continuation line with same indent as next logical line
Also remove ignore options of E125
Signed-off-by: Chen Hanxiao <chenhanxiao@gmail.com>
If initialization of new object fails we put it into blacklist and
newer parse it again until virt-manager is restarted. This helps to
reduce number of failures if some object fails initialization every
time.
However, there are some cases where we put object into blacklist
incorrectly. One of the cases is while creating new storage pool.
If the storage pool requires to be build before started but user
doesn't check to build it as well the start of the new storage pool
fails. The issue is that at first we define that object which triggers
a lifecycle event for storage pool and queues new poll operation over
storage pools. Before the poll operation starts the starting of the
storage pools fails and we undefine that storage pool before it is
initialized. The initialization fails and the storage pool is never
managed from that point.
This patch modifies the blacklist to allow 3 failures before we give up
on a specific object and if the object is initialized without error
we remove it from blacklist completely.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1446486
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1093394
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
The current implementation calls _new_object_cb, which isn't
expected to be run from a non-main thread, and can cause crashes.
https://bugzilla.redhat.com/show_bug.cgi?id=1457170
Switch the impl to just wait for 3 seconds for the pool to show
up in our cache.
The cb_add_new_pool callback will add a newly created storage pool
into virt-manager's cache so we don't have to wait for the libvirt
event to be handled.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1435064
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Add virtuozzo hypervisor to connection list.
Add radio buttons for choosing VM or container virtualization type.
New wizard window for setting template name for containers.
When creating a storage volume, it wouldn't show up in the list
since the refresh signaling was busted.
Code was using VIR_STORAGE_POOL_EVENT_REFRESHED which was dropped
from lifecycle event type, refresh is introduced as top level
event.
We need to tweak refresh() handling to work similar to the shared
XML and status caching in libvirtobject.py: when the user manually
invokes the refresh() operation, and storage events are set up,
we just invoke the refresh() but let the event loop handle
refreshing the cache.
This fixes a backtrace when invoking a manual refresh via the
host details dialog
When new pool objects appear, we call refresh() on them, to ensure
we have the latest data (in case manual changes were made to the
storage pool directory behind libvirt's back, which is quite common).
However with the storage event support, this results in lots of
REFRESHED signals during initial connection startup, which kick
off redundant object polling.
Avoid storage REFRESHED events if they come in before the connection
is finished starting up to skip this redundant polling.
Otherwise this triggers some event calls and results in double
polling during connection startup. Doesn't cause any issues, just
spams the logs and needless libvirt calls
In case that libvirtd is stopped, we could receive another type of error
from libvirt "libvirtError: internal error: client socket is closed".
This one is usually reported from local connection.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
pygobject doesn't seem to choke on debug_leak_check anymore, so we
can use it to find object leaks. just doing a few for now since it's
generally not a big deal.
It happens every now and then that a libvirt bug means calling XMLDesc
on an object will always fail. For example:
https://bugzilla.redhat.com/show_bug.cgi?id=1225771
We don't handle this very well and it can bleed into many other parts of
the code in a bad way. So if the initial polling of the object fails,
blacklist it entirely and ignore it for all future polling.
