<!DOCTYPE html>
<html>
<head>
<title></title>
</head>
<body><div style="font-family:Arial;"><br></div>
<div><br></div>
<div><br></div>
<div>On Mon, Apr 24, 2017, at 11:52 AM, Jeff Darcy wrote:<br></div>
<blockquote type="cite"><div style="font-family:Arial;">On Fri, Apr 21, 2017, at 09:17 AM, Atin Mukherjee wrote:<br></div>
<blockquote type="cite"><div dir="ltr"><div><div style="font-family:Arial;">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.<br></div>
</div>
</div>
</blockquote><div style="font-family:Arial;"><br></div>
<div style="font-family:Arial;">+100<br></div>
</blockquote><div style="font-family:Arial;"><br></div>
<div style="font-family:Arial;">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?<br></div>
<div style="font-family:Arial;"><br></div>
</body>
</html>