[PATCH] Added attach-disk parameters for network disk support

[Peter Krempa]

On Thu, Nov 12, 2020 at 15:15:27 -0600, Ryan Gahagan wrote:
> Hey Peter,

Hi Ryan,

firstly I'd like to ask you to keep the conversation on-list. (use
reply-all all the time). This ensures that the response is public and
also other people can jump in and respont. At the very least it can be
used for future reference.

I'll be re-adding the mailing list in this response.

Also please avoid top-posting in techincal lists. It's always best to
respond inline at the proper context that is being discussed.

> Sorry about all the issues with our commit, we're new to this and trying to
> make our first contribution to this repo. We had a couple questions over
> your feedback and wanted to run them by you before making another request.

Sure thing, you can always ask on the mailing list even without patches.

> In the original code, the --source parameter is marked as required but okay
> to be empty. If the string is empty, then we think the parameter read in by
> vshCommandOptStringReq would be NULL, in which case no <source> tag would
> be generated at all. If this is the case, then why is --source required in
> the first place? We see that --source-name is mutually exclusive witha

That's a quirk of it being a positional argument (VSH_OT_DATA). A
positional argument is mandatory.

> --source, but is it also okay to be empty? For example, in the issue
> <https://gitlab.com/libvirt/libvirt/-/issues/16> this patch was based on,
> there's an example XML which has a <source> with neither a file nor a name.
> Is this example incorrect, or is it fine to have neither and only have a
> protocol?

That is correct for example with the NBD protocol where a missing name
actually means the default unnamed export.

The thing is that we can't really change --source to be something else
than VSH_OT_DATA since it would change the semantics of the virsh
command.

You probably will need to use it also for the 'name' attribute and
switch the name according to the presence of the 'protocol'
attribute/option.

> When it comes to making these mutually exclusive, we also were confused on
> what flags to give them. Would it be proper behavior to give them both no
> flags or only the VSH_OFLAG_EMPTY_OK flag and then check that one is
> defined in the cmdAttachDisk method (using VSH_EXCLUSIVE_OPTIONS_VAR) and
> error there instead?

Those are two separate things. If it makes sense for a flag to be
specified but empty and it impacts behaviour then you need to use
VSH_OFLAG_EMPTY_OK.

Any non-positional arguments (those which need --) can be made optional.

On the other hand that does not say anything about how they can or can't
be combined with other options and thus you need to declare that in the
code.

> If the user provides an empty source without any protocol, but provides
> --source-host-* parameters, what should be generated instead? Would this

This should be an error. --source-host must require the use of
--source-protocol

> cause an error, would it generate an in-line <host> tag, or would it
> generate a completely empty <source> tag followed by the host information?

The protocol option flag should be mandatory if you want to use the
host/socket.


> 
> -Ryan Gahagan
> 
> On Thu, Nov 12, 2020 at 2:57 AM Peter Krempa <pkrempa at redhat.com> wrote:
> 
> > On Wed, Nov 11, 2020 at 17:00:51 -0600, Ryan Gahagan wrote:
> > > Related issue: https://gitlab.com/libvirt/libvirt/-/issues/16
> > > Added in support for the following parameters in attach-disk:
> > > --source-name
> > > --source-protocol
> > > --source-host-name
> > > --source-host-socket
> > > --source-host-transport

Please trim parts of the message that are no longer relevant.

[...]