Uploaded image for project: 'OpenShift Bugs'
  1. OpenShift Bugs
  2. OCPBUGS-36403

AdminAck test-case should not panic on Ginkgo's Fail

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Done
    • Icon: Undefined Undefined
    • None
    • 4.17
    • Test Framework
    • None
    • Moderate
    • None
    • 3
    • OTA 255, OTA 256
    • 2
    • False
    • Hide

      None

      Show
      None
    • Release Note Not Required
    • In Progress

      Description of problem

      Seen in some 4.17 update runs, like this one:

      disruption_tests: [bz-Cluster Version Operator] Verify presence of admin ack gate blocks upgrade until acknowledged expand_less	2h30m29s
      {Your Test Panicked
      github.com/openshift/origin/test/extended/util/openshift/clusterversionoperator/adminack.go:153
        When you, or your assertion library, calls Ginkgo's Fail(),
        Ginkgo panics to prevent subsequent assertions from running.
      
        Normally Ginkgo rescues this panic so you shouldn't see it.
      
        However, if you make an assertion in a goroutine, Ginkgo can't capture the
        panic.
        To circumvent this, you should call
      
        	defer GinkgoRecover()
      
        at the top of the goroutine that caused this panic.
      ...
      github.com/openshift/origin/test/extended/util/openshift/clusterversionoperator.getClusterVersion({0x8b34870, 0xc0004d3b20}, 0xc0004d3b20?)
      	github.com/openshift/origin/test/extended/util/openshift/clusterversionoperator/adminack.go:153 +0xee
      github.com/openshift/origin/test/extended/util/openshift/clusterversionoperator.getCurrentVersion({0x8b34870?, 0xc0004d3b20?}, 0xd18c2e2800?)
      	github.com/openshift/origin/test/extended/util/openshift/clusterversionoperator/adminack.go:163 +0x2c
      github.com/openshift/origin/test/extended/util/openshift/clusterversionoperator.(*AdminAckTest).Test(0xc001599de0, {0x8b34800, 0xc005a36910})
      	github.com/openshift/origin/test/extended/util/openshift/clusterversionoperator/adminack.go:72 +0x28d
      github.com/openshift/origin/test/e2e/upgrade/adminack.(*UpgradeTest).Test(0xc0018b23a0, {0x8b34608?, 0xccc6580?}, 0xc0055a3320?, 0xc0055ba180, 0x0?)
      	github.com/openshift/origin/test/e2e/upgrade/adminack/adminack.go:53 +0xfa
      ...
      

      We should deal with that noise, and get nicer error messages out of this test-case when there are hiccups calling getClusterVersion and similar.

      Version-Release number of selected component

      Seen in 4.17 CI, but it's fairly old code, so likely earlier 4.y are also exposed.

      How reproducible:

      Sippy reports 18 failures for this test-case vs. 250 success in the last week of periodic-ci-openshift-release-master-ci-4.17-e2e-gcp-ovn-upgrade runs. So fairly rare, but not crazy rare.

      Steps to Reproduce

      Run hundreds of periodic-ci-openshift-release-master-ci-4.17-e2e-gcp-ovn-upgrade and watch the Verify presence of admin ack gate blocks upgrade until acknowledged test-case.

      Actual results

      Occasional failures complaining about Ginko Fail panics.

      Expected results

      Reliable success.

              trking W. Trevor King
              trking W. Trevor King
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated:
                Resolved: