As far as I know a fix was introduced recently, so even missing to run the script won't be so critical - you can run it afterwards.<div id="yMail_cursorElementTracker_1632240882326">I would use Ansible to roll out such updates on a set of nodes - this will prevent human errors and will give the opportunity to run such tiny details like geo-rep modifying script.</div><div id="yMail_cursorElementTracker_1632241026939"><br></div><div id="yMail_cursorElementTracker_1632240882536">P.S.: Out of curiosity, are you using distributed-replicated or distributed-dispersed volumes ?</div><div id="yMail_cursorElementTracker_1632240939075"><br></div><div id="yMail_cursorElementTracker_1632240939282">Best Regards,</div><div id="yMail_cursorElementTracker_1632240952980">Strahil Nikolov</div><div id="yMail_cursorElementTracker_1632240939480"><br> <br> <blockquote style="margin: 0 0 20px 0;"> <div style="font-family:Roboto, sans-serif; color:#6D00F6;"> <div>On Tue, Sep 21, 2021 at 17:59, Erik Jacobson</div><div><erik.jacobson@hpe.com> wrote:</div> </div> <div style="padding: 10px 0 0 20px; margin: 10px 0 0 0; border-left: 1px solid #6D00F6;"> > Don't forget to run the geo-replication fix script , if you missed to do it<br clear="none">> before the upgrade.<br clear="none"><br clear="none">We don't use geo-replication YET but thank you for this thoughtful<br clear="none">reminder.<br clear="none"><br clear="none">Just a note on things like this -- we really try to do everything in a<br clear="none">package update because that's how we'd have to deploy to customers in an<br clear="none">automated way. So having to run a script as part of the upgrade would be<br clear="none">very hard in a package based work flow for a packged solution.<br clear="none"><br clear="none">I'm not complaining I love gluster but this is just food for thought.<br clear="none"><br clear="none">I can't even hardly say it with a straight face because we suffer from<br clear="none">similar issues on the cluster management side - updating one CM to the<br clear="none">next is harder than it should be so I'm certainly not judging. Updating<br clear="none">is always painful.<br clear="none"><br clear="none">I LOVE that slowly updating our gluster servers is "Just working".<br clear="none"><br clear="none">This will allow a supercomputer to slowly update their infrastructure<br clear="none">while taking no compute nodes (using nfs-hosted squashfs images or root)<br clear="none">down. It's really remarkable since it's a big jump too 7.9 to 9.3 I am<br clear="none">impressed by this part. It's a huge relief that I didn't have to do an<br clear="none">intermediate jump to gluster8 in the middle as that would have been<br clear="none">nearly impossible for us to get right.<br clear="none"><br clear="none">Thank you all!!<br clear="none"><br clear="none">PS: Frontier will have 21 leader nodes running gluster servers.<br clear="none">Distributed/replicate in groups of 3 hosting nfs-exported squashfs image<br clear="none">objects for compute node root filesystems. Many thousands of nodes.<div class="yqt1386567399" id="yqtfd44200"><br clear="none"><br clear="none">> <br clear="none">> Best Regards,<br clear="none">> Strahil Nikolov<br clear="none">> <br clear="none">> <br clear="none">>     On Tue, Sep 21, 2021 at 0:46, Erik Jacobson<br clear="none">>     <<a shape="rect" ymailto="mailto:erik.jacobson@hpe.com" href="mailto:erik.jacobson@hpe.com">erik.jacobson@hpe.com</a>> wrote:<br clear="none">>     I pretended I'm a low-level C programmer with network and filesystem<br clear="none">>     experience for a few hours.<br clear="none">> <br clear="none">>     I'm not sure what the right solution is but what was happening was the<br clear="none">>     code was trying to treat our IPV4 hosts as AF_INET6 and the family was<br clear="none">>     incompatible with our IPV4 IP addresses. Yes, we need to move to IPV6<br clear="none">>     but we're hoping to do that on our own time (~50 years like everybody<br clear="none">>     else :)<br clear="none">> <br clear="none">>     I found a chunk of the code that seemed to be force-setting us to<br clear="none">>     AF_INET6.<br clear="none">> <br clear="none">>     While I'm sure it is not 100% the correct patch, the patch attached and<br clear="none">>     pasted below is working for me so I'll integrate it with our internal<br clear="none">>     build to continue testing.<br clear="none">> <br clear="none">>     Please let me know if there is a configuration item I missed or a<br clear="none">>     different way to do this. I added -devel to this email.<br clear="none">> <br clear="none">>     In the previous thread, you would have seen that we're testing a<br clear="none">>     hopeful change that will upgrade our deployed customers from gluster<br clear="none">>     7.9 to gluster 9.3.<br clear="none">> <br clear="none">>     Thank you!! Advice on next steps would be appreciated !!<br clear="none">> <br clear="none">> <br clear="none">>     diff -Narup glusterfs-9.3-ORIG/rpc/rpc-transport/socket/src/name.c<br clear="none">>     glusterfs-9.3-NEW/rpc/rpc-transport/socket/src/name.c<br clear="none">>     --- glusterfs-9.3-ORIG/rpc/rpc-transport/socket/src/name.c    2021-06-29<br clear="none">>     00:27:44.381408294 -0500<br clear="none">>     +++ glusterfs-9.3-NEW/rpc/rpc-transport/socket/src/name.c    2021-09-20<br clear="none">>     16:34:28.969425361 -0500<br clear="none">>     @@ -252,9 +252,16 @@ af_inet_client_get_remote_sockaddr(rpc_t<br clear="none">>         /* Need to update transport-address family if address-family is not<br clear="none">>     provided<br clear="none">>             to command-line arguments<br clear="none">>         */<br clear="none">>     +    /* HPE This is forcing our IPV4 servers in to to an IPV6 address<br clear="none">>     +    * family that is not compatible with IPV4. For now we will just set it<br clear="none">>     +    * to AF_INET.<br clear="none">>     +    */<br clear="none">>     +    /*<br clear="none">>         if (inet_pton(AF_INET6, remote_host, &serveraddr)) {<br clear="none">>             sockaddr->sa_family = AF_INET6;<br clear="none">>         }<br clear="none">>     +    */<br clear="none">>     +    sockaddr->sa_family = AF_INET;<br clear="none">> <br clear="none">>         /* TODO: gf_resolve is a blocking call. kick in some<br clear="none">>             non blocking dns techniques */<br clear="none">> <br clear="none">>    <br clear="none">>     On Mon, Sep 20, 2021 at 11:35:35AM -0500, Erik Jacobson wrote:<br clear="none">>     > I missed the other important log snip:<br clear="none">>     ><br clear="none">>     > The message "E [MSGID: 101075] [common-utils.c:520:gf_resolve_ip6]<br clear="none">>     0-resolver: error in getaddrinfo [{family=10}, {ret=Address family for<br clear="none">>     hostname not supported}]" repeated 620 times between [2021-09-20<br clear="none">>     15:49:23.720633 +0000] and [2021-09-20 15:50:41.731542 +0000]<br clear="none">>     ><br clear="none">>     > So I will dig in to the code some here.<br clear="none">>     ><br clear="none">>     ><br clear="none">>     > On Mon, Sep 20, 2021 at 10:59:30AM -0500, Erik Jacobson wrote:<br clear="none">>     > > Hello all! I hope you are well.<br clear="none">>     > ><br clear="none">>     > > We are starting a new software release cycle and I am trying to find a<br clear="none">>     > > way to upgrade customers from our build of gluster 7.9 to our build of<br clear="none">>     > > gluster 9.3<br clear="none">>     > ><br clear="none">>     > > When we deploy gluster, we foribly remove all references to any host<br clear="none">>     > > names and use only IP addresses. This is because, if for any reason a<br clear="none">>     > > DNS server is unreachable, even if the peer files have IPs and DNS, it<br clear="none">>     > > causes glusterd to be unable to reach peers properly. We can't really<br clear="none">>     > > rely on /etc/hosts either because customers take artistic licene with<br clear="none">>     > > their /etc/hosts files and don't realize that problems that can cause.<br clear="none">>     > ><br clear="none">>     > > So our deployed peer files look something like this:<br clear="none">>     > ><br clear="none">>     > > uuid=46a4b506-029d-4750-acfb-894501a88977<br clear="none">>     > > state=3<br clear="none">>     > > hostname1=172.23.0.16<br clear="none">>     > ><br clear="none">>     > > That is, with full intention, we avoid host names.<br clear="none">>     > ><br clear="none">>     > > When we upgrade to gluster 9.3, we fall over with these errors and<br clear="none">>     > > gluster is now partitioned and the updated gluster servers can't reach<br clear="none">>     > > anybody:<br clear="none">>     > ><br clear="none">>     > > [2021-09-20 15:50:41.731543 +0000] E<br clear="none">>     [name.c:265:af_inet_client_get_remote_sockaddr] 0-management: DNS<br clear="none">>     resolution failed on host 172.23.0.16<br clear="none">>     > ><br clear="none">>     > ><br clear="none">>     > > As you can see, we have defined on purpose everything using IPs but in<br clear="none">>     > > 9.3 it appears this method fails. Are there any suggestions short of<br clear="none">>     > > putting real host names in peer files?<br clear="none">>     > ><br clear="none">>     > ><br clear="none">>     > ><br clear="none">>     > > FYI<br clear="none">>     > ><br clear="none">>     > > This supercomputer will be using gluster for part of its system<br clear="none">>     > > management. It is how we deploy the Image Objects (squashfs images)<br clear="none">>     > > hosted on NFS today and served by gluster leader nodes and also store<br clear="none">>     > > system logs, console logs, and other data.<br clear="none">>     > ><br clear="none">>     > > <a shape="rect" href="https://www.olcf.ornl.gov/frontier/" target="_blank">https://www.olcf.ornl.gov/frontier/</a><br clear="none">>     > ><br clear="none">>     > ><br clear="none">>     > > Erik<br clear="none">>     > > ________<br clear="none">>     > ><br clear="none">>     > ><br clear="none">>     > ><br clear="none">>     > > Community Meeting Calendar:<br clear="none">>     > ><br clear="none">>     > > Schedule -<br clear="none">>     > > Every 2nd and 4th Tuesday at 14:30 IST / 09:00 UTC<br clear="none">>     > > Bridge: <a shape="rect" href="https://meet.google.com/cpu-eiue-hvk" target="_blank">https://meet.google.com/cpu-eiue-hvk</a><br clear="none">>     > > Gluster-users mailing list<br clear="none">>     > > <a shape="rect" ymailto="mailto:Gluster-users@gluster.org" href="mailto:Gluster-users@gluster.org">Gluster-users@gluster.org</a><br clear="none">>     > > <a shape="rect" href="https://lists.gluster.org/mailman/listinfo/gluster-users" target="_blank">https://lists.gluster.org/mailman/listinfo/gluster-users</a><br clear="none">>     > ________<br clear="none">>     ><br clear="none">>     ><br clear="none">>     ><br clear="none">>     > Community Meeting Calendar:<br clear="none">>     ><br clear="none">>     > Schedule -<br clear="none">>     > Every 2nd and 4th Tuesday at 14:30 IST / 09:00 UTC<br clear="none">>     > Bridge: <a shape="rect" href="https://meet.google.com/cpu-eiue-hvk" target="_blank">https://meet.google.com/cpu-eiue-hvk</a><br clear="none">>     > Gluster-users mailing list<br clear="none">>     > <a shape="rect" ymailto="mailto:Gluster-users@gluster.org" href="mailto:Gluster-users@gluster.org">Gluster-users@gluster.org</a><br clear="none">>     > <a shape="rect" href="https://lists.gluster.org/mailman/listinfo/gluster-users" target="_blank">https://lists.gluster.org/mailman/listinfo/gluster-users</a><br clear="none">> <br clear="none"></div> </div> </blockquote></div>