Re: [Gluster-devel] AFR arbiter volumes

[Ravishankar N]

On 09/09/2015 08:36 AM, Nagaprasad Sathyanarayana wrote:

Thanks Ravi for nicely explaining this. A question on the following section;

"If 2 bricks are up and if one of them is the arbiter (i.e. the 3rd brick) and it 
blames the other up brick, then all FOPS will fail with ENOTCONN (Transport endpoint is 
not connected). If the arbiter doesn't blame the other brick, FOPS will be allowed to 
proceed. 'Blaming' here is w.r.t the values of AFR changelog extended attributes."

Q: under what circumstances arbiter brick does/does not blame the other brick?


Blaming is just the term used to indicate the state of AFR changelog 
xattrs. If a brick is down and a write/ modification FOP happens, then 
the bricks that are up 'blame' the one that is down using the these xattrs.


Thanks,
Ravi


Thanks
Naga


On 09-Sep-2015, at 7:17 am, Ravishankar N  wrote:

If 2 bricks are up and if one of them is the arbiter (i.e. the 3rd brick) and 
it blames the other up brick, then all FOPS will fail with ENOTCONN (Transport 
endpoint is not connected). If the arbiter doesn't blame the other brick, FOPS 
will be allowed to proceed. 'Blaming' here is w.r.t the values of AFR changelog 
extended attributes.


___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

[Gluster-devel] Reminder: Gluster weekly community meeting

[Humble Devassy Chirammal]

Hi All,

In about 15 minutes from now, we will have the regular weekly Gluster
Community meeting.

Meeting details:
- location: #gluster-meeting on Freenode IRC
- date: every Wednesday
- time: 12:00 UTC, 14:00 CEST, 17:30 IST
   (in your terminal, run: date -d "12:00 UTC")
- agenda: https://public.pad.fsfe.org/p/gluster-community-meetings

Currently the following items are listed:
* Roll Call
* Status of last week's action items
* Gluster 3.7
* Gluster 3.6
* Gluster 3.5
* Gluster 3.8
* Gluster 4.0
* Open Floor
   - bring your own topic!

The last topic has space for additions. If you have a suitable topic to
discuss, please add it to the agenda. See you on IRC in 30 minutes!

Thanks,
--Humble
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

[Gluster-devel] Minutes of the Weekly Gluster Community Meeting ( 9th Sep 2015)

[Humble Devassy Chirammal]

Hi All,

The minutes of today's meeting can be found at,

Minutes:
http://meetbot.fedoraproject.org/gluster-meeting/2015-09-09/gluster-meeting.2015-09-09-12.00.html
Minutes (text):
http://meetbot.fedoraproject.org/gluster-meeting/2015-09-09/gluster-meeting.2015-09-09-12.00.txt
 Log:
http://meetbot.fedoraproject.org/gluster-meeting/2015-09-09/gluster-meeting.2015-09-09-12.00.log.html

Meeting summary
---
* agenda is available @
  https://public.pad.fsfe.org/p/gluster-community-meetings  (hchiramm,
  12:01:43)
* roll call  (hchiramm, 12:04:49)

* Action items from last week:  (hchiramm, 12:05:17)

* msvbhat/rastar to send update mailing list with a DiSTAF how-to and
  start discussion on enhancements to DiSTAF  (hchiramm, 12:05:53)
  * LINK:
http://www.gluster.org/pipermail/gluster-devel/2015-September/046728.html
(anoopcs, 12:07:08)
  * LINK:
http://www.gluster.org/pipermail/gluster-devel/2015-September/046728.html
(hchiramm, 12:07:20)

* kshlm to check back with misc on the new jenkins slaves.  (hchiramm,
  12:08:57)

* krishnan_p to update Gluster News about Gluster.next progress
  (hchiramm, 12:10:02)
  * bi-weekly update on gluster news  (hchiramm, 12:13:36)
  * ACTION: kshlm to update Gluster News about Gluster.next progress
(hchiramm, 12:13:38)

* kshlm to check back with misc on the new jenkins slaves.  (hchiramm,
  12:14:03)
  * LINK: https://public.pad.fsfe.org/p/gluster-weekly-news kshlm
