Thanks Joe for the confirmation, cheers, have a good weekend. On Thu, Aug 11, 2016 at 5:17 PM, Joe Julian <[email protected]> wrote:
> On 08/11/2016 02:05 PM, Gandalf Corvotempesta wrote: > > Il 11 ago 2016 7:21 PM, "Dan Lavu" <[email protected]> ha scritto: > > > > Is it possible? Looking at everything, it just seems like I need the > content of the bricks and whatever is in /etc/glusterd and > /var/lib/glusterd maintaining the same hostname, IP and the same Gluster > version? > > > > > > Why not start from scratch and let gluster to heal when you add the > upgraded node back to the cluster? > > Because "start from scratch" means changing hostnames. When you've got a > strategy for naming hosts, assigning a hostname that doesn't fit that > strategy breaks consistency. When you're managing hosts in 6 datacenters on > 4 contenents, consistent naming is critical. > > Having consistent names makes automated deployment (or redeployment) much > easier to code when you're using mgmt, saltstack, ansible, puppet or even > chef. This is also the same reason I use consistent naming for brick > directories. > > Gluster has never written replacement tools with same hostname and path as > a possibility meaning that replace-brick doesn't work. Without being able > to use replace-brick, self-heal doesn't know to heal that one single brick > so heal...full is needed. Replace-brick is being changed to allow in-place > replacement and solve that problem. Until then, Dan's process is perfectly > reasonable and is the process that I use (more or less, I actually just > template glusterd.info and rely on the sync process to fill the rest of > /var/lib/glusterd). > > > > _______________________________________________ > Gluster-users mailing list > [email protected] > http://www.gluster.org/mailman/listinfo/gluster-users >
_______________________________________________ Gluster-users mailing list [email protected] http://www.gluster.org/mailman/listinfo/gluster-users
