| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
| |
We previously got this implicitly via a dep from python3-pytest
so never noticed that it was missing. The implicit dep is going
away in rawhide real soon.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
|
| |
|
|
| |
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
| |
Expose the artifacts from the centos-stream-8/9 and fedora 35/36 jobs so
that the main libvirt integration testing project can consume them.
The new libvirt sub-rpm containing a python helper to access QMP
directly requires python environment which we didn't yet install in the
integration job.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
|
| |
|
|
|
|
|
|
|
| |
The libvirt_virStreamRecv function uses a temporary allocated buffer to
receive data before copying the data into a Python byte array. But
there are some error paths where this buffer is not freed. This change
fixes that memory leak.
Signed-off-by: Chris Gunn <chrisgun@microsoft.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The 'extends' stanza supports a list, however there's a merge algorithm
in place where a subsequent list entry overwrites all conflicting
settings from the previous one - which is exactly what happened here as
the gitlab-build-{local,prebuilt}-env job template overwrote
api-coverage's stage to 'builds' whereas the original was
'sanity_checks'.
Fixes: 4733e2a2d13cb9a85127ba17c04cc29278b31e89
Signed-off-by: Erik Skultety <eskultet@redhat.com>
|
| |
|
|
| |
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This refresh switches the CI for contributors to be triggered by merge
requests. Pushing to a branch in a fork will no longer run CI pipelines,
in order to avoid consuming CI minutes. To regain the original behaviour
contributors can opt-in to a pipeline on push
git push <remote> -o ci.variable=RUN_PIPELINE=1
This variable can also be set globally on the repository, though this is
not recommended. Upstream repo pushes to branches will run CI.
The use of containers has changed in this update, with only the upstream
repo creating containers, in order to avoid consuming contributors'
limited storage quotas. A fork with existing container images may delete
them. Containers will be rebuilt upstream when pushing commits with CI
changes to the default branch. Any other scenario with CI changes will
simply install build pre-requisite packages in a throaway environment,
using the ci/buildenv/ scripts. These scripts may also be used on a
contributor's local machines.
With pipelines triggered by merge requests, it is also now possible to
workaround the inability of contributors to run pipelines if they have
run out of CI quota. A project member can trigger a pipeline from the
merge request, which will run in context of upstream, however, note
this should only be done after reviewing the code for any malicious
CI changes.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
|
| |
|
|
|
|
|
| |
The -lvirt linker flag has to be added to the libvirtmod_qemu and
libvirtmod_lxc modules as well.
Signed-off-by: Bastian Germann <bage@linutronix.de>
|
| |
|
|
|
|
| |
Mingw-w64 target does not support uint definition.
Signed-off-by: Bastian Germann <bage@linutronix.de>
|
| |
|
|
| |
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
|
| |
|
|
| |
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Our APIs which accept typed parameters are usually exposed in
python as accepting dictionary, for instance:
virDomainSetIOThreadParams(..., virTypedParameterPtr params, ...) ->
virDomain.setIOThreadParams(..., {}, ...)
Now, before calling the C API, the dictionary is processed by
virPyDictToTypedParams() which accepts an additional argument:
array that hints types for each typed parameter. However, if a
key is not in the array we guess what the correct type might be.
This is done by attempting conversion from python into string, if
that fails then into boolean, then into long, only to fall back
to double. Now, for the long type we can have two cases: the
value is non-negative (ULL) or it is negative (LL). Therefore, we
firstly attempt ULL case and if that fails we stick with the
latter.
However, after we attempted the ULL conversion, python records an
error internally (which is then queried via PyErr_Occurred()),
but the error is never cleared out. This leads to spurious paths
taken afterwards: e.g. when libvirt_longlongUnwrap() is trying to
convert -1, it fails. But not rightfully - the PyErr_Occurred()
check it performs has nothing to do with any of its actions,
rather than our guessing work done before.
Therefore, clear the error after we've guessed the type.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The python version of virDomainSetIOThreadParams
(setIOThreadParams()), expects two arguments on input: the thread
ID and a dictionary which is then translated into our typed
parameters. During this translation we use a helper array which
holds type for each typed parameter supported
(virPyDomainSetIOThreadParams[]). Otherwise we guess what the
correct type is. Now, when introducing
VIR_DOMAIN_IOTHREAD_THREAD_POOL_{MIN,MAX} typed params into
libvirt I forgot to update the array. Do that now.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
|
| |
|
|
| |
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
After the switch of 'my_clean' to a simple Command, the 'clean' command
has no more bits for options, resulting in distutils (either external
or embedded in setuptools) complaining about it:
distutils.errors.DistutilsClassError: command class <class '__main__.my_clean'> must provide 'user_options' attribute (a list of tuples)
To overcome that, provide all the standard bits from options, i.e. the
'user_options' list, and the 'initialize_options' & 'finalize_options'
methods. In addition, add a dummy 'all' option, as distutils wants it:
error: error in [...]/.pydistutils.cfg: command 'my_clean' has no such option 'all'
Fixes commit a965c91c6fa1275613edbbef75c0422574eb9ff2
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
|
| |
|
|
|
|
|
| |
Add classifiers that indicate we intend to support python versions
3.9 and 3.10.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
|
| |
|
|
|
|
|
|
| |
In Python 3.10 the setDaemon method was deprecated. It is redundant
since the 'daemon' parameter can be given when creating the thread,
or the 'daemon' attribute can be set after it was created.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Add a test for one more usage scenario that was possible in the past,
whereby libvirt events are registered before starting the asyncio
loop, but we let libvirt find the loop associated with the current
thread.
Skip the test relies on auto-creating an event loop with Python >= 3.10
since it now triggers a deprecation warning which will soon turn into a
RuntimeError.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
We currently have to run each of the test_aio.py test cases in a
separate process, because libvirt.virEventRegisterImpl can only be
called once per process. This leads to quite unpleasant console
output when running tests.
By introducing a mock for libvirt.virEventRegisterImpl we can
regain the ability to run everything in a single process. The only
caveat is that it relies on tests to fully cleanup, but in practice
this is ok for our current tests.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
|
| |
|
|
| |
Signed-off-by: Chris Gunn <chrisgun@microsoft.com>
|
| |
|
|
| |
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The drain method uses an asyncio.Event object to be notified when other
coroutines have removed all registered callbacks. The Event object needs
to be associated with the coroutine that the event loop is running with
and currently this is achieved by passing in the 'loop' parameter.
Unfortunately Python 3.10 has removed the 'loop' parameter and now the
object is associated implicitly with the current thread's event loop.
At the time the virEventAsyncIOImpl constructor is called, however,
there is no guarantee that an event loop has been set for the thread.
The explicitly passed in 'loop' parameter would handle this scenario.
For portability with Python >= 3.10 we need to delay creation of the
Event object until we have a guarantee that there is a loop associated
with the current thread. This is achieved by lazily creating the Event
object inside the 'drain' method, which is expected to be invoked from
coroutine context and thus ensure a loop is associated.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The 'async' keyword is new in Python 3.5, as a way to declare that a
method is a coroutine. This replaces the '@asyncio.coroutine' decorator
that is deprecated since 3.8 and scheduled to be removed in 3.11
The 'await' keyword has to be used instead of 'yield' from any
coroutines declared with 'async'.
Signed-off-by: Chris Gunn <chrisgun@microsoft.com>
[DB: Split off from a larger patch mixing multiple changes]
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
|
| |
|
|
|
|
|
|
|
|
| |
setup.py ensures we have python >= 3.5, so there is no need to do
back compat with the 'asyncio.ensure_future' method, which was new
in 3.4.4
Signed-off-by: Chris Gunn <chrisgun@microsoft.com>
[DB: Split off from a larger patch mixing multiple changes]
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
|
| |
|
|
| |
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
|
| |
|
|
| |
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
|
| |
|
|
| |
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
|
| |
|
|
|
|
| |
The API coverage test is no longer a special case.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The python lxml registers some global callbacks with libxml2. As a
result when another user of libxml2 calls APIs, it can trigger the
python callbacks that lxml previously registered. Execution of the
python callbacks in this case is often unsafe and leads to SEGVs.
This hasn't been a problem since the sanitytest.py test has been
a standalone program we execute. When it gets turned into a real
python unit test, it will run in the same process as all the other
tests and trigger the crash.
A mitigation was added in lxml 4.5.2 which is good enough to let
us continuing using lxml.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
|
| |
|
|
|
|
|
| |
The sanitytest.py file is now using the normal python unittest
pattern, though we invoke the one test explicitly for now.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
|
| |
|
|
|
|
|
|
|
| |
This is a step towards turning the sanitytest.py file into a normal
python unittest.
Best viewed with the '-b' flag to diff.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
|
| |
|
|
|
|
|
|
|
| |
This is a step towards turning the sanitytest.py file into a normal
python unittest.
Best viewed with the '-b' flag to diff.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
|
| |
|
|
|
|
|
|
|
| |
This is a step towards turning the sanitytest.py file into a normal
python unittest.
Best viewed with the '-b' flag to diff.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
|
| |
|
|
|
|
|
|
|
| |
This is a step towards turning the sanitytest.py file into a normal
python unittest.
Best viewed with the '-b' flag to diff.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
|
| |
|
|
|
|
|
|
|
| |
This is a step towards turning the sanitytest.py file into a normal
python unittest.
Best viewed with the '-b' flag to diff.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
|
| |
|
|
|
|
|
|
|
| |
This is a step towards turning the sanitytest.py file into a normal
python unittest.
Best viewed with the '-b' flag to diff.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
|
| |
|
|
|
|
|
|
|
| |
This is a step towards turning the sanitytest.py file into a normal
python unittest.
Best viewed with the '-b' flag to diff.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We want to move over to make sanitytest.py operate like a more normal
test script, which means making it self contained.
The setup.py already sets the PYTHONPATH thanks to changes introduced
in:
commit eaded7bdadf3ccdc4b208ec0ed65a1b23b8b5f69
Author: Daniel P. Berrange <berrange@redhat.com>
Date: Tue Mar 18 11:11:48 2014 +0000
Add support for running unit tests with nose
so passing the python module path into sanitytest.py is redundant.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
| |
We want to move over to make sanitytest.py operate like a more normal
test script, which means making it self contained.
The test already knows how to find the libvirt API XML path using
pkg-config and if an override location is required, this can be done
by pointing $PKG_CONFIG_PATH to a suitable place.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
|
| |
|
|
|
|
|
|
|
| |
The distutils package is deprecated and targetted for deletion in Python
3.12, so we need to switch to setuptools. Thanks to all the preceeding
changes this is no more difficult than changing the import statements.
Closes https://gitlab.com/libvirt/libvirt-python/-/issues/1
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
|
| |
|
|
|
|
|
|
|
|
| |
The 'get_platform' function is used to determine the platform specific
component of the build output directory containing the loadable
modules and python code. There is no nice replacement for this
function, but we can achieve our goal by simply scaning for the desired
subdirectory, which should exist by the time 'test' runs.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We override the 'build' command to invoke the code generator before the
extensions are compiled. The 'build' command, however, is merely a
wrapper around several other commands. It is possible for the user to
directly invoke those commands, in which case our code generator won't
get a chance to run:
$ python setup.py build_ext
running build_ext
building 'libvirtmod' extension
creating build/temp.linux-x86_64-3.10
creating build/temp.linux-x86_64-3.10/build
gcc ..snip... -c build/libvirt.c -o build/temp.linux-x86_64-3.10/build/libvirt.o
cc1: fatal error: build/libvirt.c: No such file or directory
compilation terminated.
error: command '/usr/lib64/ccache/gcc' failed with exit code 1
To solve this we instead override 'build_ext' and 'build_py'. This in
turn means we call the generator to emit C code separately from Python
code.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
|
| |
|
|
|
|
|
| |
The distutils.dir_util.remove_tree method has no compelling benefit
over using the standard python shutils module.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
|
| |
|
|
|
|
|
| |
The distutils.spawn method has no compelling benefit over using the
standard python subprocess module.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
|
| |
|
|
|
|
|
| |
The distutils.spawn.find_executable method has no compelling benefit
over using the standard python shutils module.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
|
| |
|
|
|
|
|
|
| |
Instead of searching for the pkg-config binary manually, just try to run
it and catch the exception raised if it isn't found. Use the --version
flag as a way to validate that it is at least somewhat functional.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
|
| |
|
|
|
|
|
|
|
| |
The default 'clean' command impl deletes only intermediate files from
the 'build' directory. We've overridden it to delete everything. There
is no benefit in inheriting from the default impl, given our subclass
will delete everything.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
|
| |
|
|
|
|
|
| |
This duplicates funtionality already provided by the 'bdist_rpm'
command.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
|
| |
|
|
|
|
|
|
| |
Currently we always generate both the C code and Python code at the same
time. To cope with following changes to the build process, we want to be
able to generate C and Python separately.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
|
| |
|
|
|
|
| |
The names make it clearer exactly what is being generated by each.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
|
