Re: [Gluster-devel] Reducing merge conflicts

2016-07-07 Thread Poornima Gurusiddaiah 

Completely agree with your concern here. Keeping aside the regression part, few 
observations and suggestions:
As per the Maintainers guidelines 
(https://gluster.readthedocs.io/en/latest/Contributors-Guide/Guidelines-For-Maintainers/):

a> Merge patches of owned components only.
b> Seek approvals from all maintainers before merging a patchset spanning 
multiple components.
c> Ensure that regression tests pass for all patches before merging.
d> Ensure that regression tests accompany all patch submissions.
e> Ensure that documentation is updated for a noticeable change in user 
perceivable behavior or design.
f> Encourage code unit tests from patch submitters to improve the overall 
quality of the codebase.
g> Not merge patches written by themselves until there is a +2 Code Review 
vote by other reviewers.

Clearly a, b, are not being strictly followed, because of multiple reasons.
- Not every component in Gluster has a Maintainer
- Its getting difficult to get review time from maintainers as they are 
maintainers for several component, and they are also active developers.
- What is enforced by mere documentation of procedure, is hard to implement.

Below are the few things that we can do to reduce our review backlog:
- No time for maintainers to review is not a good enough reason to bitrot 
patches in review for months, it clearly means we need additional maintainers 
for that component?
- Add maintainers for every component that is in Gluster(atleast the ones which 
have incoming patches)
- For every patch we submit we add 'component(s)' label, and evaluate if gerrit 
can automatically add maintainers as reviewers, and have another label 
'Maintainers ack' which needs to be present for any patch to be merged.
- Before every major(or minor also?) release, any patch that is not making to 
the release should have a '-1' by the maintainer or the developer themselves 
stating the reason(preferably not no time to review).
  The release manager should ensure that there are no patches in below gerrit 
search link provided by Jeff.

Any thoughts?

Regards,
Poornima

- Original Message -
> From: "Jeff Darcy" 
> To: "Gluster Devel" 
> Sent: Friday, July 8, 2016 2:02:27 AM
> Subject: [Gluster-devel] Reducing merge conflicts
> 
> I'm sure a lot of you are pretty frustrated with how long it can take to get
> even a trivial patch through our Gerrit/Jenkins pipeline.  I know I am.
> Slow tests, spurious failures, and bikeshedding over style issues are all
> contributing factors.  I'm not here to talk about those today.  What I am
> here to talk about is the difficulty of getting somebody - anybody - to look
> at a patch and (possibly) give it the votes it needs to be merged.  To put
> it bluntly, laziness here is *killing* us.  The more patches we have in
> flight, the more merge conflicts and rebases we have to endure for each one.
> It's a quadratic effect.  That's why I personally have been trying really
> hard to get patches that have passed all regression tests and haven't gotten
> any other review attention "across the finish line" so they can be merged
> and removed from conflict with every other patch still in flight.  The
> search I use for this, every day, is as follows:
> 
> 
> http://review.gluster.org/#/q/status:open+project:glusterfs+branch:master+label:CentOS-regression%253E0+label:NetBSD-regression%253E0+-label:Code-Review%253C0
> 
> That is:
> 
> open patches on glusterfs master (change project/branch as appropriate to
> your role)
>  
> CentOS and NetBSD regression tests complete
> 
> no -1 or -2 votes which might represent legitimate cause for delay
> 
> If other people - especially team leads and release managers - could make a
> similar habit of checking the queue and helping to get such "low hanging
> fruit" out of the way, we might see an appreciable increase in our overall
> pace of development.  If not, we might have to start talking about mandatory
> reviews with deadlines and penalties for non-compliance.  I'm sure nobody
> wants to see their own patches blocked and their own deadlines missed
> because they weren't doing their part to review peers' work, but that's a
> distinct possibility.  Let's all try to get this train unstuck and back on
> track before extreme measures become necessary.
> ___
> 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] Reducing merge conflicts

2016-07-07 Thread Raghavendra Gowdappa 


- Original Message -
> From: "Pranith Kumar Karampuri" 
> To: "Jeff Darcy" 
> Cc: "Gluster Devel" 
> Sent: Friday, July 8, 2016 9:28:57 AM
> Subject: Re: [Gluster-devel] Reducing merge conflicts
> 
> 
> 
> On Fri, Jul 8, 2016 at 8:40 AM, Jeff Darcy < jda...@redhat.com > wrote:
> 
> 
> > What gets measured gets managed.
> 
> Exactly. Reviewing is part of everyone's job, but reviews aren't tracked
> in any way that matters. Contrast that with the *enormous* pressure most
> of us are under to get our own patches in, and it's pretty predictable
> what will happen. We need to change that calculation.

+1.

