<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, May 8, 2014 at 4:53 AM, Jeff Darcy <span dir="ltr"><<a href="mailto:jdarcy@redhat.com" target="_blank">jdarcy@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="">> > * How do clients find it? Â Are we dynamically changing the client<br>
> > Â Â side graph to add new protocol/client instances pointing to new<br>
> > Â Â snapview-servers, or is snapview-client using RPC directly? Â Are<br>
> > Â Â the snapview-server ports managed through the glusterd portmapper<br>
> > Â Â interface, or patched in some other way?<br>
> Adding a protocol/client instance to connect to protocol/server at the<br>
> daemon.<br>
<br>
</div>So now the client graph is being dynamically modified, in ways that<br>
make it un-derivable from the volume configuration (because they're<br>
based in part on user activity since then)? Â What happens if a normal<br>
graph switch (e.g. due to add-brick) happens? Â I'll need to think some<br>
more about what this architectural change really means.</blockquote><div><br></div><div>client graph is not dynamically modified. the snapview-client and protocol/server are inserted by volgen and no further changes are made on the client side. I believe Anand was referring to "Â Adding a protocol/client instance to connect to protocol/server at the daemon" as an action being performed by volgen.</div>
<div><br></div><div><br></div><div>Â </div></div></div></div>