(hchiramm, 12:14:28)
  * ACTION: kshlm to check back with misc on the new jenkins slaves.
(hchiramm, 12:15:36)

* hagarth to post a note on gluster-devel asking for volunteers for the
  role of release maintainer for 3.7.5  (hchiramm, 12:16:02)

* poornimag to send a mail on gluster-devel asking for volunteers to
  backport glfs_fini patches to release-3.5  (hchiramm, 12:17:42)
  * ACTION: poornimag to send a mail on gluster-devel asking for
volunteers to backport glfs_fini patches to release-3.5  (hchiramm,
12:19:54)

* rastar to initiate discussion on exploring the different approaches
  towards doing GlusterFS release management and announcements
  (hchiramm, 12:20:21)
  * ACTION: rastar to initiate discussion on exploring the different
approaches towards doing GlusterFS release management and
announcements  (hchiramm, 12:24:19)
  * ACTION: kshlm or pkarampu need to setup 3.7.5 tracker.  (kshlm,
12:28:52)
  * LINK:

http://gluster.readthedocs.org/en/latest/Developer-guide/GlusterFS%20Release%20process/
(ndevos, 12:29:35)
  * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1260420   (raghu`,
12:30:48)
  * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1260420   (kshlm,
12:31:03)
  * 3.6.6 targetted for 21-09-2015  (kshlm, 12:31:25)
  * ACTION: raghu to announce target for 3.6.6 release  (kshlm,
12:33:13)
  * ndevos to do 3.5.6 release this weekend (~ 11 Sept)  (kshlm,
12:37:53)
  * ACTION: hagarth to di announcement about 3.8 once he finishes
collating information.  (kshlm, 12:45:01)
  * jdarcy is progressing with code-generation and etcd for NSR.
(kshlm, 12:46:17)
  * ACTION: tigert needs to be contacted to fix the favicon.  (kshlm,
12:50:06)
  * Jepsen could be used to test Gluster-4.0  (kshlm, 12:54:01)
  * LINK: https://github.com/aphyr/jepsen   (kshlm, 12:54:10)
  * kkeithley requires more reviewers for
http://review.gluster.org/#/c/11814  (kshlm, 12:56:41)

Meeting ended at 13:05:58 UTC.




Action Items

* kshlm to update Gluster News about Gluster.next progress
* kshlm to check back with misc on the new jenkins slaves.
* poornimag to send a mail on gluster-devel asking for volunteers to
  backport glfs_fini patches to release-3.5
* rastar to initiate discussion on exploring the different approaches
  towards doing GlusterFS release management and announcements
* kshlm or pkarampu need to setup 3.7.5 tracker.
* raghu to announce target for 3.6.6 release
* hagarth to di announcement about 3.8 once he finishes collating
  information.
* tigert needs to be contacted to fix the favicon.




Action Items, by person
---
* hagarth
  * hagarth to di announcement about 3.8 once he finishes collating
information.
* kshlm
  * kshlm to update Gluster News about Gluster.next progress
  * kshlm to check back with misc on the new jenkins slaves.
  * kshlm or pkarampu need to setup 3.7.5 tracker.
* **UNASSIGNED**
  * poornimag to send a mail on gluster-devel asking for volunteers to
backport glfs_fini patches to release-3.5
  * rastar to initiate discussion on exploring the different approaches
towards doing GlusterFS release management and announcements
  * raghu to announce target for 3.6.6 release
  * tigert needs to be contacted to fix the favicon.




People Present (lines said)
---
* kshlm (90)
* hchiramm (67)
* ndevos (42)
* justinclift (37)
* hagarth (33)
* atinm (18)
* krishnan_p (12)
* kkeithley (11)
* jdarcy (9)
* amye1 (8)
* raghu` (7)
* 

Re: [Gluster-devel] [Gluster-users] AFR arbiter volumes

[Ravishankar N]

On 09/09/2015 03:22 PM, wodel youchi wrote:

Hi,

I quite new on GlusterFS

Since the arbiter does not hold any data, how to choose it's size 
compared to the other 2 bricks?


Regards



It depends on the maximum number of inodes (`df -i` )  any of the other 
2 normal bricks can hold. The recommended inode size is 512 bytes but 
since we store various gluster xattrs and possibly application's xattrs 
on the file, I think 8KB per file is a good estimate. So "8KB x max. no. 
of inodes "  should be good for the worst case. If you have some idea of 
the max. number of files you would actually be filling the bricks with, 
that multiplied by 8KB works too as a practical estimate.


I hope I've not made any oversight in these calculations.

-Ravi
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

[Gluster-devel] Review request for Gluster IPv6 bugfix (Bug 1117886)

[nithin dabilpuram]

Hi ,

Can this code be reviewed ? It is related to transport inet6

http://review.gluster.org/#/c/11988/

thanks
Nithin

On Wed, Jun 17, 2015 at 9:06 AM, Nithin Kumar Dabilpuram <
nithind1...@yahoo.in> wrote:

> Sure Richard.
>
> -Nithin
>
>
>
> On Tuesday, 16 June 2015 1:23 AM, Richard Wareing  wrote:
>
>
> Hey Nithin,
>
> We have IPv6 going as well (v3.4.x & v3.6.x), so I might be able to help
> out here and perhaps combine our efforts.  We did something similar here,
> however we also tackled the NFS side of the house, which required a bunch
> of changes due to how port registration w/ portmapper changed in IPv6 vs
> IPv4.  You effectively have to use "libtirpc" to do all the port
> registrations with IPv6.
>
> We can offer up our patches for this work and hopefully things can be
> combined such that end-users can simply do "vol set 
> transport-address-family " and voila they have whatever support
> they desire.
>
> I'll see if we can get this posted to bug 1117886 this week.
>
> Richard
>
>
>
> --
> *From:* gluster-devel-boun...@gluster.org [
> gluster-devel-boun...@gluster.org] on behalf of Nithin Kumar Dabilpuram [
> nithind1...@yahoo.in]
> *Sent:* Saturday, June 13, 2015 9:12 PM
> *To:* gluster-devel@gluster.org
> *Subject:* [Gluster-devel] Gluster IPv6 bugfixes (Bug 1117886)
>
>
>
>
> Hi ,
>
> Can I contribute to this bug fix ? I've worked on Gluster IPv6
> functionality bugs in 3.3.2 in my past organization and was able to
> successfully bring up gluster on IPv6 link local addresses as well.
>
> Please find my work in progress patch. I'll raise gerrit review once
> testing is done. I was successfully able to create volumes with 3 peers and
> add bricks. I'll continue testing other basic functionality and see what
> needs to be modified. Any other suggestions ?
>
> Brief info about the patch:
> Here I'm trying to use "transport.address-family" option in
> /etc/glusterfs/glusterd.vol file and then propagate the same to server and
> client vol files and their translators.
>
> In this way when user mentions "transport.address-family inet6" in its
> glusterd.vol file, all glusterd servers open AF_INET6 sockets and then the
> same information is stored in glusterd_volinfo and used when generating vol
> config files.
>
> -thanks
> Nithin
>
>
>
>
>
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel
>
>
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Managing etcd (4.0)

[Atin Mukherjee]

On 09/10/2015 01:42 AM, Jeff Darcy wrote:
> Better get comfortable, everyone, because I might ramble on for a bit.
> 
> Over the last few days, I've been looking into the issue of how to manage our 
> own instances of etcd (or something similar) as part of our 4.0 configuration 
> store.  This is highly relevant for GlusterD 2.0, which would be both a 
> consumer of the service and (possibly) a manager for the daemons that provide 
> it.  It's also relevant for NSR, which needs a similar kind of 
> highly-available highly-consistent store for information about terms.  Just 
> about any other component might be able to take good advantage of such a 
> facility if it were available, such as DHT 2.0 using it for layout 
> information, and I encourage anyone working on 4.0 to think about how it can 
> make other components simpler.  (BTW, Shyam, that's just a hypothetical 
> example.  Don't take it any more seriously than you want to.)
> 
> This is not the first time I've looked into this.  During the previous round 
> of NSR development, I implemented some code to manage etcd daemons from 
> within GlusterD:
> 
> http://review.gluster.org/#/c/8887/
> 
> That code's junk.  We shouldn't use anything more than small pieces of it.  
> Among other problems, it nukes the etcd information when a new node joins.  
> That was fine for what we were doing with NSR at the time, but clearly can't 
> work in real life.  I've also been looking at the new-ish etcd interfaces for 
> cluster management:
> 
> https://github.com/coreos/etcd/blob/master/Documentation/other_apis.md
> 
> I'm pretty sure these didn't exist when I was last looking at this stuff, but 
> I could be wrong.  In any case, they look pretty nice.  Much like our own 
> "probe" mechanism, it looks like we can start a single-node cluster and then 
> add others into that cluster by talking to one of the current members.  In 
> fact, that similarity suggests how we might manage our instances of etcd.
> 
> (1) Each GlusterD *initially* starts its own private instance of etcd.
> 
> (2) When we probe from a node X to a node Y, the probe message includes 
> information about X's etcd server(s).
> 
> (3) Upon receipt of a probe, Y can (depending on a flag) either *use* X's 
> etcd cluster or *join* it.  Either way, it has to shut down its own one-node 
> cluster.  In the JOIN case, this implies that X will send the appropriate 
> etcd command to its local instance (from whence it will be propagated to the 
> others).
I've a follow up question here. Could you elaborate the difference
between *use* & *join*? As you pointed out that in either ways Y's
configuration shouldn't be taken into considerations, I believe as part
of peer probing we should clean up Y's configuration (bringing down its
one node cluster) and then just join to the existing etcd cluster.
That's the single workflow what I could think of and *use* would also do
the same thing IMO.
> 
> (4) Therefore, the CLI/REST interfaces to initiate a probe need an option to 
> control this join/use flag.  Default should be JOIN for small clusters, where 
> it's not a problem for all nodes to be etcd servers as well.
consul/etcd documentation says that the ideal configuration is to have
3-5 servers to form the cluster. The way I was thinking about it is
during peer probe we would check whether cluster has already gotten the
enough number of servers to form the cluster, if not then consider the
other end to join as a etcd server otherwise act as a client. Thoughts?
> 
> (5) For larger clusters, the administrator might start to specify USE instead 
> of JOIN after a while.  There might also need to be separate CLI/REST 
> interfaces to toggle this state without any probe involved.
> 
> (6) For detach/deprobe, we simply undo the things we did in (3).
> 
> With all of this in place, probes would become one-time exchanges.  There's 
> no need for GlusterD daemons to keep probing each other when they can just 
> "check in" with etcd (which is doing something very similar internally).  
> Instead of constantly sending its own probe/heartbeat messages and keeping 
> track of which others nodes' messages have been missed, each GlusterD would 
> simply use its node UUID to create a time-limited key in etcd, and issue 
> watches on other nodes' keys.  This is not quite as convenient as ZooKeeper's 
> ephemerals, but it's still a lot better than what we're doing now.
> 
> I'd be tempted to implement this myself, but for now it's probably more 
> important to work on NSR itself and for that I can just use an external etcd 
> cluster instead.  Maybe later in the 4.0 integration phase, if nobody else 
> has beaten me to it, I'll take a swing at it.  Until then, does anyone else 
> have any thoughts on the proposal?
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel
> 

[Gluster-devel] FreeBSD Smoke failure

[Atin Mukherjee]

All the patches are failing in FreeBSD smoke with the following log:

/usr/home/jenkins/root/workspace/freebsd-smoke/libglusterfs/src/gfdb/gfdb_sqlite3.h:15:10:
fatal error: 'sqlite3.h' file not found

Could you take a look at it?

Thanks,
Atin
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Managing etcd (4.0)

[Venky Shankar]

On Thu, Sep 10, 2015 at 10:05 AM, Atin Mukherjee  wrote:
>
>
> On 09/10/2015 01:42 AM, Jeff Darcy wrote:
>> Better get comfortable, everyone, because I might ramble on for a bit.
>>
>> Over the last few days, I've been looking into the issue of how to manage 
>> our own instances of etcd (or something similar) as part of our 4.0 
>> configuration store.  This is highly relevant for GlusterD 2.0, which would 
>> be both a consumer of the service and (possibly) a manager for the daemons 
>> that provide it.  It's also relevant for NSR, which needs a similar kind of 
>> highly-available highly-consistent store for information about terms.  Just 
>> about any other component might be able to take good advantage of such a 
>> facility if it were available, such as DHT 2.0 using it for layout 
>> information, and I encourage anyone working on 4.0 to think about how it can 
>> make other components simpler.  (BTW, Shyam, that's just a hypothetical 
>> example.  Don't take it any more seriously than you want to.)
>>
>> This is not the first time I've looked into this.  During the previous round 
>> of NSR development, I implemented some code to manage etcd daemons from 
>> within GlusterD:
>>
>> http://review.gluster.org/#/c/8887/
>>
>> That code's junk.  We shouldn't use anything more than small pieces of it.  
>> Among other problems, it nukes the etcd information when a new node joins.  
>> That was fine for what we were doing with NSR at the time, but clearly can't 
>> work in real life.  I've also been looking at the new-ish etcd interfaces 
>> for cluster management:
>>
>> https://github.com/coreos/etcd/blob/master/Documentation/other_apis.md
>>
>> I'm pretty sure these didn't exist when I was last looking at this stuff, 
>> but I could be wrong.  In any case, they look pretty nice.  Much like our 
>> own "probe" mechanism, it looks like we can start a single-node cluster and 
>> then add others into that cluster by talking to one of the current members.  
>> In fact, that similarity suggests how we might manage our instances of etcd.
>>
>> (1) Each GlusterD *initially* starts its own private instance of etcd.
>>
>> (2) When we probe from a node X to a node Y, the probe message includes 
>> information about X's etcd server(s).
>>
>> (3) Upon receipt of a probe, Y can (depending on a flag) either *use* X's 
>> etcd cluster or *join* it.  Either way, it has to shut down its own one-node 
>> cluster.  In the JOIN case, this implies that X will send the appropriate 
>> etcd command to its local instance (from whence it will be propagated to the 
>> others).
> I've a follow up question here. Could you elaborate the difference
> between *use* & *join*? As you pointed out that in either ways Y's
> configuration shouldn't be taken into considerations, I believe as part
> of peer probing we should clean up Y's configuration (bringing down its
> one node cluster) and then just join to the existing etcd cluster.
> That's the single workflow what I could think of and *use* would also do
> the same thing IMO.

Here's what I think:

With join, the node becomes a "part" of the etcd cluster participating
in leader election, replicating logs and such.

With use, the node could just use the etcd service without becoming a
part of the cluster (just as NSR would *use* etcd to store term
information).

>>
>> (4) Therefore, the CLI/REST interfaces to initiate a probe need an option to 
>> control this join/use flag.  Default should be JOIN for small clusters, 
>> where it's not a problem for all nodes to be etcd servers as well.
> consul/etcd documentation says that the ideal configuration is to have
> 3-5 servers to form the cluster. The way I was thinking about it is
> during peer probe we would check whether cluster has already gotten the
> enough number of servers to form the cluster, if not then consider the
> other end to join as a etcd server otherwise act as a client. Thoughts?
>>
>> (5) For larger clusters, the administrator might start to specify USE 
>> instead of JOIN after a while.  There might also need to be separate 
>> CLI/REST interfaces to toggle this state without any probe involved.
>>
>> (6) For detach/deprobe, we simply undo the things we did in (3).
>>
>> With all of this in place, probes would become one-time exchanges.  There's 
>> no need for GlusterD daemons to keep probing each other when they can just 
>> "check in" with etcd (which is doing something very similar internally).  
>> Instead of constantly sending its own probe/heartbeat messages and keeping 
>> track of which others nodes' messages have been missed, each GlusterD would 
>> simply use its node UUID to create a time-limited key in etcd, and issue 
>> watches on other nodes' keys.  This is not quite as convenient as 
>> ZooKeeper's ephemerals, but it's still a lot better than what we're doing 
>> now.
>>
>> I'd be tempted to implement this myself, but for now it's probably more 
>> important to work on NSR 

Re: [Gluster-devel] FreeBSD Smoke failure

[Akhil]

Hello Atin,

I have just started with the GlusterFS devel mailing list. I think the
issue here could be that you do not have sqlite-devel installed on your
system.

I see that I have sqlite-devel installed and "/usr/include/sqlite3.h" file
exist on my machine where I build and compile the glusterfs from sources.

You may want to install "sqlite-devel" package and retry the smoke test.

Hope this helps.

Regards,
Akhil

On Thu, Sep 10, 2015 at 10:10 AM, Atin Mukherjee 
wrote:

> All the patches are failing in FreeBSD smoke with the following log:
>
>
> /usr/home/jenkins/root/workspace/freebsd-smoke/libglusterfs/src/gfdb/gfdb_sqlite3.h:15:10:
> fatal error: 'sqlite3.h' file not found
>
> Could you take a look at it?
>
> Thanks,
> Atin
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel
>



-- 
With warm regards,

Akhil Bhansali.
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

[Gluster-devel] Feature: FOP Statistics JSON Dumps

[Richard Wareing]

Hey all,

I just uploaded a clean patch for our FOP statistics dump feature @ 
https://bugzilla.redhat.com/show_bug.cgi?id=1261700 .

Patches cleanly to v3.6.x/v3.7.x release branches, also includes io-stats 
support for intel arch atomic operations (ifdef'd for portability) such that 
you can collect data 24x7 with a negligible latency hit in the IO path.  We've 
been using this for quite sometime and there appeared to have been some 
interest at the dev summit to have this in mainline; so here it is.

Take a look, and I hope you find it useful.

Richard

___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

[Gluster-devel] tracker bug for 3.7.5 is created

[Pranith Kumar Karampuri]

hi,
 Please use 
https://bugzilla.redhat.com/show_bug.cgi?id=glusterfs-3.7.5 for tracking 
bug fixes that need to get into 3.7.5 release.


Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Review request for Gluster IPv6 bugfix (Bug 1117886)

[Atin Mukherjee]

On 09/10/2015 06:30 AM, nithin dabilpuram wrote:
> Hi ,
> 
> Can this code be reviewed ? It is related to transport inet6
> 
> http://review.gluster.org/#/c/11988/
I've reviewed it and logged some comments.

~Atin
> 
> thanks
> Nithin
> 
> On Wed, Jun 17, 2015 at 9:06 AM, Nithin Kumar Dabilpuram
> > wrote:
> 
> Sure Richard.
>  
> -Nithin
> 
> 
> 
> On Tuesday, 16 June 2015 1:23 AM, Richard Wareing  > wrote:
> 
> 
> Hey Nithin,
> 
> We have IPv6 going as well (v3.4.x & v3.6.x), so I might be able to
> help out here and perhaps combine our efforts.  We did something
> similar here, however we also tackled the NFS side of the house,
> which required a bunch of changes due to how port registration w/
> portmapper changed in IPv6 vs IPv4.  You effectively have to use
> "libtirpc" to do all the port registrations with IPv6.
> 
> We can offer up our patches for this work and hopefully things can
> be combined such that end-users can simply do "vol set 
> transport-address-family " and voila they have whatever
> support they desire.
> 
> I'll see if we can get this posted to bug 1117886 this week.
> 
> Richard
> 
> 
> 
> 
> *From:* gluster-devel-boun...@gluster.org
> 
> [gluster-devel-boun...@gluster.org
> ] on behalf of Nithin
> Kumar Dabilpuram [nithind1...@yahoo.in ]
> *Sent:* Saturday, June 13, 2015 9:12 PM
> *To:* gluster-devel@gluster.org 
> *Subject:* [Gluster-devel] Gluster IPv6 bugfixes (Bug 1117886)
> 
> 
> 
> 
> Hi,
> 
> Can I contribute to this bug fix ? I've worked on Gluster IPv6
> functionality bugs in 3.3.2 in my past organization and was able to
> successfully bring up gluster on IPv6 link local addresses as well.
> 
> Please find my work in progress patch. I'll raise gerrit review once
> testing is done. I was successfully able to create volumes with 3
> peers and add bricks. I'll continue testing other basic
> functionality and see what needs to be modified. Any other suggestions ?
> 
> Brief info about the patch:
> Here I'm trying to use "transport.address-family" option in
> /etc/glusterfs/glusterd.vol file and then propagate the same to
> server and client vol files and their translators.
> 
> In this way when user mentions "transport.address-family inet6" in
> its glusterd.vol file, all glusterd servers open AF_INET6 sockets
> and then the same information is stored in glusterd_volinfo and used
> when generating vol config files.
>  
> -thanks
> Nithin
> 
> 
> 
> 
> 
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org 
> http://www.gluster.org/mailman/listinfo/gluster-devel
> 
> 
> 
> 
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel
> 
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

[Gluster-devel] Managing etcd (4.0)

[Jeff Darcy]

Better get comfortable, everyone, because I might ramble on for a bit.

Over the last few days, I've been looking into the issue of how to manage our 
own instances of etcd (or something similar) as part of our 4.0 configuration 
store.  This is highly relevant for GlusterD 2.0, which would be both a 
consumer of the service and (possibly) a manager for the daemons that provide 
it.  It's also relevant for NSR, which needs a similar kind of highly-available 
highly-consistent store for information about terms.  Just about any other 
component might be able to take good advantage of such a facility if it were 
available, such as DHT 2.0 using it for layout information, and I encourage 
anyone working on 4.0 to think about how it can make other components simpler.  
(BTW, Shyam, that's just a hypothetical example.  Don't take it any more 
seriously than you want to.)

This is not the first time I've looked into this.  During the previous round of 
NSR development, I implemented some code to manage etcd daemons from within 
GlusterD:

http://review.gluster.org/#/c/8887/

That code's junk.  We shouldn't use anything more than small pieces of it.  
Among other problems, it nukes the etcd information when a new node joins.  
That was fine for what we were doing with NSR at the time, but clearly can't 
work in real life.  I've also been looking at the new-ish etcd interfaces for 
cluster management:

https://github.com/coreos/etcd/blob/master/Documentation/other_apis.md

I'm pretty sure these didn't exist when I was last looking at this stuff, but I 
could be wrong.  In any case, they look pretty nice.  Much like our own "probe" 
mechanism, it looks like we can start a single-node cluster and then add others 
into that cluster by talking to one of the current members.  In fact, that 
similarity suggests how we might manage our instances of etcd.

(1) Each GlusterD *initially* starts its own private instance of etcd.

(2) When we probe from a node X to a node Y, the probe message includes 
information about X's etcd server(s).

(3) Upon receipt of a probe, Y can (depending on a flag) either *use* X's etcd 
cluster or *join* it.  Either way, it has to shut down its own one-node 
cluster.  In the JOIN case, this implies that X will send the appropriate etcd 
command to its local instance (from whence it will be propagated to the others).

(4) Therefore, the CLI/REST interfaces to initiate a probe need an option to 
control this join/use flag.  Default should be JOIN for small clusters, where 
it's not a problem for all nodes to be etcd servers as well.

(5) For larger clusters, the administrator might start to specify USE instead 
of JOIN after a while.  There might also need to be separate CLI/REST 
interfaces to toggle this state without any probe involved.

(6) For detach/deprobe, we simply undo the things we did in (3).

With all of this in place, probes would become one-time exchanges.  There's no 
need for GlusterD daemons to keep probing each other when they can just "check 
in" with etcd (which is doing something very similar internally).  Instead of 
constantly sending its own probe/heartbeat messages and keeping track of which 
others nodes' messages have been missed, each GlusterD would simply use its 
node UUID to create a time-limited key in etcd, and issue watches on other 
nodes' keys.  This is not quite as convenient as ZooKeeper's ephemerals, but 
it's still a lot better than what we're doing now.

I'd be tempted to implement this myself, but for now it's probably more 
important to work on NSR itself and for that I can just use an external etcd 
cluster instead.  Maybe later in the 4.0 integration phase, if nobody else has 
beaten me to it, I'll take a swing at it.  Until then, does anyone else have 
any thoughts on the proposal?
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel