From owner-svn-src-all@freebsd.org Tue Jan 29 17:06:47 2019 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 21D5E14C42EE; Tue, 29 Jan 2019 17:06:47 +0000 (UTC) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7DEF18FCA1; Tue, 29 Jan 2019 17:06:46 +0000 (UTC) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x0TH6iZ0009240; Tue, 29 Jan 2019 09:06:44 -0800 (PST) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id x0TH6iKg009239; Tue, 29 Jan 2019 09:06:44 -0800 (PST) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <201901291706.x0TH6iKg009239@pdx.rh.CN85.dnsmgr.net> Subject: Re: svn commit: r343543 - head/sbin/bectl/tests In-Reply-To: <82187F03-C50D-4430-9764-ABA6E28125E9@gmail.com> To: Enji Cooper Date: Tue, 29 Jan 2019 09:06:44 -0800 (PST) CC: rgrimes@freebsd.org, Kyle Evans , src-committers , svn-src-all@freebsd.org, svn-src-head@freebsd.org Reply-To: rgrimes@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 7DEF18FCA1 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.95 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.95)[-0.955,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2019 17:06:47 -0000 [ Charset UTF-8 unsupported, converting... ] > On Jan 28, 2019, at 20:31, Rodney W. Grimes wrote: > > >>> On Mon, Jan 28, 2019 at 10:09 PM Kyle Evans wrote: > >>> > >>> Author: kevans > >>> Date: Tue Jan 29 04:08:49 2019 > >>> New Revision: 343543 > >>> URL: https://svnweb.freebsd.org/changeset/base/343543 > >>> > >>> Log: > >>> bectl(8) test: Force destroy the zpool in cleanup > >>> > >>> This is a wild guess as to why bectl tests failed once upon a time in CI, > >>> given no apparent way to see a transcript of cleanup routines with Kyua. The > >>> bectl tests construct a new, clean zpool for every test. The failure > >>> indicated was because of a mount that was leftover from a previous test, but > >>> the previous test had succeeded so it's not clear how the mount remained > >>> leftover unless the `zpool get health ${pool}` had somehow failed. > >>> > >> > >> I left out: the tests are supposed to be constructed to clean up any > >> mounts that were left over in the course of the test, hence the > >> assumption that the failure lies in the cleanup. > > Hi Rod, > > > From my experience as a hardware test engineer the test > > setup was required to make sure any of those assumptions > > are valid. Meaning that the test would have to validate > > that no left over cruft was going to interfere with the > > test about to be run. > > > > Ie, you should probably do a force destroy of the pool > > *before* the test too. > > While this approach makes sense and is valid, it would leave open/orphaned resources after each test run (in this case a single zpool). It?s best to fix the underlying issue with how the test formulates, sets up, and tears down the zpool. I did not advocate in any way that the post run cleanup should be removed. Infact you should have both a pre-test assurance that the environment is correct and a post-test cleanup trying to removall all artifacts. You can fix the current issue, but eventually if you get enough testing going on your going to start to find that things fail in ways that do not clean up (machine crash is one instance) and not doing a pretest cleanup is eventually going to run aground of this pitfall. -- Rod Grimes rgrimes@freebsd.org