Re: FreeBSD CI builds fail

[Jerome Magnin]

On Tue, Jul 23, 2019 at 08:37:37PM +0200, Jerome Magnin wrote:
> On Tue, Jul 23, 2019 at 07:09:57PM +0200, Tim Düsterhus wrote:
> > Jérôme,
> > Ilya,
> > 
> > I noticed that FreeBSD CI fails since
> > https://github.com/haproxy/haproxy/commit/885f64fb6da0a349dd3182d21d337b528225c517.
> > 
> > 
> > One example is here: https://github.com/haproxy/haproxy/runs/169980019
> > 
> > It should be investigated whether the reg-test is valid for FreeBSD and
> > either be fixed or disabled.
> > 
> > Best regards
> > Tim Düsterhus
> > 
> Thanks Tim and Ilya,
> 
> This one fails because there's a L4 timeout, I can probably update the regex 
> to
> take that into account, the interesting part is the failure and the step at
> which it fails, but for now we expect a connection failure and not a timeout.
> 
> I'm a bit more concerned about the other one reported by Ilya where the 
> backend
> server started by VTest won't accept connection. I'll look into this one
> further.

We have decided to exclude this test on non Linux system for the time being as
it triggers a race condition in VTest.
https://github.com/haproxy/haproxy/commit/0d00b544c3bdc9dc1796aca28bad46b3c1867184

Jérôme

Re: load-server-state-from-file "automatic" transfer?

[Daniel Schneller]

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  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