> 
> 
> > What I have seen at least is that it is easy to find
> > people who sent patches, how many patches someone sent in a month etc.
> > There
> > is no easy way to get these numbers for reviews. 'Reviewed-by' tag in
> > commit
> > only includes the people who did +1/+2 on the final revision of the patch,
> > which is bad.
> 
> That's a very good point. I think people people who comment also get
> Reviewed-by: lines, but it doesn't matter because there's still a whole
> world of things completely outside of Gerrit. Reviews done by email won't
> get counted, nor will consultations in the hallway or on IRC. I have some
> ideas who's most active in those ways. Some (such as yourself) show up in
> the Reviewed-by: statistics. Others do not. In terms of making sure
> people get all the credit they deserve, those things need to be counted
> too. However, in terms of *getting the review queue unstuck* I'm not so
> sure. What matters for that is the reviews that Gerrit uses to determine
> merge eligibility, so I think encouraging that specific kind of review
> still moves us in a positive direction.
> 
> In my experience at least it was only adding 'reviewied-by' for the people
> who gave +1/+2 on the final version of the patch
> 
> I agree about encouraging specific kind of review. At the same time we need
> to make reviewing, helping users in the community as important as sending
> patches in the eyes of everyone. It is very important to know these
> statistics to move in the right direction. My main problem with this is,
> everyone knows that reviews are important, then why are they not happening?
> Is it really laziness?

I think its more of 
1. priorities and incentives rather than laziness. Of course, maintainers have 
visibility on the component and kind of have a default responsibility (not the 
only one) - and incentive (and again not the only one) to at least review the 
patch. As a developer, there are no such ready incentives (Of course one gains 
more insight into the component etc, but that's not really a strong incentive - 
and expertise takes time to build up - given the other pressures we are all 
subjected to).
2. Its also a factor of competency (you know more about code/design, you find 
the issues, propose solutions and the satisfaction adds up as a feedback loop).
3. Another factor is accountability. If there is a direct accountability we 
tend to prioritize the things over others. However reviewing as of now is a 
_shared_ responsibility.

> Are we sure if there are people in the team who are
> not sharing the burden because of which it is becoming too much for 1 or 2
> people to handle the total load? All these things become very easy to reason
> about if we have this data. 

Personally I've found a genuine -1 to be more valuable than a +1. Since we are 
discussing about measuring, how does one measure the issues that are prevented 
(through a good design, thoughtful coding/review) than the issues that are 
_fixed_? Measuring -1s and -2s along with +1s and +2s can be a good place to 
start with (though as with many measurements, they may not reflect the 
underlying value accurately).

> Then I am sure we can easily find how best to
> solve this issue. Same goes for spurious failures. 

May be test cases are not subjected to strong scrutiny as the accompanying 
code. If one is time-pressed to choose between code and the test-case, I think 
I'll prioritize code over test-case (same with sending patches).

> These are not problems
> that are not faced by others in the world either. I remember watching a
> video where someone shared (I think it was in google) that they started
> putting giant TVs in the hall-way in all the offices and the people who
> don't attend to spurious-build-failure problems would show up on the screen
> for everyone in the world to see. Apparently the guy with the biggest
> picture(the one who was not attending to any build failures at all I guess)
> came to these folks and asked how should he get his picture removed from the
> screen, and it was solved in a day or two. We don't have to go to those
> lengths, but we do need data to nudge people in the right direction.

Though shaming might be an effective way to get things done, I would abstain 
from using it till we are not left with any

Re: [Gluster-devel] iSCSI

2016-07-07 Thread Atin Mukherjee 
Prasanna - Can you help here?

~Atin

On Fri, Jul 8, 2016 at 3:51 AM, francis Lavalliere <
francis.lavalli...@gmail.com> wrote:

> Hello,
>
> I've been messing around with Gluster FS version 3.7 and 3.8.
>
> Currently i am trying to implement iSCSI with Gluster FS.
>
> I've installed ubuntu 16.04 and have installed various components:
>
> I didnt found any tcmu-runner packages for ubuntu, so i manually built it
> using their git repository:
>
> I've tried : cmake . -Dwith-glfs=true  and successfully installed it using
> make/make install..
>
> when I do : targetcli ls  i do not see the output of the user:glfs
>
>
> Here is an example of the output. I've managed to do it via fileio, but
> this is not the right way.
>
> targetcli ls
>
> o- */*
> .*
> [*...*]*
>
>   o- *backstores*
> ..*
> [*...*]*
>
>   | o- *fileio*
> ...*
> [*1 Storage Object*]*
>
>   | | o- *testfs*
> ..*
> [*711.0M, /nfs/testfs.img, in use*]*
>
>   | o- *iblock*
> ...*
> [*0 Storage Object*]*
>
>   | o- *pscsi*
> *
> [*0 Storage Object*]*
>
>   | o- *rd_mcp*
> ...*
> [*0 Storage Object*]*
>
>   o- *ib_srpt*
> ...*
> [*0 Targets*]*
>
>   o- *iscsi*
> ..*
> [*1 Target*]*
>
>   | o- *iqn.2015-04.com.example:target1*
> .*
> [*1 TPG*]*
>
>   |   o- *tpg1*
> *
> [*enabled*]*
>
>   | o- *acls*
> ...*
> [*0 ACLs*]*
>
>   | o- *luns*
> *
> [*1 LUN*]*
>
>   | | o- *lun0*
> *
> [*fileio/testfs (/nfs/testfs.img)*]*
>
>   | o- *portals*
> ..*
> [*1 Portal*]*
>
>   |   o- *0.0.0.0:3260 *
> ...*
> [*OK, iser enabled*]*
>
>   o- *loopback*
> ..*
> [*0 Targets*]*
>
>   o- *qla2xxx*
> ...*
> [*0 Targets*]*
>
>   o- *tcm_fc*
> *
> [*0 Targets*]*
>
>   o- *usb_gadget*
> *
> [*0 Targets*]*
>
>   o- *vhost*
> .*
> [*0 Targets*]*
>
>
> Anyone would know how to make iSCSI target user:glfs show in the targetcli
> to be compatible with GlusterFS Directly?
>
>
> Thank you.
>
>
>
> ___
> 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] [Gluster-Maintainers] Glusterfs-3.7.13 release plans

2016-07-07 Thread Pranith Kumar Karampuri 
Could you take in http://review.gluster.org/#/c/14598/ as well? It is ready
for merge.

On Thu, Jul 7, 2016 at 3:02 PM, Atin Mukherjee  wrote:

> Can you take in http://review.gluster.org/#/c/14861 ?
>
>
> On Thursday 7 July 2016, Kaushal M  wrote:
>
>> On Thu, Jun 30, 2016 at 11:08 AM, Kaushal M  wrote:
>> > Hi all,
>> >
>> > I'm (or was) planning to do a 3.7.13 release on schedule today. 3.7.12
>> > has a huge issue with libgfapi, solved by [1].
>> > I'm not sure if this fixes the other issues with libgfapi noticed by
>> > Lindsay on gluster-users.
>> >
>> > This patch has been included in the packages 3.7.12 built for CentOS,
>> > Fedora, Ubuntu, Debian and SUSE. I guess Lindsay is using one of these
>> > packages, so it might be that the issue seen is new. So I'd like to do
>> > a quick release once we have a fix.
>> >
>> > Maintainers can merge changes into release-3.7 that follow the
>> > criteria given in [2]. Please make sure to add the bugs for patches
>> > you are merging are added as dependencies for the 3.7.13 tracker bug
>> > [3].
>> >
>>
>> I've just merged the fix for the gfapi breakage into release-3.7, and
>> hope to tag 3.7.13 soon.
>>
>> The current head for release-3.7 is commit bddf6f8. 18 patches have
>> been merged since 3.7.12 for the following components,
>>  - gfapi
>>  - nfs (includes ganesha related changes)
>>  - glusterd/cli
>>  - libglusterfs
>>  - fuse
>>  - build
>>  - geo-rep
>>  - afr
>>
>> I need and acknowledgement from the maintainers of the above
>> components that they are ready.
>> If any maintainers know of any other issues, please reply here. We'll
>> decide how to address them for this release here.
>>
>> Also, please don't merge anymore changes into release-3.7. If you need
>> to get something merged, please inform me.
>>
>> Thanks,
>> Kaushal
>>
>> > Thanks,
>> > Kaushal
>> >
>> > [1]: https://review.gluster.org/14822
>> > [2]: https://public.pad.fsfe.org/p/glusterfs-release-process-201606
>> > under the GlusterFS minor release heading
>> > [3]: https://bugzilla.redhat.com/show_bug.cgi?id=glusterfs-3.7.13
>> ___
>> maintainers mailing list
>> maintain...@gluster.org
>> http://www.gluster.org/mailman/listinfo/maintainers
>>
>
>
> --
> Atin
> Sent from iPhone
>
> ___
> maintainers mailing list
> maintain...@gluster.org
> http://www.gluster.org/mailman/listinfo/maintainers
>
>


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

Re: [Gluster-devel] Reducing merge conflicts

2016-07-07 Thread Pranith Kumar Karampuri 
On Fri, Jul 8, 2016 at 8:40 AM, Jeff Darcy  wrote:

> > What gets measured gets managed.
>
> Exactly.  Reviewing is part of everyone's job, but reviews aren't tracked
> in any way that matters.  Contrast that with the *enormous* pressure most
> of us are under to get our own patches in, and it's pretty predictable
> what will happen.  We need to change that calculation.
>
>
> > What I have seen at least is that it is easy to find
> > people who sent patches, how many patches someone sent in a month etc.
> There
> > is no easy way to get these numbers for reviews. 'Reviewed-by' tag in
> commit
> > only includes the people who did +1/+2 on the final revision of the
> patch,
> > which is bad.
>
> That's a very good point.  I think people people who comment also get
> Reviewed-by: lines, but it doesn't matter because there's still a whole
> world of things completely outside of Gerrit.  Reviews done by email won't
> get counted, nor will consultations in the hallway or on IRC.  I have some
> ideas who's most active in those ways.  Some (such as yourself) show up in
> the Reviewed-by: statistics.  Others do not.  In terms of making sure
> people get all the credit they deserve, those things need to be counted
> too.  However, in terms of *getting the review queue unstuck* I'm not so
> sure.  What matters for that is the reviews that Gerrit uses to determine
> merge eligibility, so I think encouraging that specific kind of review
> still moves us in a positive direction.
>

In my experience at least it was only adding 'reviewied-by' for the people
who gave +1/+2 on the final version of the patch

I agree about encouraging specific kind of review. At the same time we need
to make reviewing, helping users in the community as important as sending
patches in the eyes of everyone. It is very important to know these
statistics to move in the right direction. My main problem with this is,
everyone knows that reviews are important, then why are they not happening?
Is it really laziness? Are we sure if there are people in the team who are
not sharing the burden because of which it is becoming too much for 1 or 2
people to handle the total load? All these things become very easy to
reason about if we have this data. Then I am sure we can easily find how
best to solve this issue. Same goes for spurious failures. These are not
problems that are not faced by others in the world either. I remember
watching a video where someone shared (I think it was in google) that they
started putting giant TVs in the hall-way in all the offices and the people
who don't attend to spurious-build-failure problems would show up on the
screen for everyone in the world to see. Apparently the guy with the
biggest picture(the one who was not attending to any build failures at all
I guess) came to these folks and asked how should he get his picture
removed from the screen, and it was solved in a day or two. We don't have
to go to those lengths, but we do need data to nudge people in the right
direction.


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

Re: [Gluster-devel] Reducing merge conflicts

2016-07-07 Thread Pranith Kumar Karampuri 
+Nigel

On Fri, Jul 8, 2016 at 7:42 AM, Pranith Kumar Karampuri  wrote:

> What gets measured gets managed. It is good that you started this thread.
> Problem is two fold. We need a way to first find people who are reviewing a
> lot and give them more karma points in the community by encouraging that
> behaviour(making these stats known to public lets say in monthly news
> letter is one way). It is equally important to review patches when you
> compare it to sending patches. What I have seen at least is that it is easy
> to find people who sent patches, how many patches someone sent in a month
> etc. There is no easy way to get these numbers for reviews. 'Reviewed-by'
> tag in commit only includes the people who did +1/+2 on the final revision
> of the patch, which is bad. So I feel that is the first problem to be
> solved if we have to get better at this. Once I know how I am doing on a
> regular basis in this aspect I am sure I will change my ways to contribute
> better in this aspect. I would love to know what others think about this
> too.
>

Would it be possible for you to get this data using some script may be? I
think we do have apis?


>
> On Fri, Jul 8, 2016 at 2:02 AM, Jeff Darcy  wrote:
>
>> I'm sure a lot of you are pretty frustrated with how long it can take to
>> get even a trivial patch through our Gerrit/Jenkins pipeline.  I know I
>> am.  Slow tests, spurious failures, and bikeshedding over style issues are
>> all contributing factors.  I'm not here to talk about those today.  What I
>> am here to talk about is the difficulty of getting somebody - anybody - to
>> look at a patch and (possibly) give it the votes it needs to be merged.  To
>> put it bluntly, laziness here is *killing* us.  The more patches we have in
>> flight, the more merge conflicts and rebases we have to endure for each
>> one.  It's a quadratic effect.  That's why I personally have been trying
>> really hard to get patches that have passed all regression tests and
>> haven't gotten any other review attention "across the finish line" so they
>> can be merged and removed from conflict with every other patch still in
>> flight.  The search I use for this, every day, is as follows:
>>
>>
>> http://review.gluster.org/#/q/status:open+project:glusterfs+branch:master+label:CentOS-regression%253E0+label:NetBSD-regression%253E0+-label:Code-Review%253C0
>>
>> That is:
>>
>> open patches on glusterfs master (change project/branch as
>> appropriate to your role)
>>
>> CentOS and NetBSD regression tests complete
>>
>> no -1 or -2 votes which might represent legitimate cause for delay
>>
>> If other people - especially team leads and release managers - could make
>> a similar habit of checking the queue and helping to get such "low hanging
>> fruit" out of the way, we might see an appreciable increase in our overall
>> pace of development.  If not, we might have to start talking about
>> mandatory reviews with deadlines and penalties for non-compliance.  I'm
>> sure nobody wants to see their own patches blocked and their own deadlines
>> missed because they weren't doing their part to review peers' work, but
>> that's a distinct possibility.  Let's all try to get this train unstuck and
>> back on track before extreme measures become necessary.
>> ___
>> Gluster-devel mailing list
>> Gluster-devel@gluster.org
>> http://www.gluster.org/mailman/listinfo/gluster-devel
>>
>
>
>
> --
> Pranith
>



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

Re: [Gluster-devel] Reducing merge conflicts

2016-07-07 Thread Jeff Darcy 
> What gets measured gets managed.

Exactly.  Reviewing is part of everyone's job, but reviews aren't tracked
in any way that matters.  Contrast that with the *enormous* pressure most
of us are under to get our own patches in, and it's pretty predictable
what will happen.  We need to change that calculation.


> What I have seen at least is that it is easy to find
> people who sent patches, how many patches someone sent in a month etc. There
> is no easy way to get these numbers for reviews. 'Reviewed-by' tag in commit
> only includes the people who did +1/+2 on the final revision of the patch,
> which is bad.

That's a very good point.  I think people people who comment also get
Reviewed-by: lines, but it doesn't matter because there's still a whole
world of things completely outside of Gerrit.  Reviews done by email won't
get counted, nor will consultations in the hallway or on IRC.  I have some
ideas who's most active in those ways.  Some (such as yourself) show up in
the Reviewed-by: statistics.  Others do not.  In terms of making sure
people get all the credit they deserve, those things need to be counted
too.  However, in terms of *getting the review queue unstuck* I'm not so
sure.  What matters for that is the reviews that Gerrit uses to determine
merge eligibility, so I think encouraging that specific kind of review
still moves us in a positive direction.
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Reducing merge conflicts

2016-07-07 Thread Pranith Kumar Karampuri 
What gets measured gets managed. It is good that you started this thread.
Problem is two fold. We need a way to first find people who are reviewing a
lot and give them more karma points in the community by encouraging that
behaviour(making these stats known to public lets say in monthly news
letter is one way). It is equally important to review patches when you
compare it to sending patches. What I have seen at least is that it is easy
to find people who sent patches, how many patches someone sent in a month
etc. There is no easy way to get these numbers for reviews. 'Reviewed-by'
tag in commit only includes the people who did +1/+2 on the final revision
of the patch, which is bad. So I feel that is the first problem to be
solved if we have to get better at this. Once I know how I am doing on a
regular basis in this aspect I am sure I will change my ways to contribute
better in this aspect. I would love to know what others think about this
too.

On Fri, Jul 8, 2016 at 2:02 AM, Jeff Darcy  wrote:

> I'm sure a lot of you are pretty frustrated with how long it can take to
> get even a trivial patch through our Gerrit/Jenkins pipeline.  I know I
> am.  Slow tests, spurious failures, and bikeshedding over style issues are
> all contributing factors.  I'm not here to talk about those today.  What I
> am here to talk about is the difficulty of getting somebody - anybody - to
> look at a patch and (possibly) give it the votes it needs to be merged.  To
> put it bluntly, laziness here is *killing* us.  The more patches we have in
> flight, the more merge conflicts and rebases we have to endure for each
> one.  It's a quadratic effect.  That's why I personally have been trying
> really hard to get patches that have passed all regression tests and
> haven't gotten any other review attention "across the finish line" so they
> can be merged and removed from conflict with every other patch still in
> flight.  The search I use for this, every day, is as follows:
>
>
> http://review.gluster.org/#/q/status:open+project:glusterfs+branch:master+label:CentOS-regression%253E0+label:NetBSD-regression%253E0+-label:Code-Review%253C0
>
> That is:
>
> open patches on glusterfs master (change project/branch as appropriate
> to your role)
>
> CentOS and NetBSD regression tests complete
>
> no -1 or -2 votes which might represent legitimate cause for delay
>
> If other people - especially team leads and release managers - could make
> a similar habit of checking the queue and helping to get such "low hanging
> fruit" out of the way, we might see an appreciable increase in our overall
> pace of development.  If not, we might have to start talking about
> mandatory reviews with deadlines and penalties for non-compliance.  I'm
> sure nobody wants to see their own patches blocked and their own deadlines
> missed because they weren't doing their part to review peers' work, but
> that's a distinct possibility.  Let's all try to get this train unstuck and
> back on track before extreme measures become necessary.
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel
>



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

[Gluster-devel] iSCSI

2016-07-07 Thread francis Lavalliere 
Hello,

I've been messing around with Gluster FS version 3.7 and 3.8.

Currently i am trying to implement iSCSI with Gluster FS.

I've installed ubuntu 16.04 and have installed various components:

I didnt found any tcmu-runner packages for ubuntu, so i manually built it
using their git repository:

I've tried : cmake . -Dwith-glfs=true  and successfully installed it using
make/make install..

when I do : targetcli ls  i do not see the output of the user:glfs


Here is an example of the output. I've managed to do it via fileio, but
this is not the right way.

targetcli ls

o- */*
.*
[*...*]*

  o- *backstores*
