Re: [Gluster-devel] Release 4.1: LTM release targeted for end of May

[Kotresh Hiremath Ravishankar]

Hi Shyam,

Rafi and Me are proposing consistent time across replica feature for 4.1

https://github.com/gluster/glusterfs/issues/208

Thanks,
Kotresh H R

On Wed, Mar 21, 2018 at 2:05 PM, Ravishankar N 
wrote:

>
>
> On 03/20/2018 07:07 PM, Shyam Ranganathan wrote:
>
>> On 03/12/2018 09:37 PM, Shyam Ranganathan wrote:
>>
>>> Hi,
>>>
>>> As we wind down on 4.0 activities (waiting on docs to hit the site, and
>>> packages to be available in CentOS repositories before announcing the
>>> release), it is time to start preparing for the 4.1 release.
>>>
>>> 4.1 is where we have GD2 fully functional and shipping with migration
>>> tools to aid Glusterd to GlusterD2 migrations.
>>>
>>> Other than the above, this is a call out for features that are in the
>>> works for 4.1. Please *post* the github issues to the *devel lists* that
>>> you would like as a part of 4.1, and also mention the current state of
>>> development.
>>>
>> Thanks for those who responded. The github lane and milestones for the
>> said features are updated, request those who mentioned issues being
>> tracked for 4.1 check that these are reflected in the project lane [1].
>>
>> I have few requests as follows that if picked up would be a good thing
>> to achieve by 4.1, volunteers welcome!
>>
>> - Issue #224: Improve SOS report plugin maintenance
>>- https://github.com/gluster/glusterfs/issues/224
>>
>> - Issue #259: Compilation warnings with gcc 7.x
>>- https://github.com/gluster/glusterfs/issues/259
>>
>> - Issue #411: Ensure python3 compatibility across code base
>>- https://github.com/gluster/glusterfs/issues/411
>>
>> - NFS Ganesha HA (storhaug)
>>- Does this need an issue for Gluster releases to track? (maybe
>> packaging)
>>
>> I will close the call for features by Monday 26th Mar, 2018. Post this,
>> I would request that features that need to make it into 4.1 be raised as
>> exceptions to the devel and maintainers list for evaluation.
>>
>
> Hi Shyam,
>
> I want to add https://github.com/gluster/glusterfs/issues/363 also for
> 4.1. It is not a new feature but rather an enhancement to a volume option
> in AFR. I don't think it can qualify as a bug fix, so mentioning it here
> just in case it needs to be tracked too. The (only) patch is undergoing
> review cycles.
>
> Regards,
> Ravi
>
>
>> Further, as we hit end of March, we would make it mandatory for features
>>> to have required spec and doc labels, before the code is merged, so
>>> factor in efforts for the same if not already done.
>>>
>>> Current 4.1 project release lane is empty! I cleaned it up, because I
>>> want to hear from all as to what content to add, than add things marked
>>> with the 4.1 milestone by default.
>>>
>> [1] 4.1 Release lane:
>> https://github.com/gluster/glusterfs/projects/1#column-1075416
>>
>> Thanks,
>>> Shyam
>>> P.S: Also any volunteers to shadow/participate/run 4.1 as a release
>>> owner?
>>>
>> Calling this out again!
>>
>> ___
>>> Gluster-devel mailing list
>>> Gluster-devel@gluster.org
>>> http://lists.gluster.org/mailman/listinfo/gluster-devel
>>>
>>> ___
>> Gluster-devel mailing list
>> Gluster-devel@gluster.org
>> http://lists.gluster.org/mailman/listinfo/gluster-devel
>>
>
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://lists.gluster.org/mailman/listinfo/gluster-devel
>



-- 
Thanks and Regards,
Kotresh H R
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

[Gluster-devel] Coverity covscan for 2018-03-21-448dec70 (master branch)

[staticanalysis]

GlusterFS Coverity covscan results are available from
http://download.gluster.org/pub/gluster/glusterfs/static-analysis/master/glusterfs-coverity/2018-03-21-448dec70
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

[Gluster-devel] Request For Opinions: what to do about the synthetic statfvs "tweak"?

[Csaba Henk]

Hi list,

We have an ancient hack that fuse not
just passes on the statvfs data it's getting
from the storage, but tweaks it by setting
f_bsize / f_frsize to values of its own
preference. [1]

