I was away on a small vacation last week, so I haven't been able to
reply to this thread till now.
There has been quite some discussion while I was away. This kind of
discussion was exactly what we wanted.
I've read through the thread, and I'd like to summarize what I feel is
the general feeling
On 15/09/2014, at 8:19 PM, Kaushal M wrote:
snip
For the present we (GlusterD maintainers, KP and me, and other
GlusterD contributers) would like to start off GlusterD-2.0 by using
Consul for membership and config storage. The initial implementation
would probably only just have the minimum
Parthasarathi
Cc: Gluster Devel; gluster-us...@gluster.org; Balamurugan Arumugam
Subject: Re: [Gluster-users] [Gluster-devel] Proposal for GlusterD-2.0
On Fri, Sep 12, 2014 at 12:02 AM, Krishnan Parthasarathi kpart...@redhat.com
wrote:
- Original Message -
On Thu, Sep 11, 2014 at 4:55 AM
, September 12, 2014 5:58 PM
To: James; Krishnan Parthasarathi
Cc: Balamurugan Arumugam; gluster-us...@gluster.org; Gluster Devel
Subject: Re: [Gluster-users] [Gluster-devel] Proposal for GlusterD-2.0
Has anyone looked into whether LogCabin can provide the consistent small
storage based on RAFT
] [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
Has anyone looked into whether LogCabin can provide the consistent small
storage based on RAFT for Gluster?
https://github.com/logcabin/logcabin
I have no experience with using it so I cannot say if it is good or suitable.
I do know the following project uses it and it's just not as
Sent: Thursday, September 11, 2014 7:33:52 AM
Subject: Re: [Gluster-users] [Gluster-devel] Proposal for GlusterD-2.0
On 11/09/2014, at 2:46 AM, Balamurugan Arumugam wrote:
snip
WRT glusterd problem, I see Salt already resolves most of them at
infrastructure level. Its worth
- Original Message -
From: Krishnan Parthasarathi kpart...@redhat.com
To: Balamurugan Arumugam barum...@redhat.com
Cc: gluster-us...@gluster.org, Gluster Devel gluster-devel@gluster.org
Sent: Thursday, September 11, 2014 2:25:45 PM
Subject: Re: [Gluster-users] [Gluster-devel
On 11/09/2014, at 10:16 AM, Balamurugan Arumugam wrote:
snip
For distributed store, I would think of MongoDB which provides
distributed/replicated/highly available/master read-write/slave read-only
database. Lets get what community think about SaltStack and/or MongoDB.
Is this relevant for
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
I'm so glad to read this. I was thinking the same thing.
On Sep 11, 2014, at 7:22 AM, Jeff Darcy jda...@redhat.com wrote:
For distributed store, I would think of MongoDB which provides
distributed/replicated/highly available/master read-write/slave read-only
database. Lets get what community
On 11/09/2014, at 2:46 AM, Balamurugan Arumugam wrote:
snip
WRT glusterd problem, I see Salt already resolves most of them at
infrastructure level. Its worth considering it.
Salt used to have (~12 months ago) a reputation for being really
buggy. Any idea if that's still the case?
Apart
] [Gluster-devel] Proposal for GlusterD-2.0
On 11/09/2014, at 2:46 AM, Balamurugan Arumugam wrote:
snip
WRT glusterd problem, I see Salt already resolves most of them at
infrastructure level. Its worth considering it.
Salt used to have (~12 months ago) a reputation for being really
buggy
Is there any reason not to consider zookeeper?
I did bring up that idea a while ago. I'm no Java fan myself, but still
I was surprised by the vehemence of the reactions. To put it politely,
many seemed to consider the dependency on Java unacceptable for both
resource and security reasons.
That's disappointing. I can certainly understand wanting to keep dependencies
small, but that sounds like FUD more than a reasoned argument.
I do not envy your position navigating such waters.
On Sep 8, 2014, at 2:38 PM, Jeff Darcy jda...@redhat.com wrote:
Is there any reason not to consider
Is there any reason not to consider zookeeper? The 3.4 release is
quite stable and due to a large number of users, bugs are fixed and
its quirks are known.
I like the idea of RAFT. The paper is well written and very
compelling. The last time I read it, a number of critical issues were
glossed
Bulk of current GlusterD code deals with keeping the configuration of the
cluster and the volumes in it consistent and available across the nodes. The
current algorithm is not scalable (N^2 in no. of nodes) and doesn't prevent
split-brain of configuration. This is the problem area we are
- Original Message -
As part of the first phase, we aim to delegate the distributed
configuration
store. We are exploring consul [1] as a replacement for the existing
distributed configuration store (sum total of /var/lib/glusterd/* across
all
nodes). Consul provides
On 09/05/2014 03:51 PM, Kaushal M wrote:
GlusterD performs the following functions as the management daemon for
GlusterFS:
- Peer membership management
- Maintains consistency of configuration data across nodes
(distributed configuration store)
- Distributed command execution (orchestration)
On 09/06/2014 05:55 PM, Pranith Kumar Karampuri wrote:
On 09/05/2014 03:51 PM, Kaushal M wrote:
GlusterD performs the following functions as the management daemon for
GlusterFS:
- Peer membership management
- Maintains consistency of configuration data across nodes
(distributed
On 05/09/2014, at 11:21 AM, Kaushal M wrote:
snip
As part of the first phase, we aim to delegate the distributed configuration
store. We are exploring consul [1]
Does this mean we'll need to learn Go as well as C and Python?
If so, that doesn't sound completely optimal. :/
That being said,
On 5 Sep 2014, at 12:21, Kaushal M kshlms...@gmail.com wrote:
- Peer membership management
- Maintains consistency of configuration data across nodes (distributed
configuration store)
- Distributed command execution (orchestration)
- Service management (manage GlusterFS daemons)
- Portmap
- Original Message -
On 05/09/2014, at 11:21 AM, Kaushal M wrote:
snip
As part of the first phase, we aim to delegate the distributed
configuration store. We are exploring consul [1]
Does this mean we'll need to learn Go as well as C and Python?
If so, that doesn't sound
- Original Message -
On 5 Sep 2014, at 12:21, Kaushal M kshlms...@gmail.com wrote:
- Peer membership management
- Maintains consistency of configuration data across nodes (distributed
configuration store)
- Distributed command execution (orchestration)
- Service management
Isn't some of this covered by crm/corosync/pacemaker/heartbeat?
Sorta, kinda, mostly no. Those implement virtual synchrony, which is
closely related to consensus but not quite the same even in a formal CS
sense. In practice, using them is *very* different. Two jobs ago, I
inherited a design
25 matches
Mail list logo
