[libvirt PATCH] docs: virConnectGetCapabilities do not provide pool types

Pino Toscano posted 1 patch 3 years, 8 months ago
Test syntax-check failed
Patches applied successfully (tree, apply log)
git fetch https://github.com/patchew-project/libvirt tags/patchew/20200720075031.2964943-1-ptoscano@redhat.com
docs/formatstoragecaps.html.in | 6 ------
1 file changed, 6 deletions(-)
[libvirt PATCH] docs: virConnectGetCapabilities do not provide pool types
Posted by Pino Toscano 3 years, 8 months ago
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

Re: [libvirt PATCH] docs: virConnectGetCapabilities do not provide pool types
Posted by John Ferlan 3 years, 8 months ago

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
> 

Re: [libvirt PATCH] docs: virConnectGetCapabilities do not provide pool types
Posted by John Ferlan 3 years, 8 months ago
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
>>
> 

Re: [libvirt PATCH] docs: virConnectGetCapabilities do not provide pool types
Posted by Daniel P. Berrangé 3 years, 8 months ago
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 :|

Re: [libvirt PATCH] docs: virConnectGetCapabilities do not provide pool types
Posted by John Ferlan 3 years, 8 months ago

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
> 

Re: [libvirt PATCH] docs: virConnectGetCapabilities do not provide pool types
Posted by Daniel P. Berrangé 3 years, 8 months ago
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 :|