The spec file uses both "libvirt" and "%{name}", but in reality the
expanded value of %{name} will never change. Drop the macro in favor
of the explicit and more readable "libvirt".
Signed-off-by: Jim Fehlig
---
libvirt.spec.in | 66 -
1 file
Rather than checking that the object has the correct key and then
fetching it again use fetch the array first and then use
virJSONValueArrayToStringList to directly convert it.
Additionally we can avoid the conversion if there are no members
simplifying the surrounding logic.
Signed-off-by:
The 'dependencies' field in the return data may be missing in some
cases. Historically 'virJSONValueObjectGetStringArray' didn't report
error in such case, but later refactor (commit 043b50b948ef3c2 ) added
an error in order to use it in other places too.
Unfortunately this results in the error
Use qemuMonitorJSONGetReply in cases where qemuMonitorJSONCheckReply
is followed by virJSONValueObjectGet*(reply, "return").
Signed-off-by: Peter Krempa
---
src/qemu/qemu_monitor_json.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git
Use qemuMonitorJSONGetReply and unify the two blocks with the same
condition.
Signed-off-by: Peter Krempa
---
src/qemu/qemu_monitor_json.c | 19 +++
1 file changed, 7 insertions(+), 12 deletions(-)
diff --git a/src/qemu/qemu_monitor_json.c b/src/qemu/qemu_monitor_json.c
index
In two instances (qemuMonitorJSONGetStringListProperty,
qemuMonitorJSONGetStringArray) the return value is checked by
qemuMonitorJSONCheckReply and extracted by
virJSONValueObjectGetStringArray.
We can use qemuMonitorJSONGetReply which returns it directly and then
virJSONValueArrayToStringList to
Signed-off-by: Peter Krempa
---
src/libvirt_private.syms | 1 -
src/util/virjson.c | 17 -
src/util/virjson.h | 3 ---
3 files changed, 21 deletions(-)
diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms
index a5bb44a9f8..9389778db7 100644
---
Use virJSONValueObjectGetArray + virJSONValueArrayToStringList instead
so that the ofvirJSONValueObjectGetStringArray wrapper can be removed.
Signed-off-by: Peter Krempa
---
src/qemu/qemu_agent.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/qemu/qemu_agent.c
Replace usage of the following pattern with the new helper:
if (qemuMonitorJSONCheckReply(cmd, reply, VIR_JSON_TYPE_OBJECT) < 0)
return -1;
data = virJSONValueObjectGetObject(reply, "return");
Signed-off-by: Peter Krempa
---
src/qemu/qemu_monitor_json.c | 52
Using 'virJSONValueObjectHasKey' when we want to access the value
afterwards is wasteful. Fetch the JSON value right away.
Signed-off-by: Peter Krempa
---
src/qemu/qemu_monitor_json.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/qemu/qemu_monitor_json.c
Introduce virJSONValueArrayToStringList which does only the conversion
from an array to a stringlist.
This will allow refactoring the callers to be more careful in case when
they want to handle the existance of the member in the parent object
differently.
Signed-off-by: Peter Krempa
---
Replace usage of the following pattern with the new helper:
if (qemuMonitorJSONCheckReply(cmd, reply, VIR_JSON_TYPE_ARRAY) < 0)
return -1;
data = virJSONValueObjectGetArray(reply, "return");
Signed-off-by: Peter Krempa
---
src/qemu/qemu_monitor_json.c | 48
Rather than simply checking that the 'return' field is of the expected
type we can directly return it as the caller is very likely going to use
it. Extract the code into the new function and add a wrapper to preserve
old functionality.
Signed-off-by: Peter Krempa
---
First half introduces qemuMonitorJSONGetReply and uses it in our code
base, second half introduces virJSONValueArrayToStringList, uses it to
fix a bug and refactor the rest of the usage.
Peter Krempa (12):
qemu: monitor: Introduce qemuMonitorJSONGetReply, a better
qemuMonitorJSONCheckReply
On Thu, Dec 01, 2022 at 04:58:07PM +0100, Michal Privoznik wrote:
In one of recent commits I've introduced a new test case to
commandtest. In the test case I'm using poll() to wait for data
on a pipe (the write end is passed to commandhelper). However, on
FreeBSD the POLLIN semantic is a bit
In one of recent commits I've introduced a new test case to
commandtest. In the test case I'm using poll() to wait for data
on a pipe (the write end is passed to commandhelper). However, on
FreeBSD the POLLIN semantic is a bit different:
POLLINData other than high priority data may be
Daniel P. Berrangé writes:
> The 'password-secret' option was added
>
> commit b189346eb1784df95ed6fed610411dbf23d19e1f
> Author: Daniel P. Berrangé
> Date: Thu Jan 21 14:19:21 2016 +
>
> iscsi: add support for getting CHAP password via QCryptoSecret API
>
> but was not
Daniel P. Berrangé writes:
> Support for referencing secret objects was added in
>
> commit b189346eb1784df95ed6fed610411dbf23d19e1f
> Author: Daniel P. Berrangé
> Date: Thu Jan 21 14:19:21 2016 +
>
> iscsi: add support for getting CHAP password via QCryptoSecret API
>
> The
Daniel P. Berrangé writes:
> This has been replaced by the 'password-secret' option,
> which references a 'secret' object instance.
>
> Signed-off-by: Daniel P. Berrangé
> ---
> docs/about/deprecated.rst | 8
> docs/about/removed-features.rst | 7 +++
> qemu-options.hx
On Thu, Dec 01, 2022 at 11:17:02AM +0100, Andrew Burden wrote:
> Hello,
> Yeah that's how the kubevirt-dev mailing list works - or is supposed to
> work - as well. Emails from non-members are pending until manually
> approved. I don't see anything pending though so we have an issue there.
>
On Thu, Dec 01, 2022 at 11:17:02AM +0100, Andrew Burden wrote:
> Hello,
> Yeah that's how the kubevirt-dev mailing list works - or is supposed to
> work - as well. Emails from non-members are pending until manually
> approved. I don't see anything pending though so we have an issue there.
>
The 'password-secret' option was added
commit b189346eb1784df95ed6fed610411dbf23d19e1f
Author: Daniel P. Berrangé
Date: Thu Jan 21 14:19:21 2016 +
iscsi: add support for getting CHAP password via QCryptoSecret API
but was not mentioned in the command line docs
Signed-off-by:
This has been replaced by the 'password-secret' option,
which references a 'secret' object instance.
Signed-off-by: Daniel P. Berrangé
---
docs/about/deprecated.rst | 8
docs/about/removed-features.rst | 7 +++
qemu-options.hx | 9 +
ui/spice-core.c
Support for referencing secret objects was added in
commit b189346eb1784df95ed6fed610411dbf23d19e1f
Author: Daniel P. Berrangé
Date: Thu Jan 21 14:19:21 2016 +
iscsi: add support for getting CHAP password via QCryptoSecret API
The existing 'password' option is overdue for
This deprecates the -iscsi clear text 'password' option
and deletes the previously deprecated -spice 'password'
option.
Daniel P. Berrangé (3):
block: mention 'password-secret' option for -iscsi
block: deprecate iSCSI 'password' in favour of 'password-secret'
ui: remove deprecated
Hello,
Yeah that's how the kubevirt-dev mailing list works - or is supposed to
work - as well. Emails from non-members are pending until manually
approved. I don't see anything pending though so we have an issue there.
Perhaps the mechanism in googlegroups is being thrown off by the inclusion
of a
On Wed, Nov 30, 2022 at 09:47:02AM +0100, Peter Krempa wrote:
> On Tue, Nov 29, 2022 at 09:05:33 -0800, Andrea Bolognani wrote:
>
> [...]
>
> > Proposal
> >
> >
> > In order to address the issues outlined above, I propose that we
> > introduce a new set of APIs in libvirt.
> >
> >
The 8.10.0 release of both libvirt and libvirt-python is tagged and
signed tarballs and source RPMs are available at
https://libvirt.org/sources/
https://libvirt.org/sources/python/
Thanks everybody who helped with this release by sending patches,
reviewing, testing, or providing
On Wed, Nov 30, 2022 at 11:48 AM Andrea Bolognani
wrote:
> On Tue, Nov 29, 2022 at 09:05:33AM -0800, Andrea Bolognani wrote:
> > Hi,
> >
> > this is a proposal for introducing a new family of APIs in libvirt,
> > with the goal of improving integration with management applications.
> >
> >
29 matches
Mail list logo