..*
[*...*]*

  | o- *fileio*
...*
[*1 Storage Object*]*

  | | o- *testfs*
..*
[*711.0M, /nfs/testfs.img, in use*]*

  | o- *iblock*
...*
[*0 Storage Object*]*

  | o- *pscsi*
*
[*0 Storage Object*]*

  | o- *rd_mcp*
...*
[*0 Storage Object*]*

  o- *ib_srpt*
...*
[*0 Targets*]*

  o- *iscsi*
..*
[*1 Target*]*

  | o- *iqn.2015-04.com.example:target1*
.*
[*1 TPG*]*

  |   o- *tpg1*
*
[*enabled*]*

  | o- *acls*
...*
[*0 ACLs*]*

  | o- *luns*
*
[*1 LUN*]*

  | | o- *lun0*
*
[*fileio/testfs (/nfs/testfs.img)*]*

  | o- *portals*
..*
[*1 Portal*]*

  |   o- *0.0.0.0:3260 *
...*
[*OK, iser enabled*]*

  o- *loopback*
..*
[*0 Targets*]*

  o- *qla2xxx*
...*
[*0 Targets*]*

  o- *tcm_fc*
*
[*0 Targets*]*

  o- *usb_gadget*
*
[*0 Targets*]*

  o- *vhost*
