Hi! Thanks for taking a look and explaining. Should I create a ticket on GitHub for this?
Daniel > On 25. Jul 2019, at 10:44, William Lallemand <wlallem...@haproxy.com> wrote: > > On Thu, Jul 25, 2019 at 10:23:24AM +0200, Aleksandar Lazic wrote: >> Hi. >> >> Am 25.07.2019 um 10:06 schrieb William Lallemand: >>> On Thu, Jul 25, 2019 at 08:07:45AM +0200, Baptiste wrote: >>>> Hi Daniel, >>>> >>>> You're making a good point. Use the file system was the simplest and >>>> fastest way to go when we first designed this feature 4 or 5 years ago. >>>> I do agree that now with master/worker and threaded model being pushed that >>>> using the runtime-api may make sense and would be even more "cloud native". >>>> >>>> Maybe @William would have an advice on this one. >>>> >>>> Baptiste >>> >>> Hi, >>> >>> The simplest way to do that with the current architecture would be to do the >>> same thing as the "seamless reload" feature (-x). >>> >>> The new process will need to connect to the old one, send the `show servers >>> state` command, and then parse it using the server state file parser. >>> >>> However, what I don't like with this, is that we still need to configure a >>> "stats socket" manually in the configuration, it is not doable yet using the >>> internal socketpair of the master-worker model. >> >> How about to catch the idea from Daniel to use a *internal* peers setup for >> such >> states? >> > > I don't think it makes sense to use peers for that. > > The idea to do it with the stats socket is good, we only need to improve the > master-worker so a worker could use the socketpair to connect to another > worker. The only drawback is that it needs a configured stats socket in the > current model, but we already have this limitation with the seamless reload. > > -- > William Lallemand
signature.asc
Description: Message signed with OpenPGP
