Hi Jeff, I've been testing release-3.7 in the lead up to tagging 3.7.11, and found that the fix I did to allow daemons to start when management encryption is enabled, doesn't work always. The daemons fail to start because they can't connect to glusterd to fetch the volfiles, and the connection failure is partly due to own-thread not being enabled. I'd like to know why own-thread is kept optional, and is not the default for any encrypted connection? Encrypted RPC in GlusterFS can only works with a poller on its own-thread, and cannot work with epoll. When this is the case, why is it even possible to disable own-thread. In GlusterFS currently, own-thread gets enabled for most encrypted connections by default. But in certain cases, it doesn't get enabled when it should be and leads to connection failures. This sort of failure is most visible when a glusterfs/glusterfsd process attempts to fetch volfiles from glusterd. I'm going to be sending a change that removes the option of disabling own-thread, and make all encrypted connections use it. Do you see any reasons not to do this? ~kaushal _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