.*
[*0 Targets*]*


Anyone would know how to make iSCSI target user:glfs show in the targetcli
to be compatible with GlusterFS Directly?


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

[Gluster-devel] Reducing merge conflicts

2016-07-07 Thread Jeff Darcy 
I'm sure a lot of you are pretty frustrated with how long it can take to get 
even a trivial patch through our Gerrit/Jenkins pipeline.  I know I am.  Slow 
tests, spurious failures, and bikeshedding over style issues are all 
contributing factors.  I'm not here to talk about those today.  What I am here 
to talk about is the difficulty of getting somebody - anybody - to look at a 
patch and (possibly) give it the votes it needs to be merged.  To put it 
bluntly, laziness here is *killing* us.  The more patches we have in flight, 
the more merge conflicts and rebases we have to endure for each one.  It's a 
quadratic effect.  That's why I personally have been trying really hard to get 
patches that have passed all regression tests and haven't gotten any other 
review attention "across the finish line" so they can be merged and removed 
from conflict with every other patch still in flight.  The search I use for 
this, every day, is as follows:


http://review.gluster.org/#/q/status:open+project:glusterfs+branch:master+label:CentOS-regression%253E0+label:NetBSD-regression%253E0+-label:Code-Review%253C0

That is:

open patches on glusterfs master (change project/branch as appropriate to 
your role)
 
