On Tue, 2019-10-01 at 16:28 +0200, Fabiano Fidêncio wrote:
> +- name: Enable EPEL
> + command: '{{ package_manager }} install epel-release -y'
> + args:
> +warn: no
> + when:
> +- os_name == 'CentOS'
> +
At this point in the playbook the package module has been properly
bootstrapped (as
On Tue, 2019-10-01 at 16:28 +0200, Fabiano Fidêncio wrote:
> As latest CentOS7 release includes python3, let's update python3
> mapping.
>
> Signed-off-by: Fabiano Fidêncio
> ---
> guests/vars/mappings.yml | 1 -
> 1 file changed, 1 deletion(-)
\o/
Reviewed-by: Andrea Bolognani
--
Andrea Bo
On 9/27/19 5:32 PM, Daniel Henrique Barboza wrote:
On 9/27/19 5:33 PM, Cole Robinson wrote:
On 9/26/19 10:56 AM, Daniel Henrique Barboza wrote:
Signed-off-by: Daniel Henrique Barboza
---
I've made this test file to make sure I wasn't messing
up with the logic at patch 8. The idea of having
On 9/27/19 11:09 AM, Daniel Henrique Barboza wrote:
All the 6 virGetConnect* functions in driver.c shares the
same code base. This patch creates a new static function
virGetConnectGeneric() that contains the common code to
be used with all other virGetConnect*.
Signed-off-by: Daniel Henrique Bar
Commit 570143fc41fa removed all unsuitable Debian-based
distributions, but failed to account for the fact that CentOS 7
doesn't have a Meson version suitable to build osinfo-db-tools
and as such can't possibly build osinfo-db.
Signed-off-by: Andrea Bolognani
---
Pushed as a CI fix.
guests/playb
On 10/2/19 11:48 AM, Jiri Denemark wrote:
> On Thu, Sep 19, 2019 at 16:24:51 -0400, Collin Walling wrote:
>> Note: since I've made some changes to a lot of these patches / split
>> up some patches, I've decided to hold off on adding any r-b's in case
>> there is a specific change that someone does
On Tue, 2019-10-01 at 16:28 +0200, Fabiano Fidêncio wrote:
> +# Add the multilib path to the LD_LIBRARY_PATH, PKG_CONFIG_PATH, and
> GI_TYPELIB_PATH
> +# The multilib path can be discovered either using `dpkg-architecture` (on
> Debian based
> +# machines) or by calling `rpm --eval '%{_lib}'` (on
On Wed, Oct 2, 2019 at 4:16 PM Andrea Bolognani wrote:
>
> Andrea Bolognani (2):
> guests: Fix project list
> Fix target list for builds
>
> guests/host_vars/libvirt-centos-7/main.yml | 1 -
> guests/host_vars/libvirt-debian-9/main.yml | 2 --
> guests/host_vars/libvirt-ubuntu-16/
On Thu, Sep 19, 2019 at 16:24:51 -0400, Collin Walling wrote:
> Note: since I've made some changes to a lot of these patches / split
> up some patches, I've decided to hold off on adding any r-b's in case
> there is a specific change that someone does not agree with.
>
> Changelog:
>
> - Prop
On Thu, Sep 19, 2019 at 16:25:06 -0400, Collin Walling wrote:
> Providing an erroneous CPU definition in the XML file provided to the
> hypervisor-cpu-compare/baseline command will result in a verbose
> internal error. Let's add some sanity checking before executing the QMP
> commands to provide a
On 10/2/19 9:52 AM, Jiri Denemark wrote:
> On Thu, Sep 19, 2019 at 16:25:00 -0400, Collin Walling wrote:
>> This command is hooked into the virsh hypervisor-cpu-baseline command.
>> The CPU models provided in the XML sent to the command will be baselined
>> via the query-cpu-model-baseline QMP comm
On Wed, Oct 02, 2019 at 08:34:10AM -0300, Daniel Henrique Barboza wrote:
>
>
> On 10/1/19 11:45 AM, Pavel Mores wrote:
> > virDomainGetBlockInfo() returns error if called on a disk with no target
> > (a targetless disk might be a removable media drive with no media in it,
> > for instance an empt
Andrea Bolognani (2):
guests: Fix project list
Fix target list for builds
guests/host_vars/libvirt-centos-7/main.yml | 1 -
guests/host_vars/libvirt-debian-9/main.yml | 2 --
guests/host_vars/libvirt-ubuntu-16/main.yml | 1 -
guests/host_vars/libvirt-ubuntu-18/main.yml |
We've disabled osinfo-db-tools and libosinfo builds on some targets
after they switched to Meson, but while doing so we forgot to also
disable osinfo-db and virt-manager, which depend on them.
Signed-off-by: Andrea Bolognani
---
guests/host_vars/libvirt-centos-7/main.yml | 1 -
guests/host_vars
Targets that don't build osinfo-db-tools and libosinfo should not
build osinfo-db and virt-manager.
Signed-off-by: Andrea Bolognani
---
guests/playbooks/build/projects/osinfo-db.yml| 3 ---
guests/playbooks/build/projects/virt-manager.yml | 4
jenkins/projects/osinfo-db.yaml
On Thu, Sep 19, 2019 at 16:25:01 -0400, Collin Walling wrote:
> Perform a full CPU model expansion on the result of the baselined
> model name when the features flag is present.
>
> Signed-off-by: Collin Walling
> ---
> src/qemu/qemu_driver.c | 15 ++-
> 1 file changed, 14 insertions
On Thu, Sep 19, 2019 at 16:25:02 -0400, Collin Walling wrote:
> Interfaces with QEMU to compare CPU models. The command takes two CPU
> models, A and B, that are given a model name and an optional list of
> CPU features. Through the query-cpu-model-comparison command issued
> via QMP, a result is p
On Thu, Sep 19, 2019 at 16:25:05 -0400, Collin Walling wrote:
> This command is hooked into the virsh hypervisor-cpu-compare command.
> As such, the CPU model XML provided to the command will be compared
> to the hypervisor CPU contained in the QEMU capabilities file for the
> appropriate QEMU bina
On Thu, Sep 19, 2019 at 16:25:04 -0400, Collin Walling wrote:
> Implement an XML to virCPUDefPtr helper that handles the ctxt
> prerequisite for virCPUDefParseXML.
>
> This does not alter any functionality.
>
> Signed-off-by: Collin Walling
> Reviewed-by: Bjoern Walk
> Reviewed-by: Daniel Henri
On Thu, Sep 19, 2019 at 16:25:00 -0400, Collin Walling wrote:
> This command is hooked into the virsh hypervisor-cpu-baseline command.
> The CPU models provided in the XML sent to the command will be baselined
> via the query-cpu-model-baseline QMP command. The resulting CPU model
> will be reporte
On Thu, Sep 19, 2019 at 16:24:58 -0400, Collin Walling wrote:
> Interfaces with QEMU to baseline CPU models. The command takes two
> CPU models, A and B, that are given a model name and an optional list
> of CPU features. Through the query-cpu-model-baseline command issued
> via QMP, a result is pr
On Thu, Sep 19, 2019 at 16:24:54 -0400, Collin Walling wrote:
> When expanding a CPU model via query-cpu-model-expansion, any features
> that were a part of the original model are discarded. For exmaple,
> when expanding modelA with features f1, f2, a full expansion may reveal
> feature f3, but the
On Thu, Sep 19, 2019 at 16:24:57 -0400, Collin Walling wrote:
> Modify the error messages in qemuMonitorJSONParseCPUModelData to print
> the command name provided to the function.
>
> Signed-off-by: Collin Walling
> ---
> src/qemu/qemu_monitor_json.c | 15 ---
> 1 file changed, 8 ins
On Thu, Sep 19, 2019 at 16:24:56 -0400, Collin Walling wrote:
> Some older s390 CPU models (e.g. z900) will not report props as a
> response from query-cpu-model-expansion. As such, we should make the
> props field optional when parsing the return data from the QMP response.
>
> Signed-off-by: Col
On Thu, Sep 19, 2019 at 16:24:53 -0400, Collin Walling wrote:
> With refactoring most of the expansion function, let's take care of
> some additional cleanups.
>
> Signed-off-by: Collin Walling
> ---
> src/qemu/qemu_monitor_json.c | 37 ++---
> 1 file changed, 14
On Thu, Sep 19, 2019 at 16:24:55 -0400, Collin Walling wrote:
> query-cpu-model-baseline/comparison will accept a list of features
> as part of the command. Since CPUs may be defined with CPU feature
> policies, let's parse it to the appropriate boolean that the QMP
> command expects.
>
> A featur
On Thu, Sep 19, 2019 at 16:24:52 -0400, Collin Walling wrote:
> Refactor some code in qemuMonitorJSONGetCPUModelExpansion to be later
> used for the comparison and baseline functions.
>
> Signed-off-by: Collin Walling
> Reviewed-by: Bjoern Walk
> Reviewed-by: Daniel Henrique Barboza
> ---
> sr
On Wed, Oct 02, 2019 at 02:11:39PM +0200, Pavel Mores wrote:
On Wed, Oct 02, 2019 at 01:15:12PM +0200, Ján Tomko wrote:
Real estate in the commit message summary is precious, so the e.g.
part belongs in the commit message.
Right.
Also, (unless some strange usage sneaked into our XML), deals
On Wed, Oct 02, 2019 at 02:04:28PM +0200, Michal Privoznik wrote:
> On 10/2/19 1:11 PM, Daniel P. Berrangé wrote:
> > On Wed, Oct 02, 2019 at 10:45:28AM +0200, Michal Privoznik wrote:
> > > On 9/30/19 3:41 PM, Pavel Mores wrote:
> > > > The way in which the qemu driver generates aliases for disks i
The current 'for' loop with 5 consecutive 'ifs' inside
qemuBuildHostdevCommandLine can be a bit smarter:
- all 5 'ifs' fails if hostdev->mode is not equal to
VIR_DOMAIN_HOSTDEV_MODE_SUBSYS. This check can be moved to the
start of the loop, failing to the next element immediately
in case it fails;
On Wed, Oct 02, 2019 at 01:15:12PM +0200, Ján Tomko wrote:
> Real estate in the commit message summary is precious, so the e.g.
> part belongs in the commit message.
Right.
> Also, (unless some strange usage sneaked into our XML), deals
> with the host-side where says how the device appears in
On 10/2/19 1:11 PM, Daniel P. Berrangé wrote:
On Wed, Oct 02, 2019 at 10:45:28AM +0200, Michal Privoznik wrote:
On 9/30/19 3:41 PM, Pavel Mores wrote:
The way in which the qemu driver generates aliases for disks involves
ignoring the partition number part of a target dev name. This means that
On 10/1/19 11:45 AM, Pavel Mores wrote:
virDomainGetBlockInfo() returns error if called on a disk with no target
(a targetless disk might be a removable media drive with no media in it,
for instance an empty CDROM drive).
So far this caused the virsh domblkinfo --all command to abort and igno
Real estate in the commit message summary is precious, so the e.g.
part belongs in the commit message.
Also, (unless some strange usage sneaked into our XML), deals
with the host-side where says how the device appears in the
guest, so 'targetless' is wrong here.
On Tue, Oct 01, 2019 at 04:45:0
On Wed, Oct 02, 2019 at 10:45:28AM +0200, Michal Privoznik wrote:
> On 9/30/19 3:41 PM, Pavel Mores wrote:
> > The way in which the qemu driver generates aliases for disks involves
> > ignoring the partition number part of a target dev name. This means that
> > all partitions of a block device and
On 9/30/19 3:41 PM, Pavel Mores wrote:
The way in which the qemu driver generates aliases for disks involves
ignoring the partition number part of a target dev name. This means that
all partitions of a block device and the device itself all end up with the
same alias. If multiple such disks are
36 matches
Mail list logo
