John, thanks for update. as resilution we have options: 1. for reduce issues with differen shell on different platforms - need try to look Python or Perl or something similar based framwork. 2. try to find good way for PATH to correct tools with tests - probably it can depend on (1) and use definitions for tools in new frameworks 3. probably to look for universal replacements for DF, DU, FIND, GREP, SED, etc - probabbly by separate functions implementations for tests - also depend on (1) 4. anything else ?
Maybe someone know some tests framework what can be looked/investigated for automations ? Ideas/links/ are welcome. We need automation framwork, where we can specify setup/cleanup procedures and describe steps with tests. this framework should provide abiliy for run one test or several tests. -Igor > On Jun 26, 2018, at 7:55 PM, John Kennedy <[email protected]> wrote: > > On Sun, Jun 24, 2018 at 1:21 PM Igor Kozhukhov <[email protected]> wrote: > >> I’d like propose to split zfs tests to 2 parts: >> 1 - zfs hellper binaries - what can be built on platform like Linux, >> FreeBSD, Linux, OSX - and used for zfs tests >> 2 - scripting part - can be used as is on all platforms. >> >> about srcipts. >> current zfs tests based on KSH and it is outdated on illumos. >> I’d like propose to move on to more portable/usable scrupts based on BASH or >> ZSH. > > There are certainly difficulties with using ksh for these tests. Shell > behavior can differ between shells, which can cause a variety of > problems. That said, I believe separating packages and migrating from > ksh to a more modern or widely used shell is simply trading one set of > problems for another, similar set. If we plan to undertake a project > to address these problems, I think the answer lies in a commonly > available scripting language like python. With platform specific > python functionality to perform zfs and zpool operations, this scheme > would have the added benefit of avoiding the problem of system > utilities that behave differently. grep on DilOS and DelphixOS may not > behave the same, but regex in python will. > >> Next problem: it is SUDO problem. >> current idea to use PATH to temporary directory with links to tools - >> failed, if /etc/sudoers contain full security set with definitions: >> Defaults env_reset >> Defaults >> secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" >> >> yes - they ara changes are recommended with securoty needs and on DilOS we >> are using Debian proposed configs with security needs. >> >> for zfs tests - we need a hack local /etc/sudoers file and disable these >> optinos - they are not described in README file because probably others >> platforms are using another /etc/sudoers files. >> with these security options we can’t use PATH with sudo -E. >> >> for reduce this issue with hacks of local /etc/sudoers file i’d like propose >> try to change logic with tools: probably will be much more better to use >> 'alias zpool=/sbin/zpool' - and use 'zpool' with correct pach where we need >> it ? > > I think it's reasonable for various distributions to have to do some > setup (like enabling sudo) in the CI infrastructure responsible for > running the tests. > >> Also, tests are failed with 4k drives with UFS (newfs) becasue: >> root@con6-vm-64:~# newfs /dev/dsk/c0t600144F07ADEAD1800005B2E7C150001d0s0 >> newfs: construct a new file system >> /dev/rdsk/c0t600144F07ADEAD1800005B2E7C150001d0s0: (y/n)? y >> The device sector size 4096 is not supported by ufs! > > This sure sounds like a test bug, but not necessarily related to the > larger discussion above. > > -- > John Wren Kennedy > http://www.delphix.com/ ------------------------------------------ openzfs: openzfs-developer Permalink: https://openzfs.topicbox.com/groups/developer/T42f8147492666f65-M70627b09a4d62093403d05af Delivery options: https://openzfs.topicbox.com/groups
