<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 08/11/2016 02:05 PM, Gandalf Corvotempesta wrote:<br>
<blockquote
cite="mid:CAJH6TXhYk4WPAtjLJrB=yCBCWor1nvxaYwg3owCTjZvNYZvURw@mail.gmail.com"
type="cite">
<p dir="ltr">Il 11 ago 2016 7:21 PM, "Dan Lavu" <<a
moz-do-not-send="true" href="mailto:dan@redhat.com">dan@redhat.com</a>>
ha scritto:<br>
><br>
> 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? <br>
><br>
> </p>
<p dir="ltr">Why not start from scratch and let gluster to heal
when you add the upgraded node back to the cluster? </p>
<br>
</blockquote>
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. <br>
<br>
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.<br>
<br>
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).<br>
<br>
<br>
</body>
</html>