[libvirt] Storage Backend Error Handling Consistency
Roman Bogorodskiy
bogorodskiy at gmail.com
Sat Mar 5 15:09:17 UTC 2016
Richard Laager wrote:
> These two blocks exist in different storage backends' createVol
> implementations:
>
> if (vol->target.format != VIR_STORAGE_FILE_RAW) {
> virReportError(VIR_ERR_NO_SUPPORT, "%s",
> _("only RAW volumes are supported by this storage pool"));
> return -VIR_ERR_NO_SUPPORT;
> }
>
> if (vol->target.encryption != NULL) {
> virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
> "%s", _("storage pool does not support encrypted "
> "volumes"));
> return -1;
> }
>
> My hunch is that the second example (VIR_ERR_CONFIG_UNSUPPORTED and
> returning -1) is correct in both of these cases.
I think the second example is more correct and
VIR_ERR_CONFIG_UNSUPPORTED should be used is such cases, because
VIR_ERR_NO_SUPPORT is supposed to mean a function unsupported by the
driver itself, not a situation when a user is requesting some
configuration that is not possible.
> Related... Which backends should be restricted to only raw? That code
> is from storage_backend_rbd.c, which seems to be the only one
> restricted in that way. But does it make sense to allow !raw on LVM (or
> ZFS), for example?
As for ZFS, I don't see how non-raw could be used. I didn't add a check
for that because I just did not think about that. Not sure about the
other backends though.
> Whatever the correct answer, I'm looking to submit one or more patches.
>
> --
> Richard
>
> --
> libvir-list mailing list
> libvir-list at redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list
Roman Bogorodskiy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20160305/3a538856/attachment-0001.sig>
More information about the libvir-list
mailing list