Page MenuHomeFreeBSD

testing: re-implement some carp tests in python
Needs ReviewPublic

Authored by melifaro on May 16 2023, 3:06 PM.
Tags
None
Referenced Files
Unknown Object (File)
Apr 10 2024, 3:19 AM
Unknown Object (File)
Apr 9 2024, 7:00 PM
Unknown Object (File)
Feb 20 2024, 9:29 PM
Unknown Object (File)
Jan 1 2024, 5:51 AM
Unknown Object (File)
Nov 18 2023, 11:56 AM
Unknown Object (File)
Nov 18 2023, 11:45 AM
Unknown Object (File)
Nov 18 2023, 11:24 AM
Unknown Object (File)
Nov 8 2023, 1:37 PM

Details

Reviewers
kp
Summary

This change is a side-effect of debugging some carp behaviour.
Effectively it's a rewrite of carp:carp_basic_v[46] tests.
I'm not insisting to commit this. However, while it's doesn't provide much more value that the shell version, it can serve as a base for implementing more complex carp tests if so desired. Happy to discuss :-)

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Errors
SeverityLocationCodeMessage
Errortests/sys/netinet/carp.py:70E501PEP8 E501
Errortests/sys/netinet/carp.py:88E501PEP8 E501
Errortests/sys/netinet/carp.py:93E501PEP8 E501
Errortests/sys/netinet/carp.py:129E501PEP8 E501
Errortests/sys/netinet/carp.py:135E501PEP8 E501
Unit
No Test Coverage
Build Status
Buildable 51508
Build 48399: arc lint + arc unit

Event Timeline

melifaro added a reviewer: kp.
tests/sys/netinet/carp.py
105

Should we have some magic in TOPOLOGY handling so 'type: bridge' can just add interfaces to the bridge for us?

tests/sys/netinet/carp.py
105

Sounds interesting. That's not hard to implement.

User can the setup topology as

TOPOLOGY = {
    "vnet1": {"ifaces": ["epair2", "epair3", "bridge"]},
    "vnet2": {"ifaces": ["epair2"]},
    "vnet3": {"ifaces": ["epair3"]},
    "epair2": {"prefixes4": [("", "192.0.2.202/29")]},
    "epair3": {"prefixes4": [("", "192.0.2.203/29")]},
    "bridge": {"type": "bridge", "members": ["epair2", "epair3"], "prefixes4": [("192.0.2.4/29", "")]},
}

I'll look into that

To address the actual point of this review: I'm ambivalent. I still think Python doesn't contribute much for these specific tests (although there are cases where it does make more sense, such as the test_source_mac() test here). It also doesn't really seem significantly worse than the shell version, hence the ambivalence.