Re: [Gluster-devel] Proposal for GlusterD-2.0

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




----- Original Message -----
> From: "Jeff Darcy" <jdarcy@xxxxxxxxxx>
> To: "Balamurugan Arumugam" <bala@xxxxxxxxxxx>
> Cc: "Justin Clift" <justin@xxxxxxxxxxx>, gluster-users@xxxxxxxxxxx, "Gluster Devel" <gluster-devel@xxxxxxxxxxx>
> Sent: Thursday, September 11, 2014 7:45:52 PM
> Subject: Re:  [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/
_______________________________________________
Gluster-users mailing list
Gluster-users@xxxxxxxxxxx
http://supercolony.gluster.org/mailman/listinfo/gluster-users




[Index of Archives]     [Gluster Development]     [Linux Filesytems Development]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux