[
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 as _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 implementaiton of _IgniteTestContext_ may override the following
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 invokes any ducktape
services in the _before()_ it must provide implementation of this function to
let the testcase know actual number of cluster nodes still available.
Notes:
The original ducktape's _TestContext_ is replaced with the _IgniteTestContext_
(or its customized variant) during the application of the
_@ignitetest.utils.cluster_ decorator. So any ignite test MUST BE decorated
with the @{_}ignitetest.utils.cluster{_} decorator. It is already so anyway.
Any ignite test should use the _IgniteTest::available_cluster_size_ property to
determine the number of available cluster nodes. In particular it MUST NOT use
the _IgniteTest::test_context.cluster_ property directly since some nodes may
be already occupied by services invoked in customization.
***
In scope of this task some modifications were also done to let tests run
smoothly in presence of the customization:
# The *persistence_upgrade_test.py::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 framework was modified to let customization to extend set of listening
ignite events. The test affected is
{*}control_utility/consistency_test.py::ConsistencyTest{*}.
was:
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 as _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 implementaiton of _IgniteTestContext_ may override the following
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 invokes any ducktape
services in the _before()_ it must provide implementation of this function to
let the testcase know actual number of cluster nodes still available.
Notes:
The original ducktape's _TestContext_ is replaced with the _IgniteTestContext_
(or its customized variant) during the application of the
_@ignitetest.utils.cluster_ decorator. So any ignite test MUST BE decorated
with the @{_}ignitetest.utils.cluster{_} decorator. It is already so anyway.
Any ignite test should use the _IgniteTest::available_cluster_size_ property to
determine the number of available cluster nodes. In particular it MUST NOT use
the _IgniteTest::test_context.cluster_ property directly since some nodes may
be already occupied by services invoked in customization.
***
In scope of this task some modifications were also done to let tests run
smoothly in presence of the customization:
# The *persistence_upgrade_test.py::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 *auth_test.py::AuthenticationTests* uses the default ignite auth
implementation and fails if custom auth implementation if configured via the
globals. Solutuion - ignore test in such situation.
# The framework was modified to let customization to extend set of listening
ignite events. The test affected is
{*}control_utility/consistency_test.py::ConsistencyTest{*}.
> 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: 1h 10m
> 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 as _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 implementaiton of _IgniteTestContext_ may override the following
> 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 invokes any ducktape
> services in the _before()_ it must provide implementation of this function to
> let the testcase know actual number of cluster nodes still available.
> Notes:
> The original ducktape's _TestContext_ is replaced with the
> _IgniteTestContext_ (or its customized variant) during the application of the
> _@ignitetest.utils.cluster_ decorator. So any ignite test MUST BE decorated
> with the @{_}ignitetest.utils.cluster{_} decorator. It is already so anyway.
> Any ignite test should use the _IgniteTest::available_cluster_size_ property
> to determine the number of available cluster nodes. In particular it MUST
> NOT use the _IgniteTest::test_context.cluster_ property directly since some
> nodes may be already occupied by services invoked in customization.
>
> ***
> In scope of this task some modifications were also done to let tests run
> smoothly in presence of the customization:
> # The *persistence_upgrade_test.py::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 framework was modified to let customization to extend set of listening
> ignite events. The test affected is
> {*}control_utility/consistency_test.py::ConsistencyTest{*}.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