CentOS and NetBSD regression tests complete

no -1 or -2 votes which might represent legitimate cause for delay

If other people - especially team leads and release managers - could make a 
similar habit of checking the queue and helping to get such "low hanging fruit" 
out of the way, we might see an appreciable increase in our overall pace of 
development.  If not, we might have to start talking about mandatory reviews 
with deadlines and penalties for non-compliance.  I'm sure nobody wants to see 
their own patches blocked and their own deadlines missed because they weren't 
doing their part to review peers' work, but that's a distinct possibility.  
Let's all try to get this train unstuck and back on track before extreme 
measures become necessary.
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [PATCH v2 1/1] block/gluster: add support to choose libgfapi logfile

2016-07-07 Thread Jeff Cody 
On Thu, Jul 07, 2016 at 01:43:50AM +0530, Prasanna Kumar Kalever wrote:
> currently all the libgfapi logs defaults to '/dev/stderr' as it was hardcoded
> in a call to glfs logging api, in case if debug level is chosen to DEBUG/TRACE
> gfapi logs will be huge and fill/overflow the console view.
> 
> this patch provides a commandline option to mention log file path which helps
> in logging to the specified file and also help in persisting the gfapi logs.
> 
> Usage: -drive file=gluster://hostname/volname/image.qcow2,file.debug=9,\
>  file.logfile=/var/log/qemu/qemu-gfapi.log
> 
> Signed-off-by: Prasanna Kumar Kalever 
> ---
> v1: initial patch
> v2: address comments from Jeff Cody, thanks Jeff!

Reviewed-by: Jeff Cody 

