[PATCH nvme-cli rfc] fabrics: support default connect/discover args

[james.smart@broadcom.com (James Smart)]

On 4/30/2019 12:34 AM, Sagi Grimberg wrote:
>
>>> Effectively yes, but defargs does not allow 
>>> transport,traddr,trsvcid,nqn
>>> parameters (which don't make sense), and discovery.conf is designed to
>>> hold exactly those. So in practice they should not overlap.
>>>
>> Uh-oh. I _do_ know of cases where discovery.conf is used for 
>> precisely this purpose, ie holding _all_ arguments.
>
> That's fine.. it was never designed for this purpose though...
>
>> And in the absense of any other way existing implementations will be 
>> using a very similar thing.
>
> Again, this would work.
>
>>> Also, we only go to discovery.conf if we did not get a transport+traddr
>>> (which are mandatory). So its not exactly the order you mentioned, more
>>> like:
>>>
>>> defargs.conf
>>> <cmdline>
>>> if transport+traddr not given
>>> discovery.conf
>>>
>> How very curious ...
>> I would have expected that any command-line args would overwrite any 
>> arguments given in the configuration files.
>> But given that discovery.conf can contain several lines I can see the 
>> problem.
>
> Exactly. discovery.conf was simply added such that you can run nvme
> connect-all without explicitly passing parameters so you can build
> auto-connect scripts on top of.

with my suggestion it would be:
 ?? <parse cmdline for connect addressing args>
 ?? if transport+traddr not given:? pull them from discovery.conf note: 
if non-addressing args present, remember them
 ?? parse addressing args vs connectargs.conf? (aka defargs.conf)
 ? <apply non-addressing args from discovery.conf>
 ? <apply cmdline non-addressing args>

-- james