Re: [Gluster-devel] NetBSD builds failing

On Mon, Sep 07, 2015 at 02:08:44PM +0530, Ravishankar N wrote: > > git rev-parse --is-inside-work-tree # timeout=10 > Fetching changes from the remote Git repository > > git config remote.origin.url git://review.gluster.org/glusterfs.git # > timeout=10 > ERROR: Error fetching remote repo

[Gluster-devel] NetBSD builds failing

The last 15 odd regressions seem to have failed with the same error: Triggered by Gerrit:http://review.gluster.org/12109 in silent mode. Building remotely onnbslave75.cloud.gluster.org (netbsd7_regression) in workspace

Re: [Gluster-devel] wrong volume status report

Atin Mukherjee wrote: > GlusterD doesn't report the status of bricks if find that another > transaction on the same volume is in progress on the cluster. That the point: the bricks suddently disaprear from glusterfs volume status output. That does not obviously tell this

Re: [Gluster-devel] NetBSD builds failing

On 09/07/2015 02:45 PM, Emmanuel Dreyfus wrote: I nuked nbslae75:/build/install/var/log/glusterfs/*.tar.gz It should fix the problem. Thanks for that Emmanuel. ___ Gluster-devel mailing list Gluster-devel@gluster.org

Re: [Gluster-devel] Dynamically changing firewalld services

On 09/07/2015 05:08 PM, Joe Julian wrote: On 09/06/2015 09:01 PM, Kaushal M wrote: After more investigation and further discussions (sorry these happened internally), what I've found is that there is no way currently to dynamically change a firewalld service in runtime without side effects.

Re: [Gluster-devel] GlusterD 2.0 status updates

On Saturday 05 September 2015 05:46 AM, Richard Wareing wrote: So far things are moving towards 3-4 languages (Python, C, Go, sprinkle of BASH) and 2 RPC frameworks. No language or RPC mechanism is perfect, but the proficiency of the coder at the keyboard is_far_ more important. IMHO we

Re: [Gluster-devel] Dynamically changing firewalld services

On 09/07/2015 09:25 AM, Anand Nekkunti wrote: On 09/07/2015 05:08 PM, Joe Julian wrote: On 09/06/2015 09:01 PM, Kaushal M wrote: After more investigation and further discussions (sorry these happened internally), what I've found is that there is no way currently to dynamically change a

Re: [Gluster-devel] GlusterD 2.0 status updates

> Agree here. I think we can use Go as the other non-C language for > components like glusterd, geo-replication etc. and retire the python > implementation of gsyncd that exists in 3.x over time. That sounds like a pretty major effort. Are you suggesting that it (or even part of it) should be

Re: [Gluster-devel] GlusterD 2.0 status updates

> - Support for SSL transports - thought we wouldn't be using this > initially, we would require it later on. Control-plane security is important enough that I think it has to be a Day One requirement. ___ Gluster-devel mailing list

Re: [Gluster-devel] GlusterD 2.0 status updates

On 09/07/2015 12:47 PM, Kaushal M wrote: > On Mon, Sep 7, 2015 at 8:29 PM, Jeff Darcy wrote: >>> - Support for SSL transports - thought we wouldn't be using this >>> initially, we would require it later on. >> >> Control-plane security is important enough that I think it has to

Re: [Gluster-devel] wrong volume status report

On 09/07/2015 05:11 PM, Emmanuel Dreyfus wrote: > Atin Mukherjee wrote: > >> GlusterD doesn't report the status of bricks if find that another >> transaction on the same volume is in progress on the cluster. > > That the point: the bricks suddently disaprear from

Re: [Gluster-devel] Dynamically changing firewalld services

On Mon, Sep 7, 2015 at 5:08 PM, Joe Julian wrote: > > > On 09/06/2015 09:01 PM, Kaushal M wrote: >> >> After more investigation and further discussions (sorry these happened >> internally), what I've found is that there is no way currently to >> dynamically change a

Re: [Gluster-devel] GlusterD 2.0 status updates

On Mon, Sep 7, 2015 at 8:29 PM, Jeff Darcy wrote: >> - Support for SSL transports - thought we wouldn't be using this >> initially, we would require it later on. > > Control-plane security is important enough that I think it has to > be a Day One requirement. I did mean this,

Re: [Gluster-devel] GlusterD 2.0 status updates

On Monday 07 September 2015 09:38 PM, Jeff Darcy wrote: Agree here. I think we can use Go as the other non-C language for components like glusterd, geo-replication etc. and retire the python implementation of gsyncd that exists in 3.x over time. That sounds like a pretty major effort. Are you

Re: [Gluster-devel] GlusterD 2.0 status updates

Hi Atin, This looks interesting. Currently in Heketi it needs to ssh into a system to send commands to glusterfs. It would be great to determine the interfaces needed and how it would work with programs like Heketi. Do you guys have a simple few paragraphs on how glusterd2 rest interface

Re: [Gluster-devel] NetBSD builds failing

On Mon, Sep 7, 2015 at 2:45 PM, Emmanuel Dreyfus wrote: > On Mon, Sep 07, 2015 at 02:08:44PM +0530, Ravishankar N wrote: > > > git rev-parse --is-inside-work-tree # timeout=10 > > Fetching changes from the remote Git repository > > > git config remote.origin.url

Re: [Gluster-devel] GlusterD 2.0 status updates

> Every day we hear about vulnerabilities and exploits. Have we not yet > reached the point were we just start with security enabled as a matter > of routine? > > Why aren't we using TLS (the real name, FWIW) from day one? I think making it default for 3.8+ would be a good idea. The only issue

Re: [Gluster-devel] Difference in bad_tests count in mainline vs 3.7 branch

On Fri, Sep 4, 2015 at 12:56 PM, Raghavendra Talur wrote: > > > >> Maintainers - can you please take stock of this and ensure sanity of your >> components before merging patches that do not fix a failing test? >> >> > Here is my proposal to get this fixed. > > > This weekend,

Re: [Gluster-devel] GlusterD 2.0 status updates

Hi Richard, Thanks a lot for you feedback. I've done my replies inline. On Sat, Sep 5, 2015 at 5:46 AM, Richard Wareing wrote: > Hey Atin (and the wider community), > > This looks interesting, though I have a couple questions: > > 1. Language choice - Why the divergence from