On 15/09/2014, at 8:19 PM, Kaushal M wrote:
> 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 clu
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 s
"it also has Zookeeper support etc." - just to correct this and remove the
perception that LogCabin somehow requires Zookeeper or works with it.
LogCabin as I understand is the C++ implementation of a small store based on
the Raft consensus protocol - to provide a consistent and a small distribu
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 easy to set
> 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
- Original Message -
> From: "Jeff Darcy"
> To: "Balamurugan Arumugam"
> Cc: "Justin Clift" , gluster-us...@gluster.org, "Gluster
> Devel"
> Sent: Thursday, September 11, 2014 7:45:52 PM
> Subject: Re: [Gluster-users] [Gluster-devel] Proposal for GlusterD-2.0
>
> > Yes. I came acros
- Original Message -
> From: "Jeff Darcy"
> To: "Balamurugan Arumugam"
> Cc: "Justin Clift" , gluster-us...@gluster.org, "Gluster
> Devel"
> Sent: Thursday, September 11, 2014 7:45:52 PM
> Subject: Re: [Gluster-users] [Gluster-devel] Proposal for GlusterD-2.0
>
> > Yes. I came acros
On Fri, Sep 12, 2014 at 12:02 AM, Krishnan Parthasarathi
wrote:
> - Original Message -
>> On Thu, Sep 11, 2014 at 4:55 AM, Krishnan Parthasarathi
>> wrote:
>> >
>> > I think using Salt as the orchestration framework is a good idea.
>> > We would still need to have a consistent distributed
- Original Message -
> On Thu, Sep 11, 2014 at 4:55 AM, Krishnan Parthasarathi
> wrote:
> >
> > I think using Salt as the orchestration framework is a good idea.
> > We would still need to have a consistent distributed store. I hope
> > Salt has the provision to use one of our choice. It c
On Thu, Sep 11, 2014 at 12:01 PM, Prasad, Nirmal wrote:
> I really hope whatever the outcome and final choice is ... as an end user I
> hope that Gluster stays as simple to deploy as it is today.
I think it's pretty simple already with puppet-gluster. It takes me
around 15 minutes while I'm off
On Thu, Sep 11, 2014 at 4:55 AM, Krishnan Parthasarathi
wrote:
>
> I think using Salt as the orchestration framework is a good idea.
> We would still need to have a consistent distributed store. I hope
> Salt has the provision to use one of our choice. It could be consul
> or something that satisf
I'm so glad to read this. I was thinking the same thing.
On Sep 11, 2014, at 7:22 AM, Jeff Darcy 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 think about
> 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.
I definitely do not think MongoDB is the right tool for this job. I'm
not one of
> 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 wou
- Original Message -
> From: "Justin Clift"
> To: "Balamurugan Arumugam"
> Cc: "Krishnan Parthasarathi" ,
> gluster-us...@gluster.org, "Gluster Devel"
>
> Sent: Thursday, September 11, 2014 2:48:41 PM
> Subject: Re: [Glus
- Original Message -
> From: "Justin Clift"
> To: "Balamurugan Arumugam"
> Cc: "Krishnan Parthasarathi" ,
> gluster-us...@gluster.org, "Gluster Devel"
>
> Sent: Thursday, September 11, 2014 2:48:41 PM
> Subject: Re: [Glus
On 11/09/2014, at 10:16 AM, Balamurugan Arumugam 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 think about SaltStack and/or MongoDB.
Is this relevant for M
- Original Message -
> From: "Krishnan Parthasarathi"
> To: "Balamurugan Arumugam"
> Cc: gluster-us...@gluster.org, "Gluster Devel"
> Sent: Thursday, September 11, 2014 2:25:45 PM
> Subject: Re: [Gluster-users] [Gluster-devel] Proposal for GlusterD-2.0
>
> Bala,
>
> I think using Sal
Bala,
I think using Salt as the orchestration framework is a good idea.
We would still need to have a consistent distributed store. I hope
Salt has the provision to use one of our choice. It could be consul
or something that satisfies the criteria for choosing alternate technology.
I would wait f
- Original Message -
> From: "Justin Clift"
> To: "Balamurugan Arumugam"
> Cc: "Kaushal M" , gluster-us...@gluster.org, "Gluster
> Devel"
> 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:4
- Original Message -
> From: "Justin Clift"
> To: "Balamurugan Arumugam"
> Cc: "Kaushal M" , gluster-us...@gluster.org, "Gluster
> Devel"
> 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:4
On 11/09/2014, at 2:46 AM, Balamurugan Arumugam wrote:
> 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 from t
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 wrote:
>> Is there any reason not to consider zookeeper?
>
>
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 over
> 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. Som
On 8 September 2014 05:05, Krishnan Parthasarathi
wrote:
>
>
> > 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
> p
- 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 provid
> 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
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
>> (distribute
Justin Clift wrote:
> Does this mean we'll need to learn Go as well as C and Python?
> If so, that doesn't sound completely optimal. :/
I agree with that. Fancy new languages are cool and full of nice
features, but they reduce the amount of possible contributors. If you
feel you have too many st
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)
> 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, a lot of distributed/networked computing
> projects seem to be written in it these days. Is Go specifically
> a good language for our kind of challenges, or is
> 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 b
- 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 m
- Original Message -
> On 05/09/2014, at 11:21 AM, Kaushal M wrote:
>
> > 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
On 5 Sep 2014, at 12:21, Kaushal M wrote:
> - Peer membership management
> - Maintains consistency of configuration data across nodes (distributed
> configuration store)
> - Distributed command execution (orchestration)
> - Service management (manage GlusterFS daemons)
> - Portmap service for Gl
On 05/09/2014, at 11:21 AM, Kaushal M wrote:
> 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, a l
37 matches
Mail list logo
