Description of problem:
=======================

If a new node is attached to the cluster where uss is enabled, the snapd process does not start on newly attached node. Which makes unreachable to the snap world if the client is mounted with this newly attached node.

[root@inception ~]# gluster peer status
Number of Peers: 2

Hostname: rhs-arch-srv2.lab.eng.blr.redhat.com
Uuid: b51831ee-139e-4b02-83dc-cd1f140b8e5f
State: Peer in Cluster (Connected)

Hostname: rhs-arch-srv3.lab.eng.blr.redhat.com
Uuid: b2943c56-5622-43d2-adea-77e79108cdd3
State: Peer in Cluster (Connected)
[root@inception ~]# 


Newly node is: rhs-arch-srv3.lab.eng.blr.redhat.com

[root@rhs-arch-srv3 ~]# ps -eaf | grep snapd
root     10181  6085  0 09:17 pts/0    00:00:00 grep snapd
[root@rhs-arch-srv3 ~]# 

[root@rhs-arch-srv3 ~]# gluster v i | grep uss
features.uss: on
[root@rhs-arch-srv3 ~]# 


Version-Release number of selected component (if applicable):
==============================================================

glusterfs-3.6.0.32-1.el6rhs.x86_64


How reproducible:
=================
always


Steps to Reproduce:
===================
1. Create 2 node cluster
2. Create 2*2 volume from 2 node cluster
3. Enable USS
4. snapd process should run on the two nodes
5. Add another node to the cluster

Actual results:
===============

snapd is not started on the newly attached node.


Expected results:
=================

snapd should start on the newly attached node as it could serve as a primary server for a client, if snapd is not running than you can not enter to the snap world from client.