Project

General

Profile

Actions

action #44582

closed

[qam][functional][u] Test module "mariadb" seems to be not used anywhere

Added by okurz over 5 years ago. Updated about 4 years ago.

Status:
Rejected
Priority:
High
Assignee:
Category:
Bugs in existing tests
Target version:
SUSE QA - Milestone 30
Start date:
2018-11-30
Due date:
% Done:

0%

Estimated time:
Difficulty:

Description

Observation

$ git grep mariadb
lib/repo_tools.pm:    assert_screen 'smt-mariadb-password', 60;
lib/repo_tools.pm:    # install RMT and mariadb
lib/repo_tools.pm:    zypper_call 'in mariadb';
tests/console/mariadb.pm:# Summary: client part of mariadb ssl connection test
tests/console/mariadb.pm:    zypper_call('in mariadb-client');
tests/console/mariadb.pm:    mutex_lock('mariadb');
tests/console/mariadb.pm:    mutex_unlock('mariadb');
tests/console/mariadb.pm:    assert_screen 'mariadb-monitor-password';
tests/console/mariadb.pm:    assert_screen 'mariadb-monitor-opened', 60;
tests/console/mysql_odbc.pm:    assert_script_run "echo [mariadbodbc_mysql_dsn] > /etc/unixODBC/odbc.ini";
tests/console/mysql_odbc.pm:    assert_script_run "echo Driver=mariadbodbc_mysql >> /etc/unixODBC/odbc.ini";
tests/console/mysql_odbc.pm:    assert_script_run "echo [mariadbodbc_mysql] > /etc/unixODBC/odbcinst.ini";
tests/console/mysql_odbc.pm:    my $odbc = (!is_sle('<15') && !is_leap('<15.0')) ? 'mariadb-connector-odbc' : 'MyODBC-unixODBC';
tests/console/mysql_odbc.pm:    zypper_call 'in mysql mariadb-client sudo ' . $odbc;
tests/console/mysql_odbc.pm:    assert_script_run 'isql mariadbodbc_mysql_dsn root x -b < query.sql';
tests/support_server/setup.pm:sub setup_mariadb_server {
tests/support_server/setup.pm:    zypper_call('in mariadb');
tests/support_server/setup.pm:    assert_screen 'mariadb-monitor-opened';
tests/support_server/setup.pm:    assert_screen 'mariadb-user-host';
tests/support_server/setup.pm:    assert_screen 'mariadb-grant-ok';
tests/support_server/setup.pm:    if (exists $server_roles{mariadb}) {
tests/support_server/setup.pm:        setup_mariadb_server;
tests/support_server/setup.pm:        push @mutexes, 'mariadb';
tests/x11/smt_disconnect_internal.pm:    assert_screen("smt-mariadb-password-required");
$ openqa-db_query_last_use_of_module --openqa-host openqa.suse.de --module mariadb
(nothing)

Acceptance criteria

  • AC1: "mariadb" is scheduled and working

Related issues 1 (0 open1 closed)

Related to openQA Tests - action #23348: [sle][security][fips] multi-machine tests for stunnel and mariadbResolvedmitiao2017-08-14

Actions
Actions #1

Updated by okurz over 5 years ago

  • Related to action #23348: [sle][security][fips] multi-machine tests for stunnel and mariadb added
Actions #3

Updated by okurz about 5 years ago

  • Target version changed from Milestone 22 to Milestone 25
Actions #4

Updated by szarate almost 5 years ago

  • Status changed from New to In Progress
  • Assignee set to szarate

Then let's rethink the unused modules static test, because seems to be not working as expected...

Actions #5

Updated by okurz almost 5 years ago

sure, if you have a good idea. The problem about "mariadb" is that other test modules install mariadb so the term "mariadb" is mentioned by some test modules. What tools/detect_unused_modules does is looking if the according test module name is mentioned anywhere else. Enough to detect if "yast2_nfs_server" or "first_boot" is mentioned in main.pm, not enough to check if "mariadb" is actually scheduled as a test module ;)

Actions #6

Updated by mgriessmeier almost 5 years ago

  • Target version changed from Milestone 25 to Milestone 26
Actions #7

Updated by szarate almost 5 years ago

  • Status changed from In Progress to Workable
Actions #8

Updated by mgriessmeier over 4 years ago

  • Priority changed from Normal to High
  • Target version changed from Milestone 26 to Milestone 27

@santi let's check how to proceed here together =)

Actions #10

Updated by mgriessmeier over 4 years ago

  • Status changed from Workable to New
  • Assignee deleted (szarate)
  • Target version changed from Milestone 27 to Milestone 28

to be rediscussed...

Actions #11

Updated by SLindoMansilla over 4 years ago

  • Status changed from New to Blocked
Actions #12

Updated by mgriessmeier over 4 years ago

  • Target version changed from Milestone 28 to Milestone 30

needs to be discussed offline

Actions #13

Updated by szarate about 4 years ago

  • Related to action #63871: [functional][u] test fails in php7_mysql - no answer from test_mysql_connector.php added
Actions #14

Updated by szarate about 4 years ago

  • Status changed from Blocked to Feedback
  • Assignee set to dheidler
Actions #15

Updated by szarate about 4 years ago

  • Assignee changed from dheidler to szarate
Actions #16

Updated by szarate about 4 years ago

  • Assignee changed from szarate to dheidler
Actions #17

Updated by szarate about 4 years ago

  • Related to deleted (action #63871: [functional][u] test fails in php7_mysql - no answer from test_mysql_connector.php)
Actions #18

Updated by szarate about 4 years ago

  • Status changed from Feedback to Resolved
Actions #19

Updated by okurz about 4 years ago

  • Status changed from Resolved to Feedback

this is certainly an interesting interpretation of "Resolved" :D

I consider it a bit dangerous to call the ticket resolved with a link to the PR. People that are actively looking for mariadb due to the recent test regression might assume that "test is there and works fine" but your resolution was actually to delete the complete test.
Just to make sure we have a common understanding. The acceptance criterion mentions ""mariadb" is scheduled and working" which isn't fulfilled by having the test module removed.

Actions #21

Updated by szarate about 4 years ago

  • Status changed from Feedback to Rejected

rejecting in favor of 64051

Actions #22

Updated by szarate about 4 years ago

rejecting in favor of 64051

okurz wrote:

this is certainly an interesting interpretation of "Resolved" :D

I can't remember why I didn't set it to rejected, in any case rejecting in favor of 64051

I consider it a bit dangerous to call the ticket resolved with a link to the PR. People that are actively looking for mariadb due to the recent test regression might assume that "test is there and works fine" but your resolution was actually to delete the complete test.

Well, since there's no plan, nobody actually looked for mariadb tests, the test module wasn't scheduled, and it was deleted... the ticket bureucracy is too much, and tickets as old as this one, don't help

Just to make sure we have a common understanding. The acceptance criterion mentions ""mariadb" is scheduled and working" which isn't fulfilled by having the test module removed.

See acceptance criteria of the aforementioned ticket

Actions #23

Updated by okurz about 4 years ago

szarate wrote:

[…]

I consider it a bit dangerous to call the ticket resolved with a link to the PR. People that are actively looking for mariadb due to the recent test regression might assume that "test is there and works fine" but your resolution was actually to delete the complete test.
Well, since there's no plan, nobody actually looked for mariadb tests, the test module wasn't scheduled, and it was deleted... the ticket bureucracy is too much, and tickets as old as this one, don't help

I was looking for mariadb tests, the ticket was just not followed up with for a long time. And there are multiple incarnations of a test plan including main.pm from where mariadb probably vanished by mistake. Mistakes can happen but I doubt explicitly deleting the test module and accepting that in a code review is done "by mistake". I don't think mariadb mentioned anywhere else – which I am sure is as part of "what should be tested" would have stopped you from deleting the test module. This is why I consider this a dangerous approach.

Actions

Also available in: Atom PDF