[dm-devel] [PATCH] Introducing multipath C API <libdmmp/libdmmp.h>

[Hannes Reinecke]

On 02/01/2016 02:13 PM, Todd Gill wrote:
> On 01/28/2016 04:15 AM, Hannes Reinecke wrote:
>>
>> I would very much advocate to use the IPC interface into multipathd;
>> we can easily define a stable ABI for that.
>
> Do you have a preference for the format of the API?
>
> Are you thinking JSON, JSON-RPC, YAML, XML, XML-RPC?
>
> The user of the API would write a command to the netlink socket that
> multiapthd already listens? the command would be something like:
>
> multipathd show map topology JSON
>
> Just looking to confirm I understand.
>
Yes, something like that should work.

>> ATM it's just being use for the userland CLI, and hence it'll return
>> human-readable output. But I don't have any issues to define a
>> machine-readable output, too, so that it can be easily parsed from
>> other programs.
>
> I've abandoned the approach of putting a d-bus thread in multipathd.
> But, I'm still hoping to help higher level tools understand the
> multipath picture (and help users manage/monitor it).
>
Oh, I'm not doubting that some sort of multipathd interaction with other 
processes is useful.

The point I'm advocating is that we should centralize the information
on the existing multipath daemon, as this is the instance which is 
ultimatively responsible for correct multipath operation.
As the daemon carries quite some dynamic information it doesn't help if 
this information is constructed outside of the daemon; it might be
(and occasionally is) different from the information the daemon is using 
internally.

So yes, we do need some sort of query mechanism, but that should
be done by using the multipath daemon IPC mechanism.

Adding a 'format' specifier is a good starting point for that.
Plus you can add several format options if required.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare at suse.de			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)