Hi Baptiste Were you able to look into this? A workaround is to use a dummy hostname, and init-addr like so :
server testserver13 dummyhost:9003 check init-addr last,10.0.19.10 server testserver14 dummyhost:9003 check init-addr last,10.0.19.12 # disabled placeholder server testserver15 dummyhost:9003 disabled check init-addr last,169.254.0.9 This works as expected, but seems like a hack to me. And the blog post should be updated to indicate this behaviour. -- Raghu On Mon, Jan 15, 2018 at 1:10 AM, Willy Tarreau <w...@1wt.eu> wrote: > Hi Raghu, > > On Sun, Jan 14, 2018 at 05:59:16PM +0530, Raghu Udiyar wrote: > > Hi Willy > > > > Yes, this patch works, no more segfaults. > > > > However, unrelated to this issue, while testing I noticed that the > address > > from the state file is not applied if the configuration does not use a > > hostname. > > > > In the example I provided, the configuration originally has the IP > address > > set to 169.254.0.9, which is then updated through the socket to say > 10.0.19.17. > > I noticed it as well but I thought I was the one doing something wrong. > CCing Baptiste in case he remembers certain cases that have to be > addressed a specific way by the state file. I remember this stuff was > tested quite a bit so I suspect that it could depend on certain > conditions. > > > Expectation was that upon haproxy restart the address in the state fill > > will override the address in the configuration, but this does not happen. > > > > I see the relevant code in srv_init_addr : > > > > if (srv->hostname) > > return_code |= srv_iterate_initaddr(srv); > > > > As per the server-template example in the dynamic scaling blog post, this > > should have been supported. Am I missing some configuration? > > I can't really tell, let's wait for Baptiste's opinion on this. > > Thanks, > Willy >
