-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update last tests for first version of test specification #684
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice work! I see now the container tests are really difficult to document, e.g., in comparison to DHCP client.
For the "test all possible interface combinations" test, @ahmkar94, me and wkz talked about how to describe networks that are internal to the DUT, like VETH pairs and bridges, that have no physical counterpart or connection to the host -- i.e., that we cannot describe in the topology.dot file. One option, that somehow was abandoned, was an ASCII art picture included in the top test docstring that would be translated to the Readme.adoc file. Maybe the container tests would benefit even more from this?
Example:
.-------------. .---------------. .--------.
| | tgt |---------| mgmt | | | web- |
| host | data |---------| data | target | | server |
'-------------' '---------------' '--------'
| /
br0 /
`----- veth0 -----'
Yes, it has been a struggle, An extra ASCII art I think will do it more understandable. But for now this will do, but of course you are right. We need do describe software-ports in a better way. |
3b55afc
to
976164d
Compare
The ASCII art over the topology must be surrounded by .... and is codeblock in ASCIIdoc. Since this is only used for ASCII arts to help describe tests, border and background are white.
976164d
to
65e5ab8
Compare
Description
Fix #606
Other information
Checklist
Tick relevant boxes, this PR is-a or has-a: