Re: [Gluster-devel] Coverity covscan for 2018-07-20-8d7be4ac (master branch)

[Kaleb S. KEITHLEY]

On 07/20/2018 05:18 PM, staticanaly...@gluster.org wrote:
> 
> GlusterFS Coverity covscan results for the master branch are available from
> http://download.gluster.org/pub/gluster/glusterfs/static-analysis/master/glusterfs-coverity/2018-07-20-8d7be4ac/
> 
> Coverity covscan results for other active branches are also available at
> http://download.gluster.org/pub/gluster/glusterfs/static-analysis/
> 

FYI, as of this alert, Coverity has been updated to cov-sa2018-06.

--

Kaleb

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

[Gluster-devel] Coverity covscan for 2018-07-20-8d7be4ac (master branch)

[staticanalysis]

GlusterFS Coverity covscan results for the master branch are available from
http://download.gluster.org/pub/gluster/glusterfs/static-analysis/master/glusterfs-coverity/2018-07-20-8d7be4ac/

Coverity covscan results for other active branches are also available at
http://download.gluster.org/pub/gluster/glusterfs/static-analysis/

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

[Gluster-devel] Coverity covscan for 2018-07-20-ea4964df (master branch)

[staticanalysis]

GlusterFS Coverity covscan results for the master branch are available from
http://download.gluster.org/pub/gluster/glusterfs/static-analysis/master/glusterfs-coverity/2018-07-20-ea4964df/

Coverity covscan results for other active branches are also available at
http://download.gluster.org/pub/gluster/glusterfs/static-analysis/

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

[Gluster-devel] Postmortem for Jenkins Outage on 20/07/18

[Nigel Babu]

Hello folks,

I had to take down Jenkins for some time today. The server ran out of space
and was silently ignoring Gerrit requests for new jobs. If you think one of
your jobs needed a smoke or regression run and it wasn't triggered, this is
the root cause. Please retrigger your jobs.

## Summary of Impact
Jenkins jobs not triggered intermittently in the last couple of days. At
the moment, we do not have numbers on how many developers were affected by
this. This would be mitigated slightly every day due to the rotation rules
we have in place causing issues only around evening IST when we retrigger
our regular nightly jobs.

## Timeline of Events.
July 19 evening: I've noticed since yesterday that occasionally Jenkins
would not trigger a job for a push. This was on the build-jobs repo. I
chalked it to a signal getting lost in the noise and decided to debug
later. I could trigger it manually, so I put as a thing to do in the
morning. Today morning, I found that jobs are getting triggered as they
should and could not notice anything untoward.

July 20 6:41 pm: Kotresh pinged me asking if there was a problem. I could
see the problem I noticed yesterday in his job. This time a manual trigger
did not work. Around the same time Raghavendra Gowdappa also hit the same
problem. I logged into the server to notice that the Jenkins partition was
out of space.

July 20 7:40 pm: Jenkins is back online completely. A retrigger of the two
failing jobs have been successful.

## Root Cause
* Out of disk space on the Jenkins partition on build.gluster.org
* The bugzilla-post did not delete old jobs and we had about 7000 jobs in
there consuming about 20G of space.
* clang-scan job consumes about 1G per job and we were storing about 30
days worth of archives.

## Resolution
* All centos6-regression jobs are now deleted. We moved over to
centos7-regression a while ago.
* We now only store 7 days of archives for bugzilla-post and clang-scan jobs

## Future Recommendation
* Our monitoring did not alert us about the disk being filled up on the
Jenkins node. Ideally, we should have gotten a warning when we were at
least 90% full so we could plan for additional capacity or look for
mistakes in patterns.
* All jobs need to have a property that discards old runs with the maxmium
of 90 days being kept in case it's absolutely needed. This is currently not
enforced by CI but we will plan to enforce it in the future.

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

Re: [Gluster-devel] [Gluster-infra] [FYI] GitHub connectivity issues

[Michael Scherer]

Le vendredi 20 juillet 2018 à 16:10 +0530, Nigel Babu a écrit :
> Hello folks,
> 
> Our infra also runs in the same network, so if you notice issues,
> they're
> most likely related to the same network issues.

Seems to have been maybe on github side:
https://status.github.com/messages


