On 26/06/2015 21:14, Handzik, Joe wrote:
Hey ceph-devel,
Gregory Meno (of Calamari fame) and I are working on what is now officially a blueprint for Jewel ( http://tracker.ceph.com/projects/ceph/wiki/Calamariapihardwarestorage ), and we'd like some feedback.
Some of this has been addressed via separate conversations about the feature that some of this work started out as (identifying drives in a cluster by toggling their LED states), but we wanted to ask a more direct question: What is the preferred location/mechanism to execute operations on storage hardware?
We see two clear options:
1. Make Calamari responsible for executing commands using various linux utilities (and /sys, when applicable).
2. Build a command set into RADOS to execute commands using various linux utilities. These commands could then be executed by Calamari using the rest api.
The big win for #1 is the ability to rapidly iterate on the capabilities of the Calamari toolset (it is almost certainly going to be faster to create a set of scripts similar to Gregory's initial commit for SMART polling than to add that functionality inside RADOS. See: https://github.com/ceph/calamari/pull/267 ). For #2, we'd pick up the ability to run those same commands via the cli, which would give users a lot more flexibility in how they troubleshoot their cluster (Calamari wouldn't be required, it would just make life easier).
Hi Joe,
I'd reiterate my earlier comments[1] in favour of option 2.
I would be cautious about implementing any of this in Calamari until
there are at least upstream packages available for folks to use, and
broader uptake. In the current situation, it's hard to ask people to
try something out in Calamari, and much more straightforward to
distribute something as part of Ceph. Hardware is pretty varied, I
would expect you'll need help from others in the community to ensure any
hardware handling works as expected in diverse environments, which will
be much simpler with ceph than calamari.
The part where some central python (calamari or otherwise) would really
come into its own is in the fusion of information from multiple hosts,
and exposing it to a user interface. On that aspect, I left some
comments last time this came up:
http://lists.ceph.com/pipermail/ceph-calamari-ceph.com/2015-May/000073.html
Ceph itself is getting a bit smarter with some of this stuff, e.g. the
new "node ls" stuff gives you metadata about hosts and services without
the need for calamari. Hanging device info off these new structures
would be a pretty reasonable thing to do, and if someone later has a GUI
that they want to pipe that into, they can grab it via the mon along
with everything else.
Cheers,
John
1. https://www.mail-archive.com/ceph-devel@xxxxxxxxxxxxxxx/msg23186.html
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
