[
https://issues.apache.org/jira/browse/HDDS-1458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16835881#comment-16835881
]
Eric Yang commented on HDDS-1458:
---------------------------------
[~elek] {quote}2. However you removed the blockade test from the release
package. Can you please keep this functionality (to execute tests from
distribution tar) as of now? And we agreed to support the execution of the
tests in both way, I would suggest to put all the new tests to the tar file as
well. Maybe we can create a new subdirectory for all the tests in the
tar.{quote}
Blockade tests will spawn docker cluster by itself using maven as mechanism to
start the bootstrap process. As long as the smoke test functionality is in
released source tarball. The feature can test with locally build image or
released docker hub image as intended. We must have better separation between
development/test artifacts and production binary image. In some enterprise, it
is forbidden to have gcc or maven build system in production environment for
security reasons. The current arrangement provides better organization from
enterprise point of view.
{quote}I think it will simplify the build process as you don't need the
maintain the dev compose files as they are already added to the distribution
under the compose folder (even better, we can execute the fault injection tests
in any of the provided environments: secure/not-secure, etc.){quote}
Patch 004 maintains two set of compose file because pytest test cases do not
know where to retrieve ozone binary from dev environment unless using local
relative path to reference ozone binaries. The relative location of ozone
binary is different between hadoop-ozone/dist/src/main/compose, and
fault-injection project. If the docker image is self contained, then we don't
need to maintain two separate sets of docker-compose files. For dev image, the
relative path to ozone changes between submodule projects. This is the reason
that fault-injection-test project carries two set of docker-compose files. If
you agree that fault-injection-test only test with self-contained docker image,
then I will remove dev version of docker compose files.
{quote}3. The docker-compose file of
"fault-injection-test/disk-tests/read-only-test" is not tested IMHO. The conf
directory should be moved out to a rw area as the configuration are generated
runtime based on the environment variables (I am fine to fix ii in a follow-up
jira){quote}
Are you using -Pit to trigger to profile to run? I agree that there are
missing runtime configuration, and java code to exercise the ozone cluster.
They are not part of current issue because HDDS-1495 is not settled. I agree
this area needs work in a follow-up issue and getting HDDS-1495 settled is our
top priority.
> Create a maven profile to run fault injection tests
> ---------------------------------------------------
>
> Key: HDDS-1458
> URL: https://issues.apache.org/jira/browse/HDDS-1458
> Project: Hadoop Distributed Data Store
> Issue Type: Test
> Reporter: Eric Yang
> Assignee: Eric Yang
> Priority: Major
> Labels: pull-request-available
> Attachments: HDDS-1458.001.patch, HDDS-1458.002.patch,
> HDDS-1458.003.patch, HDDS-1458.004.patch
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Some fault injection tests have been written using blockade. It would be
> nice to have ability to start docker compose and exercise the blockade test
> cases against Ozone docker containers, and generate reports. This is
> optional integration tests to catch race conditions and fault tolerance
> defects.
> We can introduce a profile with id: it (short for integration tests). This
> will launch docker compose via maven-exec-plugin and run blockade to simulate
> container failures and timeout.
> Usage command:
> {code}
> mvn clean verify -Pit
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