> -- Forwarded message -
> From: Fabian Arrotin 
> Date: Fri, Jul 20, 2018 at 12:49 PM
> Subject: [Ci-users] [FYI] GitHub connectivity issue
> To: ci-us...@centos.org 
> 
> 
> Hi,
> 
> Just to let all Projects using CI that our monitoring complained a
> lot
> about "flapping" connectivity to some external nodes, including
> github.com.
> After some investigations, it seems that there are some peering
> issues
> (or routing) at Level3, but errors come and go.
> 
> We can't do anything but report internally and see if then error can
> be
> reported "upstream" at the link provider level.
> 
> So this message is more about the fact that if your tests are having
> issues with some external connectivity, that can be related to that
> issue.
> 
> -- 
> Fabian Arrotin
> The CentOS Project | https://www.centos.org
> gpg key: 56BEC54E | twitter: @arrfab
> 
> ___
> Ci-users mailing list
> ci-us...@centos.org
> https://lists.centos.org/mailman/listinfo/ci-users
> 
> 
> ___
> Gluster-infra mailing list
> gluster-in...@gluster.org
> https://lists.gluster.org/mailman/listinfo/gluster-infra
-- 
Michael Scherer
Sysadmin, Community Infrastructure and Platform, OSAS



signature.asc
Description: This is a digitally signed message part
___
Gluster-devel mailing list
Gluster-devel@gluster.org
https://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] The ctime of fstat is not correct which lead to "tar" utility error

[Lian, George (NSB - CN/Hangzhou)]

Hi,

Sorry, there seems still have issue.

We use “dd” application of linux tools instead of my demo program, and if the 
file is not exist before dd, the issue still be there.

The test command is
rm -rf /mnt/test/file.txt ; dd if=/dev/zero of=/mnt/test/file.txt bs=512 
count=1 oflag=sync;stat /mnt/test/file.txt;tar -czvf /tmp/abc.gz

1) If we set md-cache-timeout to 0, the issue will not happen

2) If we set md-cache-timeout to 1, the issue will 100% reproduced! (with 
new patch you mentioned in the mail)


Please see detail test result as the below:

bash-4.4# gluster v set export md-cache-timeout 0
volume set: failed: Volume export does not exist
bash-4.4# gluster v set test md-cache-timeout 0
volume set: success
bash-4.4# dd if=/dev/zero of=/mnt/test/file.txt bs=512 count=1 oflag=sync;stat 
/mnt/test/file.txt;tar -czvf /tmp/abc.gz /mnt/test/file.txt;stat 
/mnt/test/file.txt^C
bash-4.4# rm /mnt/test/file.txt
bash-4.4# dd if=/dev/zero of=/mnt/test/file.txt bs=512 count=1 oflag=sync;stat 
/mnt/test/file.txt;tar -czvf /tmp/abc.gz /mnt/test/file.txt;stat 
/mnt/test/file.txt
1+0 records in
1+0 records out
512 bytes copied, 0.00932571 s, 54.9 kB/s
  File: /mnt/test/file.txt
  Size: 512 Blocks: 1  IO Block: 131072 regular file
Device: 33h/51d Inode: 9949244856126716752  Links: 1
Access: (0644/-rw-r--r--)  Uid: (0/root)   Gid: (0/root)
Access: 2018-07-13 17:55:02.75600 +
Modify: 2018-07-13 17:55:02.76400 +
Change: 2018-07-13 17:55:02.76800 +
Birth: -
tar: Removing leading `/' from member names
/mnt/test/file.txt
  File: /mnt/test/file.txt
  Size: 512 Blocks: 1  IO Block: 131072 regular file
Device: 33h/51d Inode: 9949244856126716752  Links: 1
Access: (0644/-rw-r--r--)  Uid: (0/root)   Gid: (0/root)
Access: 2018-07-13 17:55:02.77600 +
Modify: 2018-07-13 17:55:02.76400 +
Change: 2018-07-13 17:55:02.76800 +
Birth: -
bash-4.4# gluster v set test md-cache-timeout 1
volume set: success
bash-4.4# rm /mnt/test/file.txt
bash-4.4# dd if=/dev/zero of=/mnt/test/file.txt bs=512 count=1 oflag=sync;stat 
/mnt/test/file.txt;tar -czvf /tmp/abc.gz /mnt/test/file.txt;stat 
/mnt/test/file.txt
1+0 records in
1+0 records out
512 bytes copied, 0.0107589 s, 47.6 kB/s
  File: /mnt/test/file.txt
  Size: 512 Blocks: 1  IO Block: 131072 regular file
Device: 33h/51d Inode: 13569976446871695205  Links: 1
Access: (0644/-rw-r--r--)  Uid: (0/root)   Gid: (0/root)
Access: 2018-07-13 17:55:11.54800 +
Modify: 2018-07-13 17:55:11.56000 +
Change: 2018-07-13 17:55:11.56000 +
Birth: -
tar: Removing leading `/' from member names
/mnt/test/file.txt
tar: /mnt/test/file.txt: file changed as we read it
  File: /mnt/test/file.txt
  Size: 512 Blocks: 1  IO Block: 131072 regular file
