Skip to content
GitLab
Projects Groups Topics Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Register
  • Sign in
  • forge forge
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributor statistics
    • Graph
    • Compare revisions
  • Issues 0
    • Issues 0
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 3
    • Merge requests 3
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Artifacts
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • ISC Open Source ProjectsISC Open Source Projects
  • forgeforge
  • Merge requests
  • !142

wait_for_message_count_in_log in flexid test

  • Review changes

  • Download
  • Patches
  • Plain diff
Merged Andrei Pavel requested to merge flexid into master Jan 14, 2021
  • Overview 6
  • Commits 4
  • Pipelines 5
  • Changes 3

Test tests/dhcpv4/kea_only/flexid/test_flex_id.py::test_v4_hooks_flexid_reconfigure failed for me before this fix at line 102:

            if presence:
>               assert len(world.srvmsg) != 0, "No response received."
E               AssertionError: No response received.
E               assert 0 != 0
E                +  where 0 = len([])
E                +    where [] = <thread._local object at 0x7fcecc6ef950>.srvmsg

When looking at the logs, I can see only 1 DHCP4_PACKET_RECEIVED instead of 2 and immediately after DHCP4_DYNAMIC_RECONFIGURATION and DHCP4_CONFIG_COMPLETE, the server is shutting down DHCPSRV_CLOSE_DB, DHCP4_SHUTDOWN. What I think happens is the second offer is sent while the server is reconfiguring, specifically before it has started listening on the interface again. This makes the package drop because nobody is listening on the interface. So instead of sleeping for a few seconds, this wait_for_message_count_in_log is used to wait for a certain event after which the server returns to normal service. A single wait for DHCP4_CONFIG_COMPLETE would have sufficed, but I left the wait for DHCP4_DYNAMIC_RECONFIGURATION to make sure that it is caused by reconfiguration.

I think a good number of sleeps are hacks that could be replaced by this waiting for events. :)

Assignee
Assign to
Reviewers
Request review from
Time tracking
Source branch: flexid