+++ This bug was initially created as a clone of Bug #1229623 +++

Description of problem:

When we choose to not go ahead with a particular session, we use glusterfind delete to delete the entry from the list. However, that leaves the session directory and all the information under it (at the location /var/lib/glusterd/glusterfind/) intact. 

True, it doesn't hamper or come in the way of creating another session with the same name, but it does lead to unnecessary confusion. 

Same is the case with LOGS at /var/log/glusterfs/glusterfind/. But we would want to store the logs for some later point of time in future. 

Version-Release number of selected component (if applicable):
glusterfs-3.7.0-3.el6rhs.x86_64

How reproducible: Always


Steps to Reproduce:
1. Have a 2node cluster, create a volume 'ozone' and a glusterfind session 'sesso1'
2. Run pre and post a couple of times
3. Execute glusterfind delete to delete the session 'sesso1'
4. Check the contents of /var/lib/glusterd/glusterfind/sesso1/ozone

Actual results:

Step4 displays the status information related to 'sesso1'

Expected results:

Glusterfind delete should delete teh directory 'sesso1' and its entire contents

--- Additional comment from Aravinda VK on 2015-06-09 13:25:36 EDT ---

Since stale directories observed only in backend and not exposed to user. Moving the priority to LOW.