[tests/acl] rewrite ACL test on pytest #1047
Conversation
Signed-off-by: Stepan Blyschak <stepanb@mellanox.com>
stepanblyschak
force-pushed
the
pytest-acl
branch
from
cc2d03c
to
9845b00
Compare
Signed-off-by: Stepan Blyschak <stepanb@mellanox.com>
Signed-off-by: Stepan Blyschak <stepanb@mellanox.com>
Signed-off-by: Stepan Blyschak <stepanb@mellanox.com>
Signed-off-by: Stepan Blyschak <stepanb@mellanox.com>
…ia pytest_runner.yml Signed-off-by: Stepan Blyschak <stepanb@mellanox.com>
Signed-off-by: Stepan Blyschak <stepanb@mellanox.com>
Signed-off-by: Stepan Blyschak <stepanb@mellanox.com>
Signed-off-by: Stepan Blyschak <stepanb@mellanox.com>
Signed-off-by: Stepan Blyschak <stepanb@mellanox.com>
| if 'failed' in res['localhost']: | ||
| if reboot_res.ready(): | ||
| logger.error('reboot result: {}'.format(reboot_res.get())) | ||
| raise Exception('DUT did not shutdown') |
There was a problem hiding this comment.
In recent testing, I found that on some testbed, rebooting happens fast. The wait_for module may not be able to detect the switch down event and timeout eventually. But indeed the switch rebooting was successful. I think it's better to ignore the failure of the wait_for down check and use uptime to verify that the switch was indeeded rebooted. For example:
- Get date and time on DUT before the reboot command is issued.
- After switch is up again (wait_for up succeeded), run "uptime -s" to get a new datetime. Assert that this new datetime is at least for example 10 seconds later than the previously recorded datetime.
There was a problem hiding this comment.
It's surprising to me that some SONiC system can reboot so fast.
Note, we execute reboot command in parallel to listening to SSH port. Assuming they start almost at the same time the reboot script itself has some serivces to stop, executes 'sleep 3', etc.
So reboot command definitely takes time (>3sec) by that time I think it is safe to assume wait_for routine has started. Even if reboot command execution time -> 0, the time it takes from grub to kernel to ssh service start is not 0,
There was a problem hiding this comment.
Theoretically it is correct. But I suspect there is other issue caused the host executing the wait_for ansible module not able to detect the SSH down status in time. Could you try the code on our testbed "mts-sonic-dut"?
|
Besides the concern of rebooting, other codes look good to me. |
Description of PR
Summary: rewrite ACL test on pytest
Fixes # (issue)
TODO:
Type of change
Approach
How did you do it?
How did you verify/test it?
Any platform specific information?
Supported testbed topology if it's a new test case?
Documentation