Re: [Gluster-infra] Nightly regression job with enabling brick multiplexing
On Tue, Apr 25, 2017 at 12:50:45PM -0400, Jeff Darcy wrote: > > > > On Mon, Apr 24, 2017, at 11:52 AM, Jeff Darcy wrote: > > On Fri, Apr 21, 2017, at 09:17 AM, Atin Mukherjee wrote: > >> As we don't run our .t files with brick mux being enabled for every > >> patches can we ensure that there is a nightly regression trigger with > >> brick multiplexing feature being enabled. The reason for this ask is > >> very simple, we have no control on the regression for this feature. > >> I've already seen a very basic test (volume status not reflecting > >> bricks online after glusterd restart) breaking recently which used to > >> work earlier.> > > +100 > > FWIW, the way I ran these tests during development was to have a patch > that makes multiplexing the default. I'd periodically rebase that on > top of whatever else was current, then run regressions on that. To do > that as part of a periodic test, we'd need the regression scripts to > look for that same patch in some "well known place" and apply it before > building. Is that something that somebody else would feel comfortable > implementing, or should I look into it? This "well known place" could be a branch in the git repository, maybe with an obvious name like "for-testing/brick-multiplex". In case the patch needs changing, everyone could then just update it and send a review. Maybe it is even possible to automatically rebase the "for-testing" branch every now and then. A Jenkins job can then checkout the master branch, and merge the "for-testing" branch before running the tests. Or, we have a change on review.gluster.org that never gets merged, and gets cherry-picked before running the regression tests (probably easier). Niels signature.asc Description: PGP signature ___ Gluster-infra mailing list Gluster-infra@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-infra
Re: [Gluster-infra] Nightly regression job with enabling brick multiplexing
On Tue, 25 Apr 2017 at 10:21 PM, Jeff Darcy wrote: > > > > On Mon, Apr 24, 2017, at 11:52 AM, Jeff Darcy wrote: > > On Fri, Apr 21, 2017, at 09:17 AM, Atin Mukherjee wrote: > > As we don't run our .t files with brick mux being enabled for every > patches can we ensure that there is a nightly regression trigger with brick > multiplexing feature being enabled. The reason for this ask is very simple, > we have no control on the regression for this feature. I've already seen a > very basic test (volume status not reflecting bricks online after glusterd > restart) breaking recently which used to work earlier. > > > +100 > > > FWIW, the way I ran these tests during development was to have a patch > that makes multiplexing the default. I'd periodically rebase that on top > of whatever else was current, then run regressions on that. To do that as > part of a periodic test, we'd need the regression scripts to look for that > same patch in some "well known place" and apply it before building. Is > that something that somebody else would feel comfortable implementing, or > should I look into it? > I personally feel some one in team can look into this, while your time is valuable with more FS reviews. I will work with team to look into this. -Amar > > ___ > Gluster-infra mailing list > Gluster-infra@gluster.org > http://lists.gluster.org/mailman/listinfo/gluster-infra -- Amar Tumballi (amarts) ___ Gluster-infra mailing list Gluster-infra@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-infra
Re: [Gluster-infra] Nightly regression job with enabling brick multiplexing
On Mon, Apr 24, 2017, at 11:52 AM, Jeff Darcy wrote: > On Fri, Apr 21, 2017, at 09:17 AM, Atin Mukherjee wrote: >> As we don't run our .t files with brick mux being enabled for every >> patches can we ensure that there is a nightly regression trigger with >> brick multiplexing feature being enabled. The reason for this ask is >> very simple, we have no control on the regression for this feature. >> I've already seen a very basic test (volume status not reflecting >> bricks online after glusterd restart) breaking recently which used to >> work earlier.> > +100 FWIW, the way I ran these tests during development was to have a patch that makes multiplexing the default. I'd periodically rebase that on top of whatever else was current, then run regressions on that. To do that as part of a periodic test, we'd need the regression scripts to look for that same patch in some "well known place" and apply it before building. Is that something that somebody else would feel comfortable implementing, or should I look into it? ___ Gluster-infra mailing list Gluster-infra@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-infra
Re: [Gluster-infra] Nightly regression job with enabling brick multiplexing
On Fri, Apr 21, 2017, at 09:17 AM, Atin Mukherjee wrote: > As we don't run our .t files with brick mux being enabled for every > patches can we ensure that there is a nightly regression trigger with > brick multiplexing feature being enabled. The reason for this ask is > very simple, we have no control on the regression for this feature. > I've already seen a very basic test (volume status not reflecting > bricks online after glusterd restart) breaking recently which used to > work earlier. +100 ___ Gluster-infra mailing list Gluster-infra@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-infra
