On Thu, Apr 27, 2017 at 2:44 PM, Frederic Lecaille <flecai...@haproxy.com> wrote:
> On 04/27/2017 12:43 PM, Baptiste wrote: > >> >> >> On Thu, Apr 27, 2017 at 11:22 AM, Frederic Lecaille >> <flecai...@haproxy.com <mailto:flecai...@haproxy.com>> wrote: >> >> On 04/27/2017 10:47 AM, Frederic Lecaille wrote: >> >> Hello HAProxy ML, >> >> Please find attached to this mail a patch proposal which allows >> server FQDNs changes from stats socket. >> >> These FQDNs are also added to server-state file. >> >> Regards, >> >> Fred. >> >> >> A new version of this patch which fixes a memleak (server hostname >> was strdup() both in srv_set_fqdn() and srv_alloc_dns_resolution()). >> >> >> >> Hi Fred, >> > > Hi Baptiste, > > I did a quick read of the patch and I noticed the following points: >> >> - in update_server_fqdn(), I don't think it's relevant to perform the >> name resolution validation (the call to str2ip2) >> First, str2ip2 uses libc resolver, which may be different from the >> runtime resolver of HAProxy and second, it's up to the >> admin/devops/script which performs this change to ensure he is not >> messing up... >> > > Ok but will the new FQDN be resolved in any case after any update from > stats socket to match with the server IP address or is this something the > operator must also take care of (provide new FQDNs which may resolve to the > current IP address???)? >From my point of view, if no runtime resolution is configured, then changing the fqdn through the CLI should have no impact (since this is HAProxy's behavior since the beginning). Unless I misunderstood the purpose of this feature... By the way, I think that the call to getaddrinfo() in str2ip2 is blocking... Hence, if I'm not wrong about getaddrinfo, it's a definitive no-go to call str2ip2 at runtime. Baptiste
