Re: [PATCH] RFC: auto-t: fix netconfig to handle resolvconf values out of order

[Denis Kenzior <denkenz@gmail.com>]

Hi James,

On 2/28/24 06:40, James Prestwood wrote:
> The slaac_test was one that would occationally fail, but very rarely,
> due to the resolvconf log values appearing in an unexpected order.
> 
> This appears to be related to a typo in netconfig-commit which would
> not set netconfig-domains and instead set dns_list. This was fixed
> with a pending patch:
> 
> https://lore.kernel.org/iwd/20240227204242.1509980-1-denkenz@gmail.com/T/#u
> 
> But applying this now leads to testNetconfig failing slaac_test
> 100% of the time.
> 
> I'm not familiar enough with resolveconf to know if this test change
> is ok, but based on the test behavior the expected log and disk logs
> are the same, just in the incorrect order. I'm not sure if this the
> log order is deterministic so instead the check now iterates the
> expected log and verifies each value appears once in the resolvconf
> log.
> 
> Here is an example of the expected vs disk logs after running the
> test:
> 
> Expected:
> 
> -a wlan1.dns
> nameserver 192.168.1.2
> nameserver 3ffe:501:ffff:100::10
> nameserver 3ffe:501:ffff:100::50
> -a wlan1.domain
> search test1
> search test2
> 
> Resolvconf log:
> 
> -a wlan1.domain
> search test1
> search test2
> -a wlan1.dns
> nameserver 192.168.1.2
> nameserver 3ffe:501:ffff:100::10
> nameserver 3ffe:501:ffff:100::50
> ---
>   autotests/testNetconfig/slaac_test.py | 21 ++++++++++++++-------
>   1 file changed, 14 insertions(+), 7 deletions(-)
> 

Looks reasonable to me.  I'm okay applying this even as an RFC, unless you want 
to resend?

Regards,
-Denis