On Wed, 5 Nov 2014, Hunter Nield wrote:
> I concur with Dan on Consul. It's a great tool.
>
> We use Consul in our Ceph environments but only as a layer above an
> installed Ceph installation. Health checks (for the mons/osds
> processes and ceph health) and service discovery (for the
> apps/services that run in Docker containers on top). We've started on
> an alerting tool if anyone has use for it -
> https://github.com/AcalephStorage/consul-alerts
>
> There is definitely some overlap on the cluster consensus side (Paxos
> vs Raft) and would be nice to reduce another moving part in our
> cluster but I would imagine the projects are too different internally
> to really combine the two of them.
>
> The one thing that we'd wished for in Ceph before Consul existed was
> an easily accessible distributed KV store. Ceph has parts of it but
> exposing something like that with an easy CLI/REST API might provide
> the primitives for building higher level functionality that Consul
> provides. More than likely a distraction though since Consul does such
> a good job now.
Have you seen the kv storage service provided by the mons? It's pretty
basic but is intended for stashing arbitrary config data. The original
use-case we wanted it for was storing the encryption keys for dm-cypt (you
can restrict individual ceph entities to a subset of the config-key
namespace), but we never got around to finishing that work (dm-crypt keys
are still stored in /etc/ceph/keys/ on the local node until we find a
vocal user with clear requirements).
config-key del <key> delete <key>
config-key exists <key> check for <key>'s existence
config-key get <key> get <key>
config-key list list keys
config-key put <key> {<val>} put <key>, value <val>
sage
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
