> Attached is a basic write-up of the user-serviceable snapshot feature > design (Avati's). Please take a look and let us know if you have > questions of any sort...
A few. The design creates a new type of daemon: snapview-server. * Where is it started? One server (selected how) or all? * How do clients find it? Are we dynamically changing the client side graph to add new protocol/client instances pointing to new snapview-servers, or is snapview-client using RPC directly? Are the snapview-server ports managed through the glusterd portmapper interface, or patched in some other way? * Since a snap volume will refer to multiple bricks, we'll need more brick daemons as well. How are *those* managed? * How does snapview-server manage user credentials for connecting to snap bricks? What if multiple users try to use the same snapshot at the same time? How does any of this interact with on-wire or on-disk encryption? I'm sure I'll come up with more later. Also, next time it might be nice to use the upstream feature proposal template *as it was designed* to make sure that questions like these get addressed where the whole community can participate in a timely fashion. _______________________________________________ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
