Uploaded image for project: 'Beaker (moved to puppet.atlassian.net)'
  1. Beaker (moved to puppet.atlassian.net)
  2. BKR-1002

Remove OR deprecate OR improve Beaker's `timesync` method



    • Bug
    • Status: Resolved
    • Normal
    • Resolution: Won't Do
    • None
    • None
    • windows
    • Quality Engineering
    • Needs Assessment


      Given the number of tickets filed, the Beaker timesync method has a bad reliability track record.

      For instance, when called against a Windows vmpooler host that is already properly configured to synchronize time, calling timesync will actually incorrectly set the time, output the message The computer did not resync because the required time change was too big, and it may take several minutes for the time to properly set. This could lead to cert requests being generated with the wrong timestamps or other non-deterministic time-related behavior that could be difficult / confusing to debug. Windows packer template changes are responsible for setting relevant GP settings in the registry up-front.

      I spent a bit of time trying to find a sequence of steps that could be reliably called against a Windows vmpooler machine, that would not generate error messages, and I was not successful. More detailed notes are available in PCP-625 comments - the code currently in Beaker is https://github.com/puppetlabs/beaker/blame/355c946185bdda0a67643718b556ccc42a069f24/lib/beaker/host_prebuilt_steps.rb#L43-L51

      That said, I recognize the importance of having a deterministic timesync helper for 3rd parties using Beaker, where nodes under test may not have a time synchronization mechanism rigged up - even if it's proving fragile / unnecessary for internal infrastructure in vmpooler.

      Some ideas:

      • Deprecate the helper and remove it in a later version (or potentially make it no-op)
      • Add documentation to Beaker noting the pitfalls of calling timesync under certain circumstances - it's particularly tricky for internal Puppet testing now as some templates have time synchronization baked in, while others do not (yet)
      • Spend more time on a more robust Windows solution - while I did attempt to avoid failures when enabling the w32time service and calling w32tm /resync, I did not perform any tests to see if the node was already configured. Perhaps there is a way to avoid running sync commands when a node is already synced. (There are some notes about Windows time sync commands, and using wmic to set dates that might prove useful)


        Issue Links



              Unassigned Unassigned
              ethan Ethan Brown
              0 Vote for this issue
              3 Start watching this issue



                Zendesk Support