action #44582
closed[qam][functional][u] Test module "mariadb" seems to be not used anywhere
0%
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
Updated by okurz about 6 years ago
- Related to action #23348: [sle][security][fips] multi-machine tests for stunnel and mariadb added
Updated by okurz about 6 years ago
Seems my suspicion in https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/3441#pullrequestreview-57732181 was correct …
Updated by okurz almost 6 years ago
- Target version changed from Milestone 22 to Milestone 25
Updated by szarate over 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...
Updated by okurz over 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 ;)
Updated by mgriessmeier over 5 years ago
- Target version changed from Milestone 25 to Milestone 26
Updated by mgriessmeier over 5 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 =)
Updated by mgriessmeier over 5 years ago
- Status changed from Workable to New
- Assignee deleted (
szarate) - Target version changed from Milestone 27 to Milestone 28
to be rediscussed...
Updated by mgriessmeier almost 5 years ago
- Target version changed from Milestone 28 to Milestone 30
needs to be discussed offline
Updated by szarate almost 5 years ago
- Related to action #63871: [functional][u] test fails in php7_mysql - no answer from test_mysql_connector.php added
Updated by szarate almost 5 years ago
- Status changed from Blocked to Feedback
- Assignee set to dheidler
Updated by szarate almost 5 years ago
- Assignee changed from dheidler to szarate
Updated by szarate almost 5 years ago
- Assignee changed from szarate to dheidler
Updated by szarate almost 5 years ago
- Related to deleted (action #63871: [functional][u] test fails in php7_mysql - no answer from test_mysql_connector.php)
Updated by okurz almost 5 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.
Updated by szarate almost 5 years ago
- Status changed from Feedback to Rejected
rejecting in favor of 64051
Updated by szarate almost 5 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
Updated by okurz almost 5 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.