[libvirt PATCH] docs: virConnectGetCapabilities do not provide pool types
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@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
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@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@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
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@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@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
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 :|
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
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 :|
participants (3)
-
Daniel P. Berrangé -
John Ferlan -
Pino Toscano