Device: 33h/51d Inode: 13569976446871695205  Links: 1
Access: (0644/-rw-r--r--)  Uid: (0/root)   Gid: (0/root)
Access: 2018-07-13 17:55:11.58000 +
Modify: 2018-07-13 17:55:11.56000 +
Change: 2018-07-13 17:55:11.56400 +
Birth: -


Best Regards,
George
From: gluster-devel-boun...@gluster.org 
[mailto:gluster-devel-boun...@gluster.org] On Behalf Of Raghavendra Gowdappa
Sent: Friday, July 20, 2018 4:01 PM
To: Lian, George (NSB - CN/Hangzhou) 
Cc: Zhang, Bingxuan (NSB - CN/Hangzhou) ; 
Raghavendra G ; Gluster-devel@gluster.org
Subject: Re: [Gluster-devel] The ctime of fstat is not correct which lead to 
"tar" utility error



On Fri, Jul 20, 2018 at 1:22 PM, Lian, George (NSB - CN/Hangzhou) 
mailto:george.l...@nokia-sbell.com>> wrote:
>>>We recently identified an issue with stat-prefetch. Fix can be found at:
>>>https://review.gluster.org/#/c/20410/11

>>>Can you let us know whether this helps?


The patch can resolve this issue, I have verified in Gluster 4.2(master trunk 
branch) and Gluster 3.12.3!

Thanks we'll merge it.


Thanks & Best Regards,
George

From: 
gluster-devel-boun...@gluster.org 
[mailto:gluster-devel-boun...@gluster.org]
 On Behalf Of Raghavendra Gowdappa
Sent: Thursday, July 19, 2018 5:06 PM
To: Lian, George (NSB - CN/Hangzhou) 
mailto:george.l...@nokia-sbell.com>>
Cc: Zhang, Bingxuan (NSB - CN/Hangzhou) 
mailto:bingxuan.zh...@nokia-sbell.com>>; 
Gluster-devel@gluster.org; Raghavendra G 
mailto:raghaven...@gluster.com>>
Subject: Re: [Gluster-devel] The ctime of fstat is not correct which lead to 
"tar" utility error



On Thu, Jul 19, 2018 at 2:29 PM, Lian, George (NSB - CN/Hangzhou) 
mailto:george.l...@nokia-sbell.com>> wrote:
Hi, Gluster Experts,

In glusterfs version 3.12.3, There seems a “fstat” issue for ctime after we use 
fsync,
We have a demo execute binary which write some data and then do fsync for this 
file, it named as “tt”,
Then run tar command right after “tt” command, it will always 

[Gluster-devel] [FYI] GitHub connectivity issues

[Nigel Babu]

Hello folks,

Our infra also runs in the same network, so if you notice issues, they're
most likely related to the same network issues.

-- Forwarded message -
From: Fabian Arrotin 
Date: Fri, Jul 20, 2018 at 12:49 PM
Subject: [Ci-users] [FYI] GitHub connectivity issue
To: ci-us...@centos.org 


Hi,

Just to let all Projects using CI that our monitoring complained a lot
about "flapping" connectivity to some external nodes, including github.com.
After some investigations, it seems that there are some peering issues
(or routing) at Level3, but errors come and go.

We can't do anything but report internally and see if then error can be
reported "upstream" at the link provider level.

So this message is more about the fact that if your tests are having
issues with some external connectivity, that can be related to that issue.

-- 
Fabian Arrotin
The CentOS Project | https://www.centos.org
gpg key: 56BEC54E | twitter: @arrfab

___
Ci-users mailing list
ci-us...@centos.org
https://lists.centos.org/mailman/listinfo/ci-users


