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). The LED state conversation had people sitting on both sides of the fence on this one, there wasn't a clear winner. Gregory mentioned a hybrid option in a conversation we had this week: Implement first in Calamari, then consider migrating the feature into the Ceph source itself if users communicate that they want it there (the LED state might move for its debugging utility, whereas the SMART poll could stay in Calamari, for example). Thoughts? Joe -- 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