The supposed advantage is that f_bsize
serves as a hint to applications for the
preferred io size. (And regarding f_frsize --
in Linux it's a historical workaround for
certain bugs in userspace[2] that f_bsize
and f_frsize are being kept equal.)

However, this has the side effect of
getting slightly different values for total
and used/free space of a volume when
accessed through libgfapi and when through
fuse -- because these values are multiples
of f_frsize, and libgfapi uses the native f_frsize
of the backend (typically 4k), while fuse provides
its synthetic f_frsize (typically 128k). So the
libfgapi provided sizes are more granular.

OTOH, I couldn't find any program in
standard Unix userspace where the
implementation commonly used in GNU/Linux
would rely on the f_bsize hint. It does not
mean there is none -- and then there is of course
the vast space of non-standard userland.

Possibiliities are:

1) retire the whole tweak and just pass on
   what we get from storage [3]
2) keep the f_bsize tweak, but drop the
   of f_frsize == f_bsize legacy workaround
   and take f_frsize from storage
3) keep everything as is, and put up with the
   fs stat divergence between transports
+1) make behaviors of 1) to 3) tunable --
  but I would not like to go this way in
  the spirit of KISS, unless absolutely a
  demand

Developers: do you know of any scenario where
we benefit from the f_bsize tweak?

Users:
- do you have any application that relies on f_bsize
  and benefits from its custom value?
- do you have any legacy application/stack
  where the f_frsize == f_bsize workaround is
  still needed (but GlusterFS  / RHGS is being kept
  up to date, so a change in this regard would hit
  your setup)?

Thanks for your thoughts!

Regards,
Csaba

[1]: 
https://github.com/gluster/glusterfs/blob/v4.0.0/xlators/mount/fuse/src/fuse-bridge.c#L3177-L3189
[2]: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=11406
[3] practically this will also imply f_frsize == f_bsize, because
 Linux filesystems usually adhere to this convention
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Release 4.1: LTM release targeted for end of May

[Ravishankar N]

On 03/20/2018 07:07 PM, Shyam Ranganathan wrote:

On 03/12/2018 09:37 PM, Shyam Ranganathan wrote:

Hi,

As we wind down on 4.0 activities (waiting on docs to hit the site, and
packages to be available in CentOS repositories before announcing the
release), it is time to start preparing for the 4.1 release.

4.1 is where we have GD2 fully functional and shipping with migration
tools to aid Glusterd to GlusterD2 migrations.

Other than the above, this is a call out for features that are in the
works for 4.1. Please *post* the github issues to the *devel lists* that
you would like as a part of 4.1, and also mention the current state of
development.

Thanks for those who responded. The github lane and milestones for the
said features are updated, request those who mentioned issues being
tracked for 4.1 check that these are reflected in the project lane [1].

I have few requests as follows that if picked up would be a good thing
to achieve by 4.1, volunteers welcome!

- Issue #224: Improve SOS report plugin maintenance
   - https://github.com/gluster/glusterfs/issues/224

- Issue #259: Compilation warnings with gcc 7.x
   - https://github.com/gluster/glusterfs/issues/259

- Issue #411: Ensure python3 compatibility across code base
   - https://github.com/gluster/glusterfs/issues/411

- NFS Ganesha HA (storhaug)
   - Does this need an issue for Gluster releases to track? (maybe packaging)

I will close the call for features by Monday 26th Mar, 2018. Post this,
I would request that features that need to make it into 4.1 be raised as
exceptions to the devel and maintainers list for evaluation.


Hi Shyam,

I want to add https://github.com/gluster/glusterfs/issues/363 also for 
4.1. It is not a new feature but rather an enhancement to a volume 
option in AFR. I don't think it can qualify as a bug fix, so mentioning 
it here just in case it needs to be tracked too. The (only) patch is 
undergoing review cycles.


Regards,
Ravi



Further, as we hit end of March, we would make it mandatory for features
to have required spec and doc labels, before the code is merged, so
factor in efforts for the same if not already done.

Current 4.1 project release lane is empty! I cleaned it up, because I
want to hear from all as to what content to add, than add things marked
with the 4.1 milestone by default.

[1] 4.1 Release lane:
https://github.com/gluster/glusterfs/projects/1#column-1075416


Thanks,
Shyam
P.S: Also any volunteers to shadow/participate/run 4.1 as a release owner?

Calling this out again!


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


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


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

Re: [Gluster-devel] [Gluster-Maintainers] Proposal to change the version numbers of Gluster project

