<div dir="ltr"><div><div><div><div><div><div><br><span class="im">> Yeah this followed by glusterd restart should help<br>
><br>
> But frankly, i was hoping that 'rm' the file isn't a neat way to fix this<br>
> issue<br>
<br>
</span>>>Why is rm not a neat way? Is it because the container deployment tool needs to<br>
>>know about gluster internals? But isn't a Dockerfile dealing with details<br>
>>of the service(s) that is being deployment in a container.<br>
<span class="im"><br><br></span></div><span class="im">I do think fixing the dockerfile is *not* the correct way. That said, the use case is not just <br></span></div><span class="im">containers. This issue can pop up in Ovirt or virtualization environments as well. <br></span></div><span class="im">The VM template may have pre configured glusterd in it and the pool created out of this template<br></span></div><span class="im">can show the same behaviour. <br><br></span></div><span class="im">I believe fixing it in gluster code base would be the right thing to do.<br><br></span></div><br><span class="im">Thanks Atin for the heads up!<br></span><div><div><div><div><div><div><div><span class="im"><br>
> AFAICT we have 2 scenarios:<br>
><br>
> 1) Non-container scenario, where the current behaviour of glusterd persisting<br>
> the info in .info file makes sense<br>
><br>
> 2) Container scenario, where the same image gets used as the base, hence all<br>
> containers gets the same UUID<br>
> For this we can have an option to tell glusterd that instructs it to refresh<br>
> the UUID during next start.<br>
><br>
</span><br></div></div></div></div></div></div></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div>--Humble<br></div><br></div></div></div>
<br><div class="gmail_quote">On Wed, Jul 1, 2015 at 11:32 AM, Krishnan Parthasarathi <span dir="ltr"><<a href="mailto:kparthas@redhat.com" target="_blank">kparthas@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> Yeah this followed by glusterd restart should help<br>
><br>
> But frankly, i was hoping that 'rm' the file isn't a neat way to fix this<br>
> issue<br>
<br>
</span>Why is rm not a neat way? Is it because the container deployment tool needs to<br>
know about gluster internals? But isn't a Dockerfile dealing with details<br>
of the service(s) that is being deployment in a container.<br>
<span class=""><br>
> AFAICT we have 2 scenarios:<br>
><br>
> 1) Non-container scenario, where the current behaviour of glusterd persisting<br>
> the info in .info file makes sense<br>
><br>
> 2) Container scenario, where the same image gets used as the base, hence all<br>
> containers gets the same UUID<br>
> For this we can have an option to tell glusterd that instructs it to refresh<br>
> the UUID during next start.<br>
><br>
> Maybe somethign like presence of a file /var/lib/glusterd/refresh_uuid makes<br>
> glusterd refresh the UUID in .info<br>
> and then delete this file, that ways, Dockerfile can touch this file, post<br>
> gluster rpm install step and things should<br>
> work as expected ?<br>
<br>
</span>If container deployment needs are different it should should address issues like<br>
above. If we start addressing glusterd's configuration handling for every<br>
new deployment technology it would quickly become unmaintainable.<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
Gluster-devel mailing list<br>
<a href="mailto:Gluster-devel@gluster.org">Gluster-devel@gluster.org</a><br>
<a href="http://www.gluster.org/mailman/listinfo/gluster-devel" rel="noreferrer" target="_blank">http://www.gluster.org/mailman/listinfo/gluster-devel</a><br>
</div></div></blockquote></div><br></div>