From: Todd Gill <tgill@redhat.com>
To: dm-devel@redhat.com
Subject: D-Bus API for multipath
Date: Tue, 01 Sep 2015 12:02:34 -0400 [thread overview]
Message-ID: <55E5CC1A.90002@redhat.com> (raw)
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?
reply other threads:[~2015-09-01 16:02 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55E5CC1A.90002@redhat.com \
--to=tgill@redhat.com \
--cc=dm-devel@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).