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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
In python 3.7, async is now a keyword, so this throws a syntax error:
File "/usr/lib64/python3.7/site-packages/libvirtaio.py", line 49
from asyncio import async as ensure_future
^
SyntaxError: invalid syntax
Switch to getattr trickery to accomplish the same goal
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This binding allows to query the AMD's SEV firmware for various platform
specific things, like a PDH certificate and a certificate chain to
establish a trusted connection with the firmware. Because the API uses
typed params, it's exempted from generation.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Libvirt recently introduced support for getting launch security
parameters, most notably AMD SEV VM memory measurement. This API can't
be generated as it's using typed parameters which we need to allocate.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Function libvirt_charPtrUnwrap() either fails or always sets the
unwrapped string so there is no need to check it explicitly.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
In virConnectCredCallbackWrapper() we ignore the error case of
libvirt_charPtrUnwrap() function so we should also reset the exception.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Commit <57a160b5248ba47d4e1c9d22d95847dad8e0524f> removed last usage
but did not remove the function itself.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1578337
Since libvirt 3.8.0 we have 6 events: defined, undefined,
started, stopped, created, deleted. However, the last two were
missing in a string list that translates libvirt events (int)
into human readable strings.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
The libvirt python bindings are now more 'pythonic' as virConnect can
now be used as a context manager.
For example, it's possible to write the following code:
with libvirt.open() as conn:
# do something with the connection...
print(conn.listAllDomains())
At the end of this with-block the connection will be closed
automatically.
Signed-off-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com>
Reviewed-by: Bjoern Walk <bwalk@linux.vnet.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com>
The Test-AutoBuild project, that this script is supposed
to be used with, hasn't seen any activity in ~7 years;
these days, libvirt-python CI builds are happening on the
Jenkins-based CentOS CI environment under the libvirt
umbrella[1], and in that context the script is not used
at all.
[1] https://ci.centos.org/view/libvirt/
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
The "git-publish" tool is a useful git extension for sending patch
series for code review. It automatically creates versioned tags
each time code on a branch is sent, so that there is a record of
each version. It also remembers the cover letter so it does not
need re-entering each time the series is reposted.
With this config file present it is now sufficient[1] to run
$ git publish
to send all patches in a branch to the list for review, with the
correct subject prefix added for this non-core libvirt module.
[1] Assuming your $HOME/.gitconfig has an SMTP server listed
at least e.g.
[sendemail]
smtpserver = smtp.example.com
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The libvirt python module is supposed to build with historical versions
of the API back to 0.9.1, which means all constants / methods must be
wrapped in conditionals. This was accidentally forgotten in:
commit 314b2346df
Author: Edgar Kaziakhmedov <edgar.kaziakhmedov@virtuozzo.com>
Date: Wed Feb 7 17:49:30 2018 +0300
Set hints for virPyDictToTypedParams
Predefine hints for all parameters possible to avoid wrong type
convert.
This broke the build against any libvirt < 2.0.0
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The end of Python 2 is nearing, so declare when it will be removed
from libvirt Python binding RPMs.
NB, this doesn't imply we'll be removing py2 support from upstream
libvirt-python on the same timeframe - we'll consider what todo
wrt that when upstream Python 2 finally goes EOL.
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This corresponds to the order in libvirt-domain.h header file.
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
There is no need to have dynamic allocation every time the API
is called. Rewrites commit <314b2346df>.
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Note we use python_sitearch not python2_sitearch, since the former
is more portable.
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Although we're capable of building against any libvirt >= 0.9.11, 99% of the
time we want RPM builds to be done against matching libvirt version, otherwise
we might silently build against an unexpected/wrong version.
We don't support building against a native libvirt that's newer than the
python binding, since the generator may incorrectly handle new APIs. So use
== instead of >= too.
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
It is expected that future RHEL-8 will have python3 by default, so enable that.
It is unclear whether python2 will still be available, so leave that enabled
for now.
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Be clear about which distros we aim to support with the specfile, so we know
what we can cleanup in the spec later.
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Allow using
rpmbuild --define "with_python2 0"
to override the default logic about which python sub-RPMs to build
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
With Fedora modularity, it is possible to have add-on repos for multiple
versions of python3. It is thus desirable to be able to build libvirt-python
in these repos, with only the python3 sub-RPMs enabled.
Thus also helps if future RHEL/Fedora drop python2 entirely from their default
repos.
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
This is particularly useful on operating systems that don't ship
Python as part of the base system (eg. FreeBSD) while still working
just as well as it did before on Linux.
Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
Most of the code treats libvirt API calls as separate block, keeping one
blank line before the LIBVIRT_BEGIN_ALLOW_THREAD, and one blank line
after LIBVIRT_END_ALLOW_THREADS. Unify the whitespace so all calls
wrapped with these macros are treated as a separate block.
We discovered that the entire python process get stuck for about 30
seconds when calling virDomain.getMemoryStats() if libvirt is stuck in
virConnect.getAllDomainStats() on inaccessible storage. This blocking
cause a horrible mess in oVirt.
This patches adds the standard *_ALLOW_THREADS around the call to avoid
this unwanted blocking.
Signed-off-by: Nir Soffer <nirsof@gmail.com>
Latest GCC versions are unhappy with us treating an integer
arithmetic result as a boolean:
libvirt-utils.c: In function ‘virReallocN’:
libvirt-utils.c:111:23: warning: ‘*’ in boolean context, suggest ‘&&’ instead [-Wint-in-bool-context]
if (!tmp && (size * count)) {
~~~~~~^~~~~~~~
Add an explicit comparison '!= 0' to keep it happy, since its
suggestion to use '&&' is nonsense.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
When python3 builds C modules, it adds the -Wsign-compare flag to GCC.
This creates lots of warnings where we compare a 'size_t' value against
an 'int' value due to signed/unsigned difference. Change all the size_t
types to ssize_t to address this.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
The intended use is to ensure that the implementation is empty, which is
one way to ensure that all connections were properly closed and file
descriptors reclaimed.
Signed-off-by: Wojtek Porczyk <woju@invisiblethingslab.com>
Since 7534c19 it is not possible to register event implementation twice.
Instead, allow for retrieving the current one, should it be needed
afterwards.
Signed-off-by: Wojtek Porczyk <woju@invisiblethingslab.com>