> ---
>  block/gluster.c | 39 ---
>  1 file changed, 36 insertions(+), 3 deletions(-)
> 
> diff --git a/block/gluster.c b/block/gluster.c
> index 16f7778..bf6a134 100644
> --- a/block/gluster.c
> +++ b/block/gluster.c
> @@ -24,6 +24,7 @@ typedef struct GlusterAIOCB {
>  typedef struct BDRVGlusterState {
>  struct glfs *glfs;
>  struct glfs_fd *fd;
> +char *logfile;
>  bool supports_seek_data;
>  int debug_level;
>  } BDRVGlusterState;
> @@ -34,6 +35,7 @@ typedef struct GlusterConf {
>  char *volname;
>  char *image;
>  char *transport;
> +char *logfile;
>  int debug_level;
>  } GlusterConf;
>  
> @@ -44,6 +46,7 @@ static void qemu_gluster_gconf_free(GlusterConf *gconf)
>  g_free(gconf->volname);
>  g_free(gconf->image);
>  g_free(gconf->transport);
> +g_free(gconf->logfile);
>  g_free(gconf);
>  }
>  }
> @@ -181,7 +184,8 @@ static struct glfs *qemu_gluster_init(GlusterConf *gconf, 
> const char *filename,
>  ret = qemu_gluster_parseuri(gconf, filename);
>  if (ret < 0) {
>  error_setg(errp, "Usage: file=gluster[+transport]://[server[:port]]/"
> -   "volname/image[?socket=...]");
> +   "volname/image[?socket=...][,file.debug=N]"
> +   "[,file.logfile=/path/filename.log]");
>  errno = -ret;
>  goto out;
>  }
> @@ -197,7 +201,7 @@ static struct glfs *qemu_gluster_init(GlusterConf *gconf, 
> const char *filename,
>  goto out;
>  }
>  
> -ret = glfs_set_logging(glfs, "-", gconf->debug_level);
> +ret = glfs_set_logging(glfs, gconf->logfile, gconf->debug_level);
>  if (ret < 0) {
>  goto out;
>  }
> @@ -256,6 +260,8 @@ static void gluster_finish_aiocb(struct glfs_fd *fd, 
> ssize_t ret, void *arg)
>  }
>  
>  #define GLUSTER_OPT_FILENAME "filename"
> +#define GLUSTER_OPT_LOGFILE "logfile"
> +#define GLUSTER_LOGFILE_DEFAULT "-" /* '-' handled in libgfapi as 
> /dev/stderr */
>  #define GLUSTER_OPT_DEBUG "debug"
>  #define GLUSTER_DEBUG_DEFAULT 4
>  #define GLUSTER_DEBUG_MAX 9
> @@ -271,6 +277,11 @@ static QemuOptsList runtime_opts = {
>  .help = "URL to the gluster image",
>  },
>  {
> +.name = GLUSTER_OPT_LOGFILE,
> +.type = QEMU_OPT_STRING,
> +.help = "Logfile path of libgfapi",
> +},
> +{
>  .name = GLUSTER_OPT_DEBUG,
>  .type = QEMU_OPT_NUMBER,
>  .help = "Gluster log level, valid range is 0-9",
> @@ -327,7 +338,7 @@ static int qemu_gluster_open(BlockDriverState *bs,  QDict 
> *options,
>  GlusterConf *gconf = g_new0(GlusterConf, 1);
>  QemuOpts *opts;
>  Error *local_err = NULL;
> -const char *filename;
> +const char *filename, *logfile;
>  
>  opts = qemu_opts_create(_opts, NULL, 0, _abort);
>  qemu_opts_absorb_qdict(opts, options, _err);
> @@ -339,6 +350,15 @@ static int qemu_gluster_open(BlockDriverState *bs,  
> QDict *options,
>  
>  filename = qemu_opt_get(opts, GLUSTER_OPT_FILENAME);
>  
> +logfile = qemu_opt_get(opts, GLUSTER_OPT_LOGFILE);
> +if (logfile) {
> +s->logfile = g_strdup(logfile);
> +} else {
> +s->logfile = g_strdup(GLUSTER_LOGFILE_DEFAULT);
> +}
> +
> +gconf->logfile = g_strdup(s->logfile);
> +
>  s->debug_level = qemu_opt_get_number(opts, GLUSTER_OPT_DEBUG,
>   GLUSTER_DEBUG_DEFAULT);
>  if (s->debug_level < 0) {
> @@ -386,6 +406,7 @@ out:
>  if (!ret) {
>  return ret;
>  }
> +g_free(s->logfile);
>  if (s->fd) {
>  glfs_close(s->fd);
>  }
> @@ -422,6 +443,7 @@ static int qemu_gluster_reopen_prepare(BDRVReopenState 
> *state,
>  
>  gconf = g_new0(GlusterConf, 1);
>  
> +gconf->logfile = g_strdup(s->logfile);
>  gconf->debug_level = s->debug_level;
>  reop_s->glfs = qemu_gluster_init(gconf, state->bs->filename, errp);
>  if (reop_s->glfs == NULL) {
> @@ -556,6 +578,11 @@ static int qemu_gluster_create(const char *filename,
>  char *tmp = NULL;
>  GlusterConf *gconf = g_new0(GlusterConf,

[Gluster-devel] Preparing to release glusterfs-3.8.1

2016-07-07 Thread Niels de Vos 
Hi,

The tagging and release of glusterfs-3.8.1 is scheduled for tomorrow
morning (Friday morning, in Amsterdam). There are still some patches
under review, but until they have at least a +1 from an additional
developer that is familiar with the component I'm not merging them.
Maintainers of the component may do so at their leisure. Let me know if
there is anything important outstanding though.

Patches:
  http://review.gluster.org/#/q/project:glusterfs+branch:release-3.8+status:open

Tracker with blocking bugs:
  
https://bugzilla.redhat.com/showdependencytree.cgi?id=glusterfs-3.8.1=1_resolved=1

At the moment, only one major bug does not have its patch merged yet:
  https://bugzilla.redhat.com/show_bug.cgi?id=1336376
  Sequential volume start is failing with SSL enabled setup

If the patch is not merged when I tag the release, I'll move the bug to
the glusterfs-3.8.2 tracker.

Thanks,
Niels


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

Re: [Gluster-devel] [Gluster-Maintainers] Glusterfs-3.7.13 release plans

2016-07-07 Thread Atin Mukherjee 
Can you take in http://review.gluster.org/#/c/14861 ?

On Thursday 7 July 2016, Kaushal M  wrote:

> On Thu, Jun 30, 2016 at 11:08 AM, Kaushal M  > wrote:
> > Hi all,
> >
> > I'm (or was) planning to do a 3.7.13 release on schedule today. 3.7.12
> > has a huge issue with libgfapi, solved by [1].
> > I'm not sure if this fixes the other issues with libgfapi noticed by
> > Lindsay on gluster-users.
> >
> > This patch has been included in the packages 3.7.12 built for CentOS,
> > Fedora, Ubuntu, Debian and SUSE. I guess Lindsay is using one of these
> > packages, so it might be that the issue seen is new. So I'd like to do
> > a quick release once we have a fix.
> >
> > Maintainers can merge changes into release-3.7 that follow the
> > criteria given in [2]. Please make sure to add the bugs for patches
> > you are merging are added as dependencies for the 3.7.13 tracker bug
> > [3].
> >
>
> I've just merged the fix for the gfapi breakage into release-3.7, and
> hope to tag 3.7.13 soon.
>
> The current head for release-3.7 is commit bddf6f8. 18 patches have
> been merged since 3.7.12 for the following components,
>  - gfapi
>  - nfs (includes ganesha related changes)
>  - glusterd/cli
>  - libglusterfs
>  - fuse
>  - build
>  - geo-rep
>  - afr
>
> I need and acknowledgement from the maintainers of the above
> components that they are ready.
> If any maintainers know of any other issues, please reply here. We'll
> decide how to address them for this release here.
>
> Also, please don't merge anymore changes into release-3.7. If you need
> to get something merged, please inform me.
>
> Thanks,
> Kaushal
>
> > Thanks,
> > Kaushal
> >
> > [1]: https://review.gluster.org/14822
> > [2]: https://public.pad.fsfe.org/p/glusterfs-release-process-201606
> > under the GlusterFS minor release heading
> > [3]: https://bugzilla.redhat.com/show_bug.cgi?id=glusterfs-3.7.13
> ___
> maintainers mailing list
> maintain...@gluster.org 
> http://www.gluster.org/mailman/listinfo/maintainers
>


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

Re: [Gluster-devel] Glusterfs-3.7.13 release plans

2016-07-07 Thread Kaushal M 
On Thu, Jun 30, 2016 at 11:08 AM, Kaushal M  wrote:
> Hi all,
>
> I'm (or was) planning to do a 3.7.13 release on schedule today. 3.7.12
> has a huge issue with libgfapi, solved by [1].
> I'm not sure if this fixes the other issues with libgfapi noticed by
> Lindsay on gluster-users.
>
> This patch has been included in the packages 3.7.12 built for CentOS,
> Fedora, Ubuntu, Debian and SUSE. I guess Lindsay is using one of these
> packages, so it might be that the issue seen is new. So I'd like to do
> a quick release once we have a fix.
>
> Maintainers can merge changes into release-3.7 that follow the
> criteria given in [2]. Please make sure to add the bugs for patches
> you are merging are added as dependencies for the 3.7.13 tracker bug
> [3].
>

I've just merged the fix for the gfapi breakage into release-3.7, and
hope to tag 3.7.13 soon.

The current head for release-3.7 is commit bddf6f8. 18 patches have
been merged since 3.7.12 for the following components,
 - gfapi
 - nfs (includes ganesha related changes)
 - glusterd/cli
 - libglusterfs
 - fuse
 - build
 - geo-rep
 - afr

I need and acknowledgement from the maintainers of the above
components that they are ready.
If any maintainers know of any other issues, please reply here. We'll
decide how to address them for this release here.

Also, please don't merge anymore changes into release-3.7. If you need
to get something merged, please inform me.

Thanks,
Kaushal

> Thanks,
> Kaushal
>
> [1]: https://review.gluster.org/14822
> [2]: https://public.pad.fsfe.org/p/glusterfs-release-process-201606
> under the GlusterFS minor release heading
> [3]: https://bugzilla.redhat.com/show_bug.cgi?id=glusterfs-3.7.13
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

[Gluster-devel] GlusterFS linux-AIO bug

2016-07-07 Thread Keiviw 
hi,
I have some problems about linux-AIO. I have installed GlusterFS 3.6.7 
because of its stability, and mounted to /mnt/glusterfs. When I excute "vi 
/mnt/glusterfs/test.txt", it was ok and I wrote something successfully. But 
when I changed the code in xlators/protocol/client/src/client.copen() and 
create() for adding O_DIRECT flag, like this, flags |= O_DIRECT. Here comes the 
problem.
1. When I copyed a non-empty file to /mnt/glusterfs, it was failed.
2. When I touch a file "test.txt", it was ok. And then "vi 
/mnt/glusterfs/test.txt", I wrote something unsuccessfully, the error was 
"E667,fsync failed".
3. I have notice the bug in GlsuterFS 3.3.*, 
https://bugzilla.redhat.com/show_bug.cgi?id=837495, it was fixed??
4, Storage.linux-aio on would exist the same error.___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

[Gluster-devel] Updating Jenkins with Jenkins

2016-07-07 Thread Nigel Babu 
Hello folks,

As you have read from my emails over this month, I'm going to have Jenkins jobs
generated from JJB. I'm going to go one step further. I'm going to move the
repo[1] into Gerrit. One successful merge on Gerrit, it will update Jenkins.
I'll do a sync from Gerrit to Github for this repo.

I'm not a big fan of the Gerrit interface, but I believe this is the right way
forward.

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