-- 
nigelb
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iEYEARECAAYFAltRjOcACgkQnVkHo1a+xU5ndwCcDQmJTyunYsNRPvwpKGhK59Md
vN4AnAj7MV28RcZz4SoIUoWxiuyVzh+a
=w+ez
-END PGP SIGNATURE-
___
Gluster-devel mailing list
Gluster-devel@gluster.org
https://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] The ctime of fstat is not correct which lead to "tar" utility error

[Lian, George (NSB - CN/Hangzhou)]

>>>We recently identified an issue with stat-prefetch. Fix can be found at:
>>>https://review.gluster.org/#/c/20410/11

>>>Can you let us know whether this helps?


The patch can resolve this issue, I have verified in Gluster 4.2(master trunk 
branch) and Gluster 3.12.3!

Thanks & Best Regards,
George

From: gluster-devel-boun...@gluster.org 
[mailto:gluster-devel-boun...@gluster.org] On Behalf Of Raghavendra Gowdappa
Sent: Thursday, July 19, 2018 5:06 PM
To: Lian, George (NSB - CN/Hangzhou) 
Cc: Zhang, Bingxuan (NSB - CN/Hangzhou) ; 
Gluster-devel@gluster.org; Raghavendra G 
Subject: Re: [Gluster-devel] The ctime of fstat is not correct which lead to 
"tar" utility error



On Thu, Jul 19, 2018 at 2:29 PM, Lian, George (NSB - CN/Hangzhou) 
mailto:george.l...@nokia-sbell.com>> wrote:
Hi, Gluster Experts,

In glusterfs version 3.12.3, There seems a “fstat” issue for ctime after we use 
fsync,
We have a demo execute binary which write some data and then do fsync for this 
file, it named as “tt”,
Then run tar command right after “tt” command, it will always error with “tar: 
/mnt/test/file1.txt: file changed as we read it”

