<div dir="ltr">The main intention of test case is heal shouldn't happen when shd is not running on source brick. I think we can disable self-heal daemon to achieve the similar behaviour<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 31, 2018 at 10:39 AM, Nigel Babu <span dir="ltr"><<a href="mailto:nigelb@redhat.com" target="_blank">nigelb@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Mon, May 28, 2018 at 9:15 AM, Atin Mukherjee <span dir="ltr"><<a href="mailto:amukherj@redhat.com" target="_blank">amukherj@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Mon, May 28, 2018 at 8:50 AM, Nigel Babu <span dir="ltr"><<a href="mailto:nigelb@redhat.com" target="_blank">nigelb@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>(Adding Atin)</div><div><br></div><div>We're making an assumption that when bricks are brought online, SHD isn't brought online. Did this behavior change recently?</div></div></blockquote><div><br></div></span><div>AFAIK, there's no change of behaviour as such which got introduced recently.</div><span><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>Atin, is there a difference to how bricks should be killed with brick multiplex on vs off?<br></div></div></blockquote><div><br></div></span><div>For non brick multiplexing cases, sending a SIGTERM (kill -15) to a process is the way to go, however with brick multiplexing following the same approach would eventually kill the entire process resulting in all other brick instances (attached bricks) to be also going down which is unexpected. Like our upstream regression test infrastructure we should use gf_attach () utility to kill any bricks w/ brick multiplexing.</div><span><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 25, 2018 at 4:38 PM, Vitalii Koriakov <span dir="ltr"><<a href="mailto:vkoriako@redhat.com" target="_blank">vkoriako@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello all.<br>
<br>
We have such scenario:<br>
- brink brick offline<br>
- kill shd processes on other bricks<br>
- bring killed brick online<br>
<br>
The thing is that with bringing brick, we bring up shd processes on other bricks also.<br>
Its connected with brick mux, so, killing brick and bringing brick is different and it seems that brickmux is enabled.<br>
So we have failed test, because of such behavior.<br>
<br>
We need a mechanism to bring brick up without shd.<br></blockquote></div></div></blockquote><div><br></div></span><div>Not sure how this test is a requirement. The only way to bring up brick processes is to do a volume start force and with that all the respective daemons (including shd) also comes up.</div><span><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br></blockquote></div></div></blockquote></span></div></div></div></blockquote><div><br></div></span><div>Vijay, why is this a test requirement? From Atin's response, it sounds like Gluster is behaving as expected here.<span class="HOEnZb"><font color="#888888"><br></font></span></div></div><span class="HOEnZb"><font color="#888888"><br clear="all"><br>-- <br><div class="m_-5190231187820058345gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">nigelb<br></div></div>
</font></span></div></div>
</blockquote></div><br></div>