[Gluster-devel] Gluster Community Bug Triage meeting

Hi there, Rafi KC (rkavu...@redhat.com) invites you to participate in the Doodle poll "Gluster Community Bug Triage meeting." This meeting is scheduled for anyone that is interested in learning more about, or assisting with the triaging of bug for GlusterFS product. This meeting usually

Re: [Gluster-devel] GlusterFS User and Group Quotas

Answer inline - Original Message - From: "Vijaikumar Mallikarjuna" To: "Gluster Devel" Sent: Tuesday, December 8, 2015 3:02:55 PM Subject: [Gluster-devel] GlusterFS User and Group Quotas Hi All, Below is the design for ' GlusterFS User

[Gluster-devel] REMINDER: Gluster Community Bug Triage meeting at 12:00 UTC (~in 30 minutes)

Hi all, This meeting is scheduled for anyone that is interested in learning more about, or assisting with the Bug Triage. Meeting details: - location: #gluster-meeting on Freenode IRC (https://webchat.freenode.net/?channels=gluster-meeting ) - date: every Tuesday - time: 12:00 UTC

[Gluster-devel] Minutes of today's Gluster Community Bug Triage Meeting (December 8, 2015)

> Hi all, > > This meeting is scheduled for anyone that is interested in learning more > about, or assisting with the Bug Triage. > > Meeting details: > - location: #gluster-meeting on Freenode IRC > (https://webchat.freenode.net/?channels=gluster-meeting ) > - date: every Tuesday > -

[Gluster-devel] Restarting build.gluster.org

The gerrit-trigger plugin is not triggering automatically again. And as before, I have no idea why. I've scheduled a Jenkins restart, which should happen after running jobs finish. Hopefully, this fixes the problem. ~kaushal ___ Gluster-devel mailing

Re: [Gluster-devel] Should we remove tests/basic/rpm.t from the regression suite?

On 12/08/2015 10:25 AM, Kaushal M wrote: > We already have devrpms jobs which test building rpms, so building > rpms again seems unnecessary. > > The reason I'm asking this is because I'm facing issues trying to get > this working in the saltstack configured environment I'm fixing. I > don't see

Re: [Gluster-devel] compound fop design first cut

Raghavendra Gowdappa writes: > From what I can see, new compound ops will _evolve_ in future based on > requirements unseen as of now. Yes, That is the one thing you can count on here ;) The compounding architecture proposed here, scares me to be honest. The complexity

Re: [Gluster-devel] compound fop design first cut

On December 8, 2015 at 12:53:04 PM, Ira Cooper (i...@redhat.com) wrote: > Raghavendra Gowdappa writes: > I propose that we define a "compound op" that contains ops. > > Within each op, there are fields that can be "inherited" from the > previous op, via use of a sentinel value. > > Sentinel

Re: [Gluster-devel] compound fop design first cut

On 12/09/2015 11:44 AM, Pranith Kumar Karampuri wrote: On 12/09/2015 06:37 AM, Vijay Bellur wrote: On 12/08/2015 03:45 PM, Jeff Darcy wrote: On December 8, 2015 at 12:53:04 PM, Ira Cooper (i...@redhat.com) wrote: Raghavendra Gowdappa writes: I propose that we define a "compound op"

[Gluster-devel] minor "make install" issue for FreeBSD

Near the end of "make install", it fails in glusterfind because DESTDIR is empty. Here's the "make install" output: ../.././install-sh -c -d '/usr/local/libexec/glusterfs/gfind_missing_files' /usr/bin/install -c gfind_missing_files.sh gfid_to_path.sh gfid_to_path.py

Re: [Gluster-devel] compound fop design first cut

On 12/08/2015 03:45 PM, Jeff Darcy wrote: On December 8, 2015 at 12:53:04 PM, Ira Cooper (i...@redhat.com) wrote: Raghavendra Gowdappa writes: I propose that we define a "compound op" that contains ops. Within each op, there are fields that can be "inherited" from the previous op, via use

Re: [Gluster-devel] compound fop design first cut

On 12/09/2015 10:39 AM, Prashanth Pai wrote: However, I’d be even more comfortable with an even simpler approach that avoids the need to solve what the database folks (who have dealt with complex transactions for years) would tell us is a really hard problem. Instead of designing for every

[Gluster-devel] Gluster Upstream Development Visual

Hi Team, Here is a Video that highlights all your contributions to Gluster (Upstream). Help yourself to find your Name by adjusting the dates shown in the top with the help of progress bar. I dedicate this to all Gluster folks. Link:

Re: [Gluster-devel] GFID to Path Conversion

Hi, Sharing draft design for GFID to Path Conversion.(Directory GFID to Path is very easy in DHT v.1, this design may not work in case of DHT 2.0) Performance and Storage space impact yet to be analyzed. Storing the required informaton --- Metadata information

[Gluster-devel] Review backlog

Hi All, We have approximately 500 open patches in gerrit with the last updated timestamp of at least one patch going all the way back to 2012. Of these patches, a fair number are no longer valid and probably need to be abandoned. Even after that we will be left with a significant number of

Re: [Gluster-devel] Should we remove tests/basic/rpm.t from the regression suite?

On Tue, Dec 8, 2015 at 9:39 PM, Kaleb KEITHLEY wrote: > On 12/08/2015 10:25 AM, Kaushal M wrote: >> We already have devrpms jobs which test building rpms, so building >> rpms again seems unnecessary. >> >> The reason I'm asking this is because I'm facing issues trying to get

Re: [Gluster-devel] compound fop design first cut

On 12/09/2015 06:37 AM, Vijay Bellur wrote: On 12/08/2015 03:45 PM, Jeff Darcy wrote: On December 8, 2015 at 12:53:04 PM, Ira Cooper (i...@redhat.com) wrote: Raghavendra Gowdappa writes: I propose that we define a "compound op" that contains ops. Within each op, there are fields that can