Oleg Ignatenko created IGNITE-9545:
--------------------------------------
Summary: IgniteProjectionStartStopRestartSelfTest: misleading
javadocs, required conditions are not described, inconvenient to configure
locally
Key: IGNITE-9545
URL: https://issues.apache.org/jira/browse/IGNITE-9545
Project: Ignite
Issue Type: Bug
Affects Versions: 2.6
Reporter: Oleg Ignatenko
This test has been [reported as
flaky|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&tab=testDetails&testNameId=2278553016619338221#analysis]
at Teamcity. Looking closer shows that there are some issues with the test.
[IgniteProjectionStartStopRestartSelfTest|https://github.com/apache/ignite/blob/master/modules/ssh/src/test/java/org/apache/ignite/internal/IgniteProjectionStartStopRestartSelfTest.java]
class javadocs provide instructions on how to configure test which have
nothing to do with the way how it is actually configured. Not only the way is
different but even respective property names are incorrect, which is easy to
see from very first 3 statements in test code that initialize configuration.
Checking git history of this file shows that root cause for this issue is a
change made about 4 years ago when obtaining test properties has changed from
{{GridTestProperties.getProperty}} to {{System.getenv}} (back then, also
property names have changed) but test javadoc was not updated to reflect that.
Another issue with javadoc which makes it unnecessarily difficult to
investigate failures is that it doesn't explain that test expects configured
target host to run ssh server and accept connections at configured port from
user with specified credentials.
Javadocs need to be corrected.
Another issue with the test is the way it obtains the config (username and
password): when I tried to do some quick experiments on my machine it turned
out fairly difficult to set to what I wanted. When I tried to change test code
to obtain config in the way how it was in the past (via {{GridTestProperties}})
it went much easier.
One good thing of the current way is it has proven to work well on Teamcity and
because of that it makes sense to keep it. But on the other hand it looks
desirable to augment it with fallback to the way that is more convenient for
local experimenting.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
