Re: [Gluster-devel] Initiative to increase developer participation
On Thu, May 29, 2014 at 11:08:34PM -0400, Pranith Kumar Karampuri wrote: hi, We are taking an initiative to come up with some easy bugs where we can help volunteers in the community to send patches for. Goals of this initiative: - Each maintainer needs to come up with a list of bugs that are easy to fix in their components. - All the developers who are already active in the community to help the new comers by answering the questions. - Improve developer documentation to address FAQ Documentation in the wiki, mainly these pages: - http://www.gluster.org/community/documentation/index.php/Main_Page#Developers - http://www.gluster.org/community/documentation/index.php/Developers - Over time make these new comers as experienced developers in glusterfs :-) Maintainers, Could you please come up with the initial list of bugs by next Wednesday before community meeting? If we mark bugs with the EasyFix keyword (see below), all bugs can get listed with a simple Bugzilla query: - https://bugzilla.redhat.com/buglist.cgi?bug_status=NEWkeywords=EasyFixproduct=GlusterFS Niels, Could you send out the guideline to mark the bugs as easy fix. Also the wiki link for backports. To mark a bug as Easy to Fix, open the Bug, and add in 'EasyFix' in the 'Keywords' field. Of course, it would help any newcomer if there is a comment on where (i.e. which source file, function) the changes are needed. For example, https://bugzilla.redhat.com/1100204 contains a clear description what is needed, and where. For the stable branches (release-3.4 and release-3.5 in the git repository), it often is needed to 'backport' a change from the current development branch (master). Backporting is for many changes relatively easy and we have started to document the steps here: - http://www.gluster.org/community/documentation/index.php/Backport_Guidelines The Backport Wishlist is a list of patches/bugs that are proposed candidates for backporting. When a backport request has been filed, a bug for this backport and the release-version should be created. Depending on the change, the EasyFix keyword could be set by the person creating the bug (or by a developer or sub-maintainer after a review). PS: This is not just for new comers to the community but also for existing developers to explore other components. Please feel free to suggest and give feedback to improve this process :-). And, as a reminder, anyone that is interested in trying to write a patch, do not hesitate to ask questions. If something in the documentation is unclear, we do need to know so that we can improve it. Furthermore, I am of the opinion that there hardly exist stupid questions, and it's more stupid to not ask questions that others can easily answer. Always assume that if you have a question, someone else would like to hear the answer too :-) Reach out to the developers in #gluster or #gluster-dev on Freenode IRC, or on one of the mailinglists, try to keep the discussions public so that anyone can learn from it. Thanks, Niels ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] inode lru limit
Hi, Currently the lru-limit of the inode table in brick processes is 16384. There is a option to configure it to some other value. The protocol/server uses inode_lru_limit variable present in its private structure while creating the inode table (whose default value is 16384). When the option is reconfigured via volume set option the protocol/server's inode_lru_limit variable present in its private structure is changed. But the actual size of the inode table still remains same as old one. Only when the brick is restarted the newly set value comes into picture. Is it ok? Should we change the inode table's lru_limit variable also as part of reconfigure? If so, then probably we might have to remove the extra inodes present in the lru list by calling inode_table_prune. Please provide feedback Regards, Raghavendra Bhat ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Initiative to increase developer participation
Thanks Pranith/Niels, It is a great initiative, it will help us a lot :) On 05/30/2014 01:16 PM, Niels de Vos wrote: On Thu, May 29, 2014 at 11:08:34PM -0400, Pranith Kumar Karampuri wrote: hi, We are taking an initiative to come up with some easy bugs where we can help volunteers in the community to send patches for. Goals of this initiative: - Each maintainer needs to come up with a list of bugs that are easy to fix in their components. - All the developers who are already active in the community to help the new comers by answering the questions. - Improve developer documentation to address FAQ Documentation in the wiki, mainly these pages: - http://www.gluster.org/community/documentation/index.php/Main_Page#Developers - http://www.gluster.org/community/documentation/index.php/Developers - Over time make these new comers as experienced developers in glusterfs :-) Maintainers, Could you please come up with the initial list of bugs by next Wednesday before community meeting? If we mark bugs with the EasyFix keyword (see below), all bugs can get listed with a simple Bugzilla query: - https://bugzilla.redhat.com/buglist.cgi?bug_status=NEWkeywords=EasyFixproduct=GlusterFS Niels, Could you send out the guideline to mark the bugs as easy fix. Also the wiki link for backports. To mark a bug as Easy to Fix, open the Bug, and add in 'EasyFix' in the 'Keywords' field. Of course, it would help any newcomer if there is a comment on where (i.e. which source file, function) the changes are needed. For example, https://bugzilla.redhat.com/1100204 contains a clear description what is needed, and where. For the stable branches (release-3.4 and release-3.5 in the git repository), it often is needed to 'backport' a change from the current development branch (master). Backporting is for many changes relatively easy and we have started to document the steps here: - http://www.gluster.org/community/documentation/index.php/Backport_Guidelines The Backport Wishlist is a list of patches/bugs that are proposed candidates for backporting. When a backport request has been filed, a bug for this backport and the release-version should be created. Depending on the change, the EasyFix keyword could be set by the person creating the bug (or by a developer or sub-maintainer after a review). PS: This is not just for new comers to the community but also for existing developers to explore other components. Please feel free to suggest and give feedback to improve this process :-). And, as a reminder, anyone that is interested in trying to write a patch, do not hesitate to ask questions. If something in the documentation is unclear, we do need to know so that we can improve it. Furthermore, I am of the opinion that there hardly exist stupid questions, and it's more stupid to not ask questions that others can easily answer. Always assume that if you have a question, someone else would like to hear the answer too :-) Reach out to the developers in #gluster or #gluster-dev on Freenode IRC, or on one of the mailinglists, try to keep the discussions public so that anyone can learn from it. Thanks, Niels ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] regarding special treatment of ENOTSUP for setxattr
- Original Message -
From: Pranith Kumar Karampuri pkara...@redhat.com
To: Vijay Bellur vbel...@redhat.com
Cc: Gluster Devel gluster-devel@gluster.org
Sent: Wednesday, May 28, 2014 4:16:32 PM
Subject: Re: [Gluster-devel] regarding special treatment of ENOTSUP for
setxattr
Vijay,
Could you please merge http://review.gluster.com/7788 if there are no more
concerns.
Gentle reminder.
Pranith.
Pranith
- Original Message -
From: Pranith Kumar Karampuri pkara...@redhat.com
To: Harshavardhana har...@harshavardhana.net
Cc: Gluster Devel gluster-devel@gluster.org
Sent: Monday, May 26, 2014 1:18:18 PM
Subject: Re: [Gluster-devel] regarding special treatment of ENOTSUP for
setxattr
Please review http://review.gluster.com/7788 submitted to remove the
filtering of that error.
Pranith
- Original Message -
From: Harshavardhana har...@harshavardhana.net
To: Pranith Kumar Karampuri pkara...@redhat.com
Cc: Kaleb KEITHLEY kkeit...@redhat.com, Gluster Devel
gluster-devel@gluster.org
Sent: Friday, May 23, 2014 2:12:02 AM
Subject: Re: [Gluster-devel] regarding special treatment of ENOTSUP for
setxattr
http://review.gluster.com/#/c/7823/ - the fix here
On Thu, May 22, 2014 at 1:41 PM, Harshavardhana
har...@harshavardhana.net wrote:
Here are the important locations in the XFS tree coming from 2.6.32
branch
STATIC int
xfs_set_acl(struct inode *inode, int type, struct posix_acl *acl)
{
struct xfs_inode *ip = XFS_I(inode);
unsigned char *ea_name;
int error;
if (S_ISLNK(inode-i_mode)) I would
generally think this is the issue.
return -EOPNOTSUPP;
STATIC long
xfs_vn_fallocate(
struct inode*inode,
int mode,
loff_t offset,
loff_t len)
{
longerror;
loff_t new_size = 0;
xfs_flock64_t bf;
xfs_inode_t *ip = XFS_I(inode);
int cmd = XFS_IOC_RESVSP;
int attr_flags = XFS_ATTR_NOLOCK;
if (mode ~(FALLOC_FL_KEEP_SIZE | FALLOC_FL_PUNCH_HOLE))
return -EOPNOTSUPP;
STATIC int
xfs_ioc_setxflags(
xfs_inode_t *ip,
struct file *filp,
void__user *arg)
{
struct fsxattr fa;
unsigned intflags;
unsigned intmask;
int error;
if (copy_from_user(flags, arg, sizeof(flags)))
return -EFAULT;
if (flags ~(FS_IMMUTABLE_FL | FS_APPEND_FL | \
FS_NOATIME_FL | FS_NODUMP_FL | \
FS_SYNC_FL))
return -EOPNOTSUPP;
Perhaps some sort of system level acl's are being propagated by us
over symlinks() ? - perhaps this is the related to the same issue of
following symlinks?
On Sun, May 18, 2014 at 10:48 AM, Pranith Kumar Karampuri
pkara...@redhat.com wrote:
Sent the following patch to remove the special treatment of ENOTSUP
here:
http://review.gluster.org/7788
Pranith
- Original Message -
From: Kaleb KEITHLEY kkeit...@redhat.com
To: gluster-devel@gluster.org
Sent: Tuesday, May 13, 2014 8:01:53 PM
Subject: Re: [Gluster-devel] regarding special treatment of ENOTSUP
for
setxattr
On 05/13/2014 08:00 AM, Nagaprasad Sathyanarayana wrote:
On 05/07/2014 03:44 PM, Pranith Kumar Karampuri wrote:
- Original Message -
From: Raghavendra Gowdappa rgowd...@redhat.com
To: Pranith Kumar Karampuri pkara...@redhat.com
Cc: Vijay Bellur vbel...@redhat.com,
gluster-devel@gluster.org,
Anand Avati aav...@redhat.com
Sent: Wednesday, May 7, 2014 3:42:16 PM
Subject: Re: [Gluster-devel] regarding special treatment of
ENOTSUP
for setxattr
I think with repetitive log message suppression patch being
merged,
we
don't really need gf_log_occasionally (except if they are logged
in
DEBUG or
TRACE levels).
That definitely helps. But still, setxattr calls are not supposed
to
fail with ENOTSUP on FS where we support gluster. If there are
special
keys which fail with ENOTSUPP, we can conditionally log setxattr
failures only when the key is something new?
I know this is about EOPNOTSUPP (a.k.a. ENOTSUPP) returned by
setxattr(2) for legitimate attrs.
But I can't help but wondering if this isn't related to other bugs
we've
had with, e.g., lgetxattr(2) called on invalid xattrs?
E.g. see https://bugzilla.redhat.com/show_bug.cgi?id=765202. We have
a
hack where xlators communicate with
Re: [Gluster-devel] rackspace-regression job history disappeared?
On 29/05/2014, at 5:58 AM, Justin Clift wrote: snip Any idea what causes the job history for a project (eg rackspace-regression) to disappear? Asked on #jenkins IRC, and the it seems to be a bug in Jenkins. :( They said possibly this one: https://issues.jenkins-ci.org/browse/JENKINS-16845 But there are others in their issue tracker with similar symptoms. The job history itself is actually still on disk on the master (under /var/lib/jenkins/jobs/rackspace-regression/builds). Its just not showing up in the webUI. We may need to upgrade Jenkins. More likely, setup new Jenkins instance in Rackspace. (this has really turned into a strange-and-unusual-punishment thing hasn't it? ;) + Justin -- Open Source and Standards @ Red Hat twitter.com/realjustinclift ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] rackspace-regression job history disappeared?
:-D Nice job JC. - Luis On 05/30/2014 10:54 AM, Justin Clift wrote: On 29/05/2014, at 5:58 AM, Justin Clift wrote: snip Any idea what causes the job history for a project (eg rackspace-regression) to disappear? Asked on #jenkins IRC, and the it seems to be a bug in Jenkins. :( They said possibly this one: https://issues.jenkins-ci.org/browse/JENKINS-16845 But there are others in their issue tracker with similar symptoms. The job history itself is actually still on disk on the master (under /var/lib/jenkins/jobs/rackspace-regression/builds). Its just not showing up in the webUI. We may need to upgrade Jenkins. More likely, setup new Jenkins instance in Rackspace. (this has really turned into a strange-and-unusual-punishment thing hasn't it? ;) + Justin -- Open Source and Standards @ Red Hat twitter.com/realjustinclift ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