The command output is list as the below, the source code and volume info 
configuration attached FYI,
This issue will be 100% reproducible! (/mnt/test is mountpoint of glusterfs 
volume “test” , which the volume info is attached in mail)
--
./tt;tar -czvf /tmp/abc.gz /mnt/test/file1.txt
mtime:1531247107.27200
ctime:1531247107.27200
tar: Removing leading `/' from member names
/mnt/test/file1.txt
tar: /mnt/test/file1.txt: file changed as we read it
--

After my investigation, the xattrop for changelog is later than the fsync 
response , this is mean:
In function  “afr_fsync_cbk” will call afr_delayed_changelog_wake_resume (this, 
local->fd, stub);

In our case, it always a pending changelog , so glusterfs save the metadata 
information to stub, and handle pending changelog first,
But the changelog will also change the ctime, from the packet captured by 
tcpdump, the response packet of xattrop will not include the metadata 
information,  and the wake_resume also not handle this metadata changed case.

So in this case, the metadata in mdc_cache is not right, and when cache is 
valid, the application will get WRONG metadata!

For verify my guess, if I change the configuration for this volume
“gluster v set test md-cache-timeout 0” or
“gluster v set export stat-prefetch off”
This issue will be GONE!

We recently identified an issue with stat-prefetch. Fix can be found at:
https://review.gluster.org/#/c/20410/11

Can you let us know whether this helps?



And I restore the configuration to default, which mean stat-prefetch is on and 
md-cache-timeout is 1 second,
I try invalidate the md-cache in source code as the below in function 
mdc_fync_cbk on md-cache.c
The issue also will be GONE!

So GLusterFS Experts,
Could you please verify this issue, and share your comments on my investigation?
And your finally solutions is highly appreciated!

Does the following fix you've posted solves the problem?


changes in function “mdc_fsync_cbk”
int
mdc_fsync_cbk (call_frame_t *frame, void *cookie, xlator_t *this,
   int32_t op_ret, int32_t op_errno,
   struct iatt *prebuf, struct iatt *postbuf, dict_t *xdata)
{
mdc_local_t  *local = NULL;

local = frame->local;

if (op_ret != 0)
goto out;

if (!local)
goto out;

mdc_inode_iatt_set_validate(this, local->fd->inode, prebuf, postbuf,
 _gf_true);
/* new added for ctime issue*/
mdc_inode_iatt_invalidate(this, local->fd->inode);
/* new added end*/
out:
MDC_STACK_UNWIND (fsync, frame, op_ret, op_errno, prebuf, postbuf,
  xdata);

return 0;
}
-
Best Regards,
George

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

Re: [Gluster-devel] The ctime of fstat is not correct which lead to "tar" utility error

[Raghavendra Gowdappa]

On Fri, Jul 20, 2018 at 1:22 PM, Lian, George (NSB - CN/Hangzhou) <
george.l...@nokia-sbell.com> wrote:

> >>>We recently identified an issue with stat-prefetch. Fix can be found at:
>
> >>>https://review.gluster.org/#/c/20410/11
>
>
>
> >>>Can you let us know whether this helps?
>
>
>
>
>
> The patch can resolve this issue, I have verified in Gluster 4.2(master
> trunk branch) and Gluster 3.12.3!
>

Thanks we'll merge it.


>
> Thanks & Best Regards,
>
> George
>
>
>
> *From:* gluster-devel-boun...@gluster.org [mailto:gluster-devel-bounces@
> gluster.org] *On Behalf Of *Raghavendra Gowdappa
> *Sent:* Thursday, July 19, 2018 5:06 PM
> *To:* Lian, George (NSB - CN/Hangzhou) 
> *Cc:* Zhang, Bingxuan (NSB - CN/Hangzhou) ;
> Gluster-devel@gluster.org; Raghavendra G 
> *Subject:* Re: [Gluster-devel] The ctime of fstat is not correct which
> lead to "tar" utility error
>
>
>
>
>
>
>
> On Thu, Jul 19, 2018 at 2:29 PM, Lian, George (NSB - CN/Hangzhou) <
> george.l...@nokia-sbell.com> wrote:
>
> Hi, Gluster Experts,
>
>
>
> In glusterfs version 3.12.3, There seems a “fstat” issue for ctime after
> we use fsync,
>
> We have a demo execute binary which write some data and then do fsync for
> this file, it named as “tt”,
>
> Then run tar command right after “tt” command, it will always error with “tar:
> /mnt/test/file1.txt: file changed as we read it”
>
>
>
> The command output is list as the below, the source code and volume info
> configuration attached FYI,
>
> This issue will be 100% reproducible! (/mnt/test is mountpoint of
> glusterfs volume “test” , which the volume info is attached in mail)
>
> --
>
> ./tt;tar -czvf /tmp/abc.gz /mnt/test/file1.txt
>
> mtime:1531247107.27200
>
> ctime:1531247107.27200
>
> tar: Removing leading `/' from member names
>
> /mnt/test/file1.txt
>
> tar: /mnt/test/file1.txt: file changed as we read it
>
> --
>
>
>
> After my investigation, the xattrop for changelog is later than the fsync
> response , this is mean:
>
> In function  “afr_fsync_cbk” will call afr_delayed_changelog_wake_resume
> (this, local->fd, stub);
>
>
>
> In our case, it always a pending changelog , so glusterfs save the
> metadata information to stub, and handle pending changelog first,
>
> But the changelog will also change the ctime, from the packet captured by
> tcpdump, the response packet of xattrop will not include the metadata
> information,  and the wake_resume also not handle this metadata changed
> case.
>
>
>
> So in this case, the metadata in mdc_cache is not right, and when cache is
> valid, the application will get WRONG metadata!
>
>
>
> For verify my guess, if I change the configuration for this volume
>
> “gluster v set test md-cache-timeout 0” or
>
> “gluster v set export stat-prefetch off”
>
> This issue will be GONE!
>
>
>
> We recently identified an issue with stat-prefetch. Fix can be found at:
>
> https://review.gluster.org/#/c/20410/11
>
>
>
> Can you let us know whether this helps?
>
>
>
>
>
>
>
> And I restore the configuration to default, which mean stat-prefetch is on
> and md-cache-timeout is 1 second,
>
> I try invalidate the md-cache in source code as the below in function
> mdc_fync_cbk on md-cache.c
>
> The issue also will be GONE!
>
>
>
> So GLusterFS Experts,
>
> Could you please verify this issue, and share your comments on my
> investigation?
>
> And your finally solutions is highly appreciated!
>
>
>
> Does the following fix you've posted solves the problem?
>
>
>
>
>
> changes in function “mdc_fsync_cbk”
>
> int
>
> mdc_fsync_cbk (call_frame_t *frame, void *cookie, xlator_t *this,
>
>int32_t op_ret, int32_t op_errno,
>
>struct iatt *prebuf, struct iatt *postbuf, dict_t *xdata)
>
> {
>
> mdc_local_t  *local = NULL;
>
>
>
> local = frame->local;
>
>
>
> if (op_ret != 0)
>
> goto out;
>
>
>
> if (!local)
>
> goto out;
>
>
>
> mdc_inode_iatt_set_validate(this, local->fd->inode, prebuf,
> postbuf,
>
>  _gf_true);
>
> /* new added for ctime issue*/
>
> mdc_inode_iatt_invalidate(this, local->fd->inode);
>
>
> /* new added end*/
>
> out:
>
> MDC_STACK_UNWIND (fsync, frame, op_ret, op_errno, prebuf, postbuf,
>
>   xdata);
>
>
>
> return 0;
>
> }
>
> 
> -
>
> Best Regards,
>
> George
>
>
>
___
Gluster-devel mailing list
Gluster-devel@gluster.org
https://lists.gluster.org/mailman/listinfo/gluster-devel

