[Gluster-users] [Gluster-devel] Proposal for GlusterD-2.0

[Jeff Darcy]

> Yes.  I came across Salt currently for unified management for storage to
> manage gluster and ceph which is still in planning phase.  I could think of
> a complete requirement of infra requirement to solve from glusterd to
> unified management.  Calamari ceph management already uses Salt.  It would
> be the ideal solution with Salt (or any infra) if gluster, ceph and unified
> management uses.


I think the idea of using Salt (or similar) is interesting, but it's also
key that Ceph still has its mon cluster as well.  (Is "mon calamari" an
*intentional* Star Wars reference?)  As I see it, glusterd or anything we
use to replacement has multiple responsibilities:

(1) Track the current up/down state of cluster members and resources.

(2) Store configuration and coordinate changes to it.

(3) Orchestrate complex or long-running activities (e.g. rebalance).

(4) Provide service discovery (current portmapper).

Salt and its friends clearly shine at (2) and (3), though they "outsource"
the actual data storage to an external data store.  With such a data
store, (4) becomes pretty trivial.  The sticking point for me is (1).  How
does Salt handle that need, or how might it be satisfied on top of the
facilities Salt does provide?  I can see *very* clearly how to do it on
top of etcd or consul.  Could those in fact be used for Salt's data store?
It seems like Salt shouldn't need a full-fledged industrial strength
database, just something with high consistency/availability and some basic
semantics.

Maybe we should try to engage with the Salt developers to come up with
ideas.  Or find out exactly what functionality they found still needs to
be in the mon cluster and not in Salt.