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

[Balamurugan Arumugam]

----- Original Message -----
> From: "Jeff Darcy" <jdarcy at redhat.com>
> To: "Balamurugan Arumugam" <bala at gluster.com>
> Cc: "Justin Clift" <justin at gluster.org>, gluster-users at gluster.org, "Gluster Devel" <gluster-devel at gluster.org>
> Sent: Thursday, September 11, 2014 7:45:52 PM
> Subject: Re: [Gluster-users] [Gluster-devel] Proposal for GlusterD-2.0
> 
> > 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.
> 

Salt has a way to push events to salt-master from salt-minions.  At salt-master, we would extend reactor[1] to handle such (any) events.  This helps to solve (1).


Regards,
Bala

[1] http://docs.saltstack.com/en/latest/topics/reactor/