[Gluster-devel] Feature Classification & Quality Expectation.

[Amar Tumballi]

We sent an email few days back for proposal to deprecate some features in
glusterfs (
https://lists.gluster.org/pipermail/gluster-devel/2018-July/054997.html).

Shyam recently sent the document as a patch upstream Gluster @
https://review.gluster.org/20538/. (Same is copied below in email here).
Please provide your valuable feedback on the same, so we can make it a
general practice.

This is done for making things more clear about proper expectation from
each of the component/feature, we want to have more classification of each
feature, control them using the code itself, and make sure we keep the list
up-to-date with each release, so our users have proper expectations set.



The purpose of the document is to define a classification for various
xlators and expectations around what each classification means from a
perspective of health and maintenance of the xlator.

The need to do this is to ensure certain classifications are kept in good
health, and helps the community and contributors focus efforts on around
the same.
Classifications

   1. Experimental (E)
   2. TechPreview (TP)
   3. Maintained/Supported (M)
   4. Sunset (S)
   5. Deprecated (D)

Experimental (E)

Developed in the experimental branch, for exploring new features. These are
NEVER released, and MAYBE packaged to help with getting feedback from
interested users.
Quality
expectations

   - Compiles
   - Does not break nightly experimental regressions

TechPreview (TP)

Features in master or release branches that are not complete for general
purpose consumption, but are mature enough to invite feedback and host user
data.

These features will receive better attention from maintainers/authors that
are working on maturing the same, than ones in
Experimental/Sunset/Deprecated states.

There is no grantee that these features will move to the Maintained state,
and may just get Deprecated based on feedback, or other project goals or
technical alternatives.
Quality
expectations

   - Same as Maintained, sans
  - Performance, Scale, other(?)

Maintained (M)

These features are part of the core Gluster functionality and are
maintained actively. These are part of master and release branches and get
high priority attention from maintainers and other interested contributors.
Quality
expectations

NOTE: A short note on what each of these mean are added here, details to
follow.

   - Bug backlog: Actively address bug backlog
   - Enhancement backlog: Actively maintain outstanding enhancement backlog
   (need not be acted on, but should be visible to all)
   - Review backlog: Actively keep this below desired counts and states
   - Static code health: Actively meet near-zero issues in this regard
  - Coverity, spellcheck and other checks
   - Runtime code health: Actively meet defined coverage levels in this
   regard
  - Coverage, others?
  - Per-patch regressions
  - Glusto runs
  - Performance
  - Scalability
   - Technical specifications: Implementation details should be documented
   and updated at regular cadence (even per patch that change assumptions in
   here)
   - User documentation: User facing details should be maintained to
   current status in the documentation
   - Debuggability: Steps, tools, procedures should be documented and
   maintained each release/patch as applicable
   - Troubleshooting: Steps, tools, procedures should be documented and
   maintained each release/patch as applicable
  - Steps/guides for self service
  - Knowledge base for problems
   - Other common criteria that will apply: Required metrics/desired states
   to be define per criteria
  - Monitoring, usability, statedump, and other such xlator expectations

Sunset (S)

Features on master or release branches that would be deprecated and/or
replaced with similar or other functionality in the next major release.
Quality
expectations

   - Retain status-quo when moved to this state, till it is moved to
   deprecated

Deprecated (D)

Features/code still in tree, but not packaged or shipped or supported in
any form. This is noted as a category till the code is removed from the
tree.

These feature and their corresponding code and test health will not be
executed.
Quality
expectations

   - None



Regards,
Amar


On Thu, Jul 19, 2018 at 12:26 PM, Amar Tumballi  wrote:

>
> *Hi all,Over last 

Re: [Gluster-devel] [Gluster-users] Proposal to mark few features as Deprecated / SunSet from Version 5.0

[Amar Tumballi]

On Thu, Jul 19, 2018 at 6:46 PM, mabi  wrote:

> Hi Amar,
>
> Just wanted to say that I think the quota feature in GlusterFS is really
> useful. In my case I use it on one volume where I have many cloud
> installations (mostly files) for different people and all these need to
> have a different quota set on a specific directory. The GlusterFS quota
> allows me nicely to manage that which would not be possible in the
> application directly. It would really be an overhead for me to for example
> to have one volume per installation just because of setting the max size
> like that.
>
> I hope that this feature can continue to exist.
>
>
Thanks for the feedback. We will consider this use-case.


> Best regards,
> M.
>
>
>
> ‐‐‐ Original Message ‐‐‐
> On July 19, 2018 8:56 AM, Amar Tumballi  wrote:
>
> Hi all,
>
> Over last 12 years of Gluster, we have developed many features, and
> continue to support most of it till now. But along the way, we have figured
> out better methods of doing things. Also we are not actively maintaining
> some of these features.
>
> We are now thinking of cleaning up some of these ‘unsupported’ features,
> and mark them as ‘SunSet’ (i.e., would be totally taken out of codebase in
> following releases) in next upcoming release, v5.0. The release notes
> will provide options for smoothly migrating to the supported configurations.
>
> If you are using any of these features, do let us know, so that we can
> help you with ‘migration’.. Also, we are happy to guide new developers to
> work on those components which are not actively being maintained by current
> set of developers.
> *List of features hitting sunset:*
> *‘cluster/stripe’ translator:*
>
> This translator was developed very early in the evolution of GlusterFS,
> and addressed one of the very common question of Distributed FS, which is
> “What happens if one of my file is bigger than the available brick. Say, I
> have 2 TB hard drive, exported in glusterfs, my file is 3 TB”. While it
> solved the purpose, it was very hard to handle failure scenarios, and give
> a real good experience to our users with this feature. Over the time,
> Gluster solved the problem with it’s ‘Shard’ feature, which solves the
> problem in much better way, and provides much better solution with existing
> well supported stack. Hence the proposal for Deprecation.
>
> If you are using this feature, then do write to us, as it needs a proper
> migration from existing volume to a new full supported volume type before
> you upgrade.
> *‘storage/bd’ translator:*
>
> This feature got into the code base 5 years back with this *patch*
> [1]. Plan was to use a block device
> directly as a brick, which would help to handle disk-image storage much
> easily in glusterfs.
>
> As the feature is not getting more contribution, and we are not seeing any
> user traction on this, would like to propose for Deprecation.
>
> If you are using the feature, plan to move to a supported gluster volume
> configuration, and have your setup ‘supported’ before upgrading to your new
> gluster version.
> *‘RDMA’ transport support:*
>
> Gluster started supporting RDMA while ib-verbs was still new, and very
> high-end infra around that time were using Infiniband. Engineers did work
> with Mellanox, and got the technology into GlusterFS for better data
> migration, data copy. While current day kernels support very good speed
> with IPoIB module itself, and there are no more bandwidth for experts in
> these area to maintain the feature, we recommend migrating over to TCP (IP
> based) network for your volume.
>
> If you are successfully using RDMA transport, do get in touch with us to
> prioritize the migration plan for your volume. Plan is to work on this
> after the release, so by version 6.0, we will have a cleaner transport
> code, which just needs to support one type.
> *‘Tiering’ feature*
>
> Gluster’s tiering feature which was planned to be providing an option to
> keep your ‘hot’ data in different location than your cold data, so one can
> get better performance. While we saw some users for the feature, it needs
> much more attention to be completely bug free. At the time, we are not
> having any active maintainers for the feature, and hence suggesting to take
> it out of the ‘supported’ tag.
>
> If you are willing to take it up, and maintain it, do let us know, and we
> are happy to assist you.
>
> If you are already using tiering feature, before upgrading, make sure to
> do gluster volume tier detach all the bricks before upgrading to next
> release. Also, we recommend you to use features like dmcache on your LVM
> setup to get best performance from bricks.
> *‘Quota’*
>
> This is a call out for ‘Quota’ feature, to let you all know that it will
> be ‘no new development’ state. While this feature is ‘actively’ in use by
> many people, the challenges we have in accounting mechanisms involved, has
> made it hard to achieve good performance with