<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>