[Amar Tumballi]

With all this discussion, I see that there are no serious concerns about
release numbers.

Should we go ahead and say that from 4-1.Next release, our names would be
Gluster 5.0.0, Gluster 6.0.0 or Gluster 2018.10, Gluster 2019.02 ?

Regards,
Amar

On Fri, Mar 16, 2018 at 5:58 PM, Atin Mukherjee  wrote:

>
>
> On Fri, Mar 16, 2018 at 11:03 AM, Vijay Bellur  wrote:
>
>>
>>
>> On Wed, Mar 14, 2018 at 9:48 PM, Atin Mukherjee 
>> wrote:
>>
>>>
>>>
>>> On Thu, Mar 15, 2018 at 9:45 AM, Vijay Bellur 
>>> wrote:
>>>


 On Wed, Mar 14, 2018 at 5:40 PM, Shyam Ranganathan  wrote:

> On 03/14/2018 07:04 PM, Joe Julian wrote:
> >
> >
> > On 03/14/2018 02:25 PM, Vijay Bellur wrote:
> >>
> >>
> >> On Tue, Mar 13, 2018 at 4:25 AM, Kaleb S. KEITHLEY
> >> > wrote:
> >>
> >> On 03/12/2018 02:32 PM, Shyam Ranganathan wrote:
> >> > On 03/12/2018 10:34 AM, Atin Mukherjee wrote:
> >> >>   *
> >> >>
> >> >> After 4.1, we want to move to either continuous
> >> numbering (like
> >> >> Fedora), or time based (like ubuntu etc) release
> >> numbers. Which
> >> >> is the model we pick is not yet finalized. Happy to
> >> hear opinions.
> >> >>
> >> >>
> >> >> Not sure how the time based release numbers would make more
> >> sense than
> >> >> the one which Fedora follows. But before I comment further on
> >> this I
> >> >> need to first get a clarity on how the op-versions will be
> >> managed. I'm
> >> >> assuming once we're at GlusterFS 4.1, post that the releases
> >> will be
> >> >> numbered as GlusterFS5, GlusterFS6 ... So from that
> >> perspective, are we
> >> >> going to stick to our current numbering scheme of op-version
> >> where for
> >> >> GlusterFS5 the op-version will be 5?
> >> >
> >> > Say, yes.
> >> >
> >> > The question is why tie the op-version to the release number?
> That
> >> > mental model needs to break IMO.
> >> >
> >> > With current options like,
> >> > https://docs.gluster.org/en/latest/Upgrade-Guide/op_version/
> >> 
> it is
> >> > easier to determine the op-version of the cluster and what it
> >> should be,
> >> > and hence this need not be tied to the gluster release
> version.
> >> >
> >> > Thoughts?
> >>
> >> I'm okay with that, but——
> >>
> >> Just to play the Devil's Advocate, having an op-version that
> bears
> >> some
> >> resemblance to the _version_ number may make it easy/easier to
> >> determine
> >> what the op-version ought to be.
> >>
> >> We aren't going to run out of numbers, so there's no reason to
> be
> >> "efficient" here. Let's try to make it easy. (Easy to not make a
> >> mistake.)
> >>
> >> My 2¢
> >>
> >>
> >> +1 to the overall release cadence change proposal and what Kaleb
> >> mentions here.
> >>
> >> Tying op-versions to release numbers seems like an easier approach
> >> than others & one to which we are accustomed to. What are the
> benefits
> >> of breaking this model?
> >>
> > There is a bit of confusion among the user base when a release
> happens
> > but the op-version doesn't have a commensurate bump. People ask why
> they
> > can't set the op-version to match the gluster release version they
> have
> > installed. If it was completely disconnected from the release
> version,
> > that might be a great enough mental disconnect that the expectation
> > could go away which would actually cause less confusion.
>
> Above is the reason I state it as well (the breaking of the mental
> model
> around this), why tie it together when it is not totally related. I
> also
> agree that, the notion is present that it is tied together and hence
> related, but it may serve us better to break it.
>
>

 I see your perspective. Another related reason for not introducing an
 op-version bump in a new release would be that there are no incompatible
 features introduced (in the new release). Hence it makes sense to preserve
 the older op-version.

 To make everyone's lives simpler, would it be useful to introduce a
 command that provides the max op-version to release number mapping? The
 output of the command could look like:

 op-version X: 3.7.0 to 3.7.11
 op-version Y: 3.7.12 to x.y.z

>>>
>>> We already have 

Re: [Gluster-devel] [Gluster-Maintainers] Release 4.1: LTM release targeted for end of May

[Amar Tumballi]

On Tue, Mar 13, 2018 at 7:07 AM, Shyam Ranganathan 
wrote:

> Hi,
>
> As we wind down on 4.0 activities (waiting on docs to hit the site, and
> packages to be available in CentOS repositories before announcing the
> release), it is time to start preparing for the 4.1 release.
>
> 4.1 is where we have GD2 fully functional and shipping with migration
> tools to aid Glusterd to GlusterD2 migrations.
>
> Other than the above, this is a call out for features that are in the
> works for 4.1. Please *post* the github issues to the *devel lists* that
> you would like as a part of 4.1, and also mention the current state of
> development.
>
> Further, as we hit end of March, we would make it mandatory for features
> to have required spec and doc labels, before the code is merged, so
> factor in efforts for the same if not already done.
>
> Current 4.1 project release lane is empty! I cleaned it up, because I
> want to hear from all as to what content to add, than add things marked
> with the 4.1 milestone by default.
>
>
I would like to see we have sane default values for most of the options, or
have group options for many use-cases.

Also want to propose that,  we include a release of
http://github.com/gluster/gluster-health-report with 4.1, and make the
project more usable.

Also, we see that some of the patches from FB branch on namespace and
throttling are in, so we would like to call that feature out as
experimental by then.

Regards,
Amar


> Thanks,
> Shyam
> P.S: Also any volunteers to shadow/participate/run 4.1 as a release owner?
> ___
> maintainers mailing list
> maintain...@gluster.org
> http://lists.gluster.org/mailman/listinfo/maintainers
>



-- 
Amar Tumballi (amarts)
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-Maintainers] Release 4.1: LTM release targeted for end of May

[Amar Tumballi]

Sorry, couldn't respond earlier.


On Fri, Mar 16, 2018 at 7:14 AM, Pranith Kumar Karampuri <
pkara...@redhat.com> wrote:

>
>
> On Wed, Mar 14, 2018 at 8:27 PM, Amye Scavarda  wrote:
>
>> Responding on the architects question:
>>
>> On Tue, Mar 13, 2018 at 9:57 PM, Pranith Kumar Karampuri <
>> pkara...@redhat.com> wrote:
>>
>>>
>>>
>>> On Tue, Mar 13, 2018 at 4:26 PM, Pranith Kumar Karampuri <
>>> pkara...@redhat.com> wrote:
>>>


 On Tue, Mar 13, 2018 at 1:51 PM, Amar Tumballi 
 wrote:

> >>
>> >> Further, as we hit end of March, we would make it mandatory for
>> features
>> >> to have required spec and doc labels, before the code is merged, so
>> >> factor in efforts for the same if not already done.
>> >
>> >
>> > Could you explain the point above further? Is it just the label or
>> the
>> > spec/doc
>> > that we need merged before the patch is merged?
>> >
>>
>> I'll hazard a guess that the intent of the label is to indicate
>> availability of the doc. "Completeness" of code is being defined as
>> including specifications and documentation.
>>
>>
> I believe this has originated from maintainers meeting agreements [1]
> . The proposal to make a spec and documentation mandatory was submitted 3
> months back and is documented, and submitted for comment @
> https://docs.google.com/document/d/1AFkZmRRDXRxs21GnGauieI
> yiIiRZ-nTEW8CPi7Gbp3g/edit?usp=sharing
>
>
 Thanks! This clears almost all the doubts I had :).

>>>
>>> The document above refers to Architects - "Now Architects are approved
>>> to revert a patch which violates by either not having github issue nor
>>> bug-id, or uses a bug-id to get the feature in etc."
>>>
>>> Who are they? What are their responsibilities?
>>>
>>
>> In our last reboot of the maintainers readme file, we expanded the
>> architects role:
>> https://github.com/gluster/glusterfs/blob/master/MAINTAINERS
>> General Project Architects
>> --
>> M: Jeff Darcy 
>> M: Vijay Bellur 
>> P: Amar Tumballi 
>> P: Pranith Karampuri 
>> P: Raghavendra Gowdappa 
>> P: Shyamsundar Ranganathan 
>> P: Niels de Vos 
>> P: Xavier Hernandez 
>> What should we work to make more clear about this?
>>
>
> Wow, embarrassing, I am an architect who doesn't know his
> responsibilities. Could you let me know where I could find them?
>

We had some email conversations at this thread: http://lists.gluster.
org/pipermail/gluster-devel/2017-March/052321.html

Final version of the discussion is captured here: https://hackmd.io/s/
SkwiZd4qe. and the patch for the changes was merged
with more than 20 votes (including yours) on it @
https://review.gluster.org/#/c/17583

Regards,
Amar




>
>
>> - amye
>>
>>
>>>
>>>


> The idea is, if the code is going to be released, it should have
> relevant documentation for users to use it, otherwise, it doesn't matter 
> if
> the feature is present or not. If the feature is 'default', and there is 
> no
> documentation required, just mention it, so the flags can be given. Also,
> if there is no general agreement about the design, it doesn't make sense 
> to
> merge a feature and then someone has to redo things.
>
> For any experimental code, which we want to publish for other
> developers to test, who doesn't need documentation, we have 'experimental'
> branch, which should be used for validation.
>

>  [1] - http://lists.gluster.org/pipermail/gluster-devel/2017-Dece
> mber/054070.html
>



 --
 Pranith

>>>
>>>
>>>
>>> --
>>> Pranith
>>>
>>> ___
>>> Gluster-devel mailing list
>>> Gluster-devel@gluster.org
>>> http://lists.gluster.org/mailman/listinfo/gluster-devel
>>>
>>
>>
>>
>> --
>> Amye Scavarda | a...@redhat.com | Gluster Community Lead
>>
>
>
>
> --
> Pranith
>



-- 
Amar Tumballi (amarts)
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-Maintainers] Release 4.1: LTM release targeted for end of May

[Raghavendra Gowdappa]

Proposing efforts of adding metrics to various perf xlators. Following are
links to github issues:

https://github.com/gluster/glusterfs/issues/422
https://github.com/gluster/glusterfs/issues/423
https://github.com/gluster/glusterfs/issues/424
https://github.com/gluster/glusterfs/issues/425
https://github.com/gluster/glusterfs/issues/426
https://github.com/gluster/glusterfs/issues/427
https://github.com/gluster/glusterfs/issues/428
https://github.com/gluster/glusterfs/issues/429

regards,
Raghavendra

On Wed, Mar 21, 2018 at 10:29 AM, Jiffin Tony Thottan 
wrote:

> Hi,
>
> I would like to (rep)propose lease support https://github.com/gluster/glu
> sterfs/issues/350
>
> Current status
>
> Following patches posted :
>
> https://review.gluster.org/#/c/19568/ -- gfapi recall lease
>
> https://review.gluster.org/#/c/12496/ -- test case
>
> https://review.gluster.org/#/c/11721/ -- add lease fop for afr
>
> need to sent a patch for adding lease fop in ec
>
> + I have patch for bug fixes in current lease implementation
>
> Regards,
>
> Jiffin
>
>
> On Tuesday 13 March 2018 07:07 AM, Shyam Ranganathan wrote:
>
>> Hi,
>>
>> As we wind down on 4.0 activities (waiting on docs to hit the site, and
>> packages to be available in CentOS repositories before announcing the
>> release), it is time to start preparing for the 4.1 release.
>>
>> 4.1 is where we have GD2 fully functional and shipping with migration
>> tools to aid Glusterd to GlusterD2 migrations.
>>
>> Other than the above, this is a call out for features that are in the
>> works for 4.1. Please *post* the github issues to the *devel lists* that
>> you would like as a part of 4.1, and also mention the current state of
>> development.
>>
>> Further, as we hit end of March, we would make it mandatory for features
>> to have required spec and doc labels, before the code is merged, so
>> factor in efforts for the same if not already done.
>>
>> Current 4.1 project release lane is empty! I cleaned it up, because I
>> want to hear from all as to what content to add, than add things marked
>> with the 4.1 milestone by default.
>>
>> Thanks,
>> Shyam
>> P.S: Also any volunteers to shadow/participate/run 4.1 as a release owner?
>> ___
>> Gluster-devel mailing list
>> Gluster-devel@gluster.org
>> http://lists.gluster.org/mailman/listinfo/gluster-devel
>>
>
> ___
> maintainers mailing list
> maintain...@gluster.org
> http://lists.gluster.org/mailman/listinfo/maintainers
>
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel