2:50 a.m.
Remove the paragraph in the storage pool page that mentions
virConnectGetCapabilities, as virConnectGetCapabilities does not return
any information about pools.
Signed-off-by: Pino Toscano <ptoscano(a)redhat.com>
---
docs/formatstoragecaps.html.in | 6 ------
1 file changed, 6 deletions(-)
diff --git a/docs/formatstoragecaps.html.in b/docs/formatstoragecaps.html.in
index ee3888f44d..d8a1cacd96 100644
--- a/docs/formatstoragecaps.html.in
+++ b/docs/formatstoragecaps.html.in
@@ -13,12 +13,6 @@
supported, and if relevant the source format types, the required
source elements, and the target volume format types. </p>
- <p>The Storage Pool Capabilities XML provides more information than the
- <a
href="/html/libvirt-libvirt-host.html#virConnectGetCapabilities">
- <code>virConnectGetCapabilities</code>
- </a>
- which only provides an enumerated list of supported pool types.</p>
-
<h2><a id="elements">Element and attribute
overview</a></h2>
<p>A query interface was added to the virConnect API's to retrieve the
--
2.26.2
12:31 p.m.
On 7/20/20 3:50 AM, Pino Toscano wrote:
Remove the paragraph in the storage pool page that mentions
virConnectGetCapabilities, as virConnectGetCapabilities does not return
any information about pools.
Signed-off-by: Pino Toscano <ptoscano(a)redhat.com>
---
docs/formatstoragecaps.html.in | 6 ------
1 file changed, 6 deletions(-)
I was asked by Pino to review to be "ok" with removal, so yeah:
Reviewed-by: John Ferlan <jferlan(a)redhat.com>
John
If anyone cares to dredge up history back in Jan/Feb 2019 I believe it
was a true statement in at least a patches I had locally, but reviews,
conversations, and other adjustments to the code changed that. Been too
long to recall all those details.
diff --git a/docs/formatstoragecaps.html.in
b/docs/formatstoragecaps.html.in
index ee3888f44d..d8a1cacd96 100644
--- a/docs/formatstoragecaps.html.in
+++ b/docs/formatstoragecaps.html.in
@@ -13,12 +13,6 @@
supported, and if relevant the source format types, the required
source elements, and the target volume format types. </p>
- <p>The Storage Pool Capabilities XML provides more information than the
- <a
href="/html/libvirt-libvirt-host.html#virConnectGetCapabilities">
- <code>virConnectGetCapabilities</code>
- </a>
- which only provides an enumerated list of supported pool types.</p>
-
<h2><a id="elements">Element and attribute
overview</a></h2>
<p>A query interface was added to the virConnect API's to retrieve the
7:46 a.m.
Upon further reflection and some memory jiggling...
virsh -c storage:///system capabilities
<capabilities>
<pool>
<enum name='type'>
<value>dir</value>
<value>fs</value>
<value>netfs</value>
<value>logical</value>
<value>iscsi</value>
<value>iscsi-direct</value>
<value>scsi</value>
<value>mpath</value>
<value>disk</value>
<value>rbd</value>
<value>sheepdog</value>
<value>gluster</value>
<value>zfs</value>
</enum>
</pool>
</capabilities>
But yeah, without the -c storage:///system one won't see the results
because 'npools == 0' when virCapabilitiesFormatStoragePoolXML is called
from virCapabilitiesFormatXML unless it's the storage driver URI.
John
On 7/20/20 1:31 PM, John Ferlan wrote:
On 7/20/20 3:50 AM, Pino Toscano wrote:
> Remove the paragraph in the storage pool page that mentions
> virConnectGetCapabilities, as virConnectGetCapabilities does not return
> any information about pools.
>
> Signed-off-by: Pino Toscano <ptoscano(a)redhat.com>
> ---
> docs/formatstoragecaps.html.in | 6 ------
> 1 file changed, 6 deletions(-)
>
I was asked by Pino to review to be "ok" with removal, so yeah:
Reviewed-by: John Ferlan <jferlan(a)redhat.com>
John
If anyone cares to dredge up history back in Jan/Feb 2019 I believe it
was a true statement in at least a patches I had locally, but reviews,
conversations, and other adjustments to the code changed that. Been too
long to recall all those details.
> diff --git a/docs/formatstoragecaps.html.in b/docs/formatstoragecaps.html.in
> index ee3888f44d..d8a1cacd96 100644
> --- a/docs/formatstoragecaps.html.in
> +++ b/docs/formatstoragecaps.html.in
> @@ -13,12 +13,6 @@
> supported, and if relevant the source format types, the required
> source elements, and the target volume format types. </p>
>
> - <p>The Storage Pool Capabilities XML provides more information than the
> - <a
href="/html/libvirt-libvirt-host.html#virConnectGetCapabilities">
> - <code>virConnectGetCapabilities</code>
> - </a>
> - which only provides an enumerated list of supported pool types.</p>
> -
> <h2><a id="elements">Element and attribute
overview</a></h2>
>
> <p>A query interface was added to the virConnect API's to retrieve
the
>
9:14 a.m.
On Tue, Jul 21, 2020 at 08:46:55AM -0400, John Ferlan wrote:
Upon further reflection and some memory jiggling...
virsh -c storage:///system capabilities
<capabilities>
<pool>
<enum name='type'>
<value>dir</value>
<value>fs</value>
<value>netfs</value>
<value>logical</value>
<value>iscsi</value>
<value>iscsi-direct</value>
<value>scsi</value>
<value>mpath</value>
<value>disk</value>
<value>rbd</value>
<value>sheepdog</value>
<value>gluster</value>
<value>zfs</value>
</enum>
</pool>
</capabilities>
But yeah, without the -c storage:///system one won't see the results
because 'npools == 0' when virCapabilitiesFormatStoragePoolXML is called
from virCapabilitiesFormatXML unless it's the storage driver URI.
Err, don't you mean "virsh pool-capabilities".
The "capabilities" command is exclusively for the virt driver usage,
not storage.
In the new modular daemon work, "capabilities" API will never be
sent to the storage daemon.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
2:23 p.m.
On 7/21/20 10:14 AM, Daniel P. Berrangé wrote:
On Tue, Jul 21, 2020 at 08:46:55AM -0400, John Ferlan wrote:
>
> Upon further reflection and some memory jiggling...
>
> virsh -c storage:///system capabilities
> <capabilities>
>
> <pool>
> <enum name='type'>
> <value>dir</value>
> <value>fs</value>
> <value>netfs</value>
> <value>logical</value>
> <value>iscsi</value>
> <value>iscsi-direct</value>
> <value>scsi</value>
> <value>mpath</value>
> <value>disk</value>
> <value>rbd</value>
> <value>sheepdog</value>
> <value>gluster</value>
> <value>zfs</value>
> </enum>
> </pool>
>
> </capabilities>
>
> But yeah, without the -c storage:///system one won't see the results
> because 'npools == 0' when virCapabilitiesFormatStoragePoolXML is called
> from virCapabilitiesFormatXML unless it's the storage driver URI.
Err, don't you mean "virsh pool-capabilities".
pool-capabilities takes a different path ending in
virStoragePoolCapsFormat as opposed to capabilities which ends up in
virCapabilitiesFormatXML
The "capabilities" command is exclusively for the virt
driver usage,
not storage.
# virsh version
Compiled against library: libvirt 6.6.0
Using library: libvirt 6.6.0
Using API: QEMU 6.6.0
Running hypervisor: QEMU 5.0.50
# virsh -c storage:///system capabilities
[as above]
This work is/was done Jan/Feb 2019 - Perhaps I'm only getting asked
(again) about it now as a result of some downstream documenting :-/. Far
too long ago for me to recall why both options were done.
But separable enough in commit 05fe03505a to be undone.
John
In the new modular daemon work, "capabilities" API will never be
sent to the storage daemon.
Regards,
Daniel
4:08 a.m.
On Tue, Jul 21, 2020 at 03:23:24PM -0400, John Ferlan wrote:
On 7/21/20 10:14 AM, Daniel P. Berrangé wrote:
> On Tue, Jul 21, 2020 at 08:46:55AM -0400, John Ferlan wrote:
>>
>> Upon further reflection and some memory jiggling...
>>
>> virsh -c storage:///system capabilities
>> <capabilities>
>>
>> <pool>
>> <enum name='type'>
>> <value>dir</value>
>> <value>fs</value>
>> <value>netfs</value>
>> <value>logical</value>
>> <value>iscsi</value>
>> <value>iscsi-direct</value>
>> <value>scsi</value>
>> <value>mpath</value>
>> <value>disk</value>
>> <value>rbd</value>
>> <value>sheepdog</value>
>> <value>gluster</value>
>> <value>zfs</value>
>> </enum>
>> </pool>
>>
>> </capabilities>
>>
>> But yeah, without the -c storage:///system one won't see the results
>> because 'npools == 0' when virCapabilitiesFormatStoragePoolXML is
called
>> from virCapabilitiesFormatXML unless it's the storage driver URI.
>
> Err, don't you mean "virsh pool-capabilities".
>
pool-capabilities takes a different path ending in
virStoragePoolCapsFormat as opposed to capabilities which ends up in
virCapabilitiesFormatXML
> The "capabilities" command is exclusively for the virt driver usage,
> not storage.
# virsh version
Compiled against library: libvirt 6.6.0
Using library: libvirt 6.6.0
Using API: QEMU 6.6.0
Running hypervisor: QEMU 5.0.50
# virsh -c storage:///system capabilities
[as above]
This work is/was done Jan/Feb 2019 - Perhaps I'm only getting asked
(again) about it now as a result of some downstream documenting :-/. Far
too long ago for me to recall why both options were done.
But separable enough in commit 05fe03505a to be undone.
Ohh, that's bizarre. I don't see the point in reporting the storage
stuff in "capabilities", as it is a subset of what you're reporting
in "pool-capabilities".
We certainly shouldn't encourage anyone to use the "capabilities"
stuff for storage, so any docs should direct people to "pool-capabilities"
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
1584
days inactive
1586
days old
5 comments
3 participants
participants (3)
-
Daniel P. Berrangé -
John Ferlan -
Pino Toscano