D-Bus API for multipath

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Currently higher level tools like PostgreSQL, OpenStack/Cinder, Cockpit,
Gnome Disk Utility, Gluster and Ceph don't have easy access to
information about multipath devices.  Providing higher level tools the
ability to visually display/understand multipath setup and health would
be a big help.

Tools currently need to parse the output of the CLI to determine the
mapping from a /dev/mapper/xx to the corresponding /dev/sdxx.  Parsing
CLI output is prone to problems and can be brittle over time.  It also
doesn't deal well with state updates as clients need to poll for changes.

D-Bus is the most common IPC mechanism for the expected consumers of the
API.  D-bus also provides fine granularity of API access security, which
will be more important when configuration change functionality is
introduced into the API.

Proposed Initial Features of D-Bus API:

- Read only attributes and relationships for map, path group and path
- Read only attributes of multipath (blacklist, friendly names etc)
- Signals for path properties (failure, restore)
- Signals for map properties failure (failure, restore, policy change)

Subsequent phases could include the ability to setup and manage features
of multipath.

My impression is this should be done as an extension to the multipathd.
 The d-bus interface could be disabled by default and enabled with a
change to the .conf file setting.

Other approaches may be possible, such the addition of an API to
libmultipath, and accessing that with a some other daemon, like
storaged, but that sort of thing would be less direct than doing it in
multipathd.  An additional API to libmultipath also doesn't solve event
driven state updates in a language agnostic way.

There is also an existing socket into multipathd and that solves some
issues, but raises others.  Talking over a socket home-brewed protocol
requires clients to write code to parsing/marshaling, re-invent
security etc.

I am looking for feedback on this before I get started on an
implementation. Do you agree that a D-Bus interface for multipaththd is
is the most appropriate approach to this problem?

--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel



[Index of Archives]     [DM Crypt]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite Discussion]     [KDE Users]     [Fedora Docs]

  Powered by Linux