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@xxxxxxx +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)
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
