Federico Paolinelli comments

Results 511 comments of


                                            Federico Paolinelli

Is it worth using testcontainers to set up our unit, integration or e2e tests?

> * replicate what happens in [this test shell script](https://github.com/gomods/athens/blob/master/scripts/test_e2e.sh), it looks like it runs an empty program (empty main) first without configuring to download from Athens, then ensuring it...

Creating NDP responders returns errors for a long time after interface comes up

https://github.com/metallb/metallb/pull/1726 _might_ fix the issue. @john-a-joyce , would you mind trying to deploy directly from main? Also, note that now the configuration is crd based.

FRR BGP: service’s routes are always deleted and then created in a continuous loop

@cyclinder any luck with this?

FRR BGP: service’s routes are always deleted and then created in a continuous loop

np, thanks for getting back!

FRR BGP: service’s routes are always deleted and then created in a continuous loop

@cyclinder friendly reminder :-)

FRR BGP: service’s routes are always deleted and then created in a continuous loop

We did not change FRR in between versions. It might either be something external (i.e. related to your network), or a fix that we applied for some other reason that...

FRR BGP: service’s routes are always deleted and then created in a continuous loop

So you are saying 0.13.4 is bugged, and 0.13.7 is not, right?

FRR BGP: service’s routes are always deleted and then created in a continuous loop

... and it happens only when multihop=true, right?

FRR BGP: service’s routes are always deleted and then created in a continuous loop

I tried to run a diff, and the only two things around that area are: https://github.com/metallb/metallb/pull/1583 and https://github.com/metallb/metallb/pull/1607, which would explain a scenario where FRR receives an unnecessary configuration change...

FRR BGP: service’s routes are always deleted and then created in a continuous loop

> I tried to run a diff, and the only two things around that area are: #1583 and #1607, which would explain a scenario where FRR receives an unnecessary configuration...