[
https://issues.apache.org/jira/browse/IGNITE-16569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Korotkov updated IGNITE-16569:
-------------------------------------
Description:
Currently the ducktests can be customized only via the providing of external
implentations of _IgniteNodeSpec_ and _IgniteApplicationSpec_ classes. These
classes specify the enviroment (java command line options, specific ignite
configuration, extra libraries in the classpath) in which client and server
ignite nodes should be started. Names of actual classes to be used during the
test run are passed ad _NodeSpec_ and _AppSpec_ globals parameters.
The goal of this work is to add ability to add extra procedures to be invoked
_before_ and _after_ each testcase transparently via the globals parameters in
a way similar to described above for ignite nodes. It should be possible to
invoke of extra ducktape services in these procedures on the same testing
cluster.
*User API:*
User optionally passes the name of custom implementation of _IgniteTestContext_
class via the _globals_ parameter as
{code:java}
> ducktape --globals
> '{"IgniteTestContext":"utils.test_context.CustomTestContext"}' ... {code}
The custom implmentaiton of _IgniteTestContext_ may override the floowing
member functions:
* _before(self)_ - Actions to be done before any testcase start.
* {_}after(self, test_result) - A{_}ctions to be done after testcase finish.
The result of the original test is passed to this function for additional
analysis if needed. The _after()_ implementation may either return result
without modifications or return the customized one. The final test result would
be the one returned from this function.
* _available_cluster_size(self) -_ if customization invoke any ducktape
services in the _before()_ it must provide implementaiton of this function to
let the testcase know actual number of cluster nodes still available.
*Implementaiton:*
There are several problems in ducktest which should be fixed to let them run in
different configurations:
# The *PersistenceUpgradeTest* fails if SSL is enabled via the --globals
options. The immediate reason is that control.sh doesn't support the SSL
options (like key_store_path) in the 2.7.6 version which is the starting point
for the test incremental migrations of the PDS. Solution is to ignore test if
SSL is enabled.
# The *AuthenticationTests* uses the hardcoded username and password and
ignores ones passed via the globals.
was:
There are several problems in ducktest which should be fixed to let them run in
different configurations:
# The *PersistenceUpgradeTest* fails if SSL is enabled via the --globals
options. The immediate reason is that control.sh doesn't support the SSL
options (like key_store_path) in the 2.7.6 version which is the starting point
for the test incremental migrations of the PDS. Solution is to ignore test if
SSL is enabled.
# The *AuthenticationTests* uses the hardcoded username and password and
ignores ones passed via the globals.
> Add ability to customize the test context for ducktest
> ------------------------------------------------------
>
> Key: IGNITE-16569
> URL: https://issues.apache.org/jira/browse/IGNITE-16569
> Project: Ignite
> Issue Type: Bug
> Reporter: Sergey Korotkov
> Assignee: Sergey Korotkov
> Priority: Minor
> Labels: ducktests
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Currently the ducktests can be customized only via the providing of external
> implentations of _IgniteNodeSpec_ and _IgniteApplicationSpec_ classes. These
> classes specify the enviroment (java command line options, specific ignite
> configuration, extra libraries in the classpath) in which client and server
> ignite nodes should be started. Names of actual classes to be used during the
> test run are passed ad _NodeSpec_ and _AppSpec_ globals parameters.
> The goal of this work is to add ability to add extra procedures to be invoked
> _before_ and _after_ each testcase transparently via the globals parameters
> in a way similar to described above for ignite nodes. It should be possible
> to invoke of extra ducktape services in these procedures on the same testing
> cluster.
> *User API:*
> User optionally passes the name of custom implementation of
> _IgniteTestContext_ class via the _globals_ parameter as
> {code:java}
> > ducktape --globals
> > '{"IgniteTestContext":"utils.test_context.CustomTestContext"}' ... {code}
>
> The custom implmentaiton of _IgniteTestContext_ may override the floowing
> member functions:
> * _before(self)_ - Actions to be done before any testcase start.
> * {_}after(self, test_result) - A{_}ctions to be done after testcase finish.
> The result of the original test is passed to this function for additional
> analysis if needed. The _after()_ implementation may either return result
> without modifications or return the customized one. The final test result
> would be the one returned from this function.
> * _available_cluster_size(self) -_ if customization invoke any ducktape
> services in the _before()_ it must provide implementaiton of this function to
> let the testcase know actual number of cluster nodes still available.
> *Implementaiton:*
>
>
> There are several problems in ducktest which should be fixed to let them run
> in different configurations:
> # The *PersistenceUpgradeTest* fails if SSL is enabled via the --globals
> options. The immediate reason is that control.sh doesn't support the SSL
> options (like key_store_path) in the 2.7.6 version which is the starting
> point for the test incremental migrations of the PDS. Solution is to ignore
> test if SSL is enabled.
> # The *AuthenticationTests* uses the hardcoded username and password and
> ignores ones passed via the globals.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
