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 :|
© 2016 - 2024 Red Hat, Inc.