On 1/29/19 5:18 AM, Michal Privoznik wrote: > On 1/16/19 2:15 AM, John Ferlan wrote: >> https://bugzilla.redhat.com/show_bug.cgi?id=1581670 >> >> Add the Storage Pool and Volume API's defined for each generated >> capability output, such as: >> >> <pool> >> <type>dir</pool> >> <poolapis> >> <buildPool/> >> <refreshPool/> >> <deletePool/> >> </poolapis> >> <volapis> >> <buildVol/> >> <buildVolFrom/> >> <createVol/> >> <refreshVol/> >> <deleteVol/> >> <resizeVol/> >> <uploadVol/> >> <downloadVol/> >> <wipeVol/> >> </volapis> >> </pool> >> >> ... >> >> <pool> >> <type>iscsi</pool> >> <poolapis> >> <findPoolSources/> >> <startPool/> >> <refreshPool/> >> <stopPool/> >> </poolapis> >> <volapis> >> <uploadVol/> >> <downloadVol/> >> <wipeVol/> >> </volapis> >> </pool> > > Frankly, I don't like this. Firstly, our users don't see 'uploadVol' > they see 'virStorageVolUpload'. Secondly, I am not sure if we want to be > introspectable this much. I mean, our users can just call the API and > deal with VIR_ERR_NO_SUPPORT. This looks like an overkill to me. > That's fine - hence the reason for separation. I guess I was thinking that developers may like to know what API's are supported by each pool - kind of a "features" list of sorts. Using the backend naming scheme is/was kind of a cheat. I'm not against being more creative - ideas are welcome ;-). I think most important is perhaps knowing what volume operations a pool supports or at least the upload/download, wipe, and resize. Without any kind of extra data, the output is kind of boring: <capabilities> <pool> <type>dir</pool> </pool> <pool> <type>fs</pool> </pool> <pool> <type>netfs</pool> </pool> .... <pool> <type>zfs</pool> </pool> </capabilities> John -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
