mbox series

[blktests,v1,00/11] Switch to allowed_host

Message ID 20230726124644.12619-1-dwagner@suse.de (mailing list archive)
Headers show
Series Switch to allowed_host | expand

Message

Daniel Wagner July 26, 2023, 12:46 p.m. UTC
Max asked me to replace replace the 'nvme/rc: Avoid triggering host nvme-cli
autoconnect' feature with using allowed_host on the target side [1]

So while looking into this new feature, I first started to refactor existing
code so that it looks a bit more consistent. I think there is even more
potential to make it smaller, by introducing something similiar to
_nvmet_passthru_target_setup() and _nvmet_passthru_target_cleanup() for non
passthru tests. A lot of duplicated setup/cleanup code in many tests.

Except the last two patches are just refactoring patches. So if we decide to use
common target setup/cleanup helpers, I think we could add them before the last
two patches, which would make the last patch way smaller.

Daniel

[1] https://lore.kernel.org/all/4b17be94-d068-f026-756f-59208075e254@nvidia.com/

Daniel Wagner (11):
  nvme/{003,004,005,013,046,049}: Group all variables declarations
  nvme: Reorganize test preamble code section
  nvme/rc: Add common subsystem nqn define
  nvme: Use def_subsysnqn variable instead local variable
  nvme/{041,042,043,044,045,048}: Remove local variable hostnqn and
    hostid
  nvme/rc: Add common file_path name define
  nvme: Use def_file_path variable instead local variable
  nvme/rc: Add common def_subsys_uuid define
  nvme: Use def_subsys_uuid variable
  nvme/rc: Add helper for adding/removing to allow list
  nvme: Add explicitly host to allow_host list

 tests/nvme/003 | 11 ++++----
 tests/nvme/004 | 27 +++++++++++---------
 tests/nvme/005 | 27 +++++++++++---------
 tests/nvme/006 | 21 ++++++++-------
 tests/nvme/007 | 20 ++++++---------
 tests/nvme/008 | 26 +++++++++----------
 tests/nvme/009 | 24 +++++++++---------
 tests/nvme/010 | 26 +++++++++----------
 tests/nvme/011 | 25 +++++++++---------
 tests/nvme/012 | 26 +++++++++----------
 tests/nvme/013 | 25 +++++++++---------
 tests/nvme/014 | 26 +++++++++----------
 tests/nvme/015 | 24 +++++++++---------
 tests/nvme/016 | 17 ++++++-------
 tests/nvme/017 | 26 ++++++++-----------
 tests/nvme/018 | 24 +++++++++---------
 tests/nvme/019 | 26 +++++++++----------
 tests/nvme/020 | 24 +++++++++---------
 tests/nvme/021 | 24 +++++++++---------
 tests/nvme/022 | 24 +++++++++---------
 tests/nvme/023 | 26 +++++++++----------
 tests/nvme/024 | 24 +++++++++---------
 tests/nvme/025 | 24 +++++++++---------
 tests/nvme/026 | 24 +++++++++---------
 tests/nvme/027 | 24 +++++++++---------
 tests/nvme/028 | 24 +++++++++---------
 tests/nvme/029 | 26 +++++++++----------
 tests/nvme/030 | 19 +++++++-------
 tests/nvme/031 | 14 +++++-----
 tests/nvme/033 |  9 ++++---
 tests/nvme/034 |  9 ++++---
 tests/nvme/035 |  9 ++++---
 tests/nvme/036 |  9 ++++---
 tests/nvme/037 |  8 +++---
 tests/nvme/038 |  6 ++---
 tests/nvme/039 |  4 +--
 tests/nvme/040 | 30 ++++++++++++----------
 tests/nvme/041 | 50 ++++++++++++++++--------------------
 tests/nvme/042 | 55 ++++++++++++++++++----------------------
 tests/nvme/043 | 52 +++++++++++++++++--------------------
 tests/nvme/044 | 69 +++++++++++++++++++++++---------------------------
 tests/nvme/045 | 61 ++++++++++++++++++++------------------------
 tests/nvme/046 |  1 +
 tests/nvme/047 | 30 +++++++++++-----------
 tests/nvme/048 | 46 +++++++++++++++------------------
 tests/nvme/049 |  1 +
 tests/nvme/rc  | 30 +++++++++++++++++++---
 47 files changed, 572 insertions(+), 585 deletions(-)

Comments

Shinichiro Kawasaki July 28, 2023, 8:20 a.m. UTC | #1
On Jul 26, 2023 / 14:46, Daniel Wagner wrote:
> Max asked me to replace replace the 'nvme/rc: Avoid triggering host nvme-cli
> autoconnect' feature with using allowed_host on the target side [1]
> 
> So while looking into this new feature, I first started to refactor existing
> code so that it looks a bit more consistent. I think there is even more
> potential to make it smaller, by introducing something similiar to
> _nvmet_passthru_target_setup() and _nvmet_passthru_target_cleanup() for non
> passthru tests. A lot of duplicated setup/cleanup code in many tests.

Thanks for this action :)

> 
> Except the last two patches are just refactoring patches. So if we decide to use
> common target setup/cleanup helpers, I think we could add them before the last
> two patches, which would make the last patch way smaller.

I ran 'make check' and saw shellecheck complaints below. I added 'export' to the
variables then they disappeared.

tests/nvme/rc:19:1: warning: def_subsysnqn appears unused. Verify use (or export if used externally). [SC2034]
tests/nvme/rc:20:1: warning: def_file_path appears unused. Verify use (or export if used externally). [SC2034]
tests/nvme/rc:21:1: warning: def_file_path appears unused. Verify use (or export if used externally). [SC2034]

I also ran nvme tests with the export fixes and saw no regression. Looks good
from test run point of view.
Daniel Wagner July 28, 2023, 8:59 a.m. UTC | #2
On Fri, Jul 28, 2023 at 08:20:55AM +0000, Shinichiro Kawasaki wrote:
> > Except the last two patches are just refactoring patches. So if we decide to use
> > common target setup/cleanup helpers, I think we could add them before the last
> > two patches, which would make the last patch way smaller.
> 
> I ran 'make check' and saw shellecheck complaints below. I added 'export' to the
> variables then they disappeared.
> 
> tests/nvme/rc:19:1: warning: def_subsysnqn appears unused. Verify use (or export if used externally). [SC2034]
> tests/nvme/rc:20:1: warning: def_file_path appears unused. Verify use (or export if used externally). [SC2034]
> tests/nvme/rc:21:1: warning: def_file_path appears unused. Verify use (or export if used externally). [SC2034]

These variables are not used in nvme/rc at the point I introduce them. Only in
the tests. I could add the nvmet setup/cleanup helpers with the variables which
would make those warnings go away. But these helpers would then add the end of
the series. Also not really good. I don't what is best here.

> I also ran nvme tests with the export fixes and saw no regression. Looks good
> from test run point of view.

Thanks!

BTW, I am off next week, so I don't think I send soon an update.