[
https://issues.apache.org/jira/browse/HDDS-1458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16845508#comment-16845508
]
Eric Yang commented on HDDS-1458:
---------------------------------
{quote}Can you please delete the original one from the compose/ozoneblockade
dir of the dirst tar.{quote}
Sure.
{quote}Can you please remove the -dev compose file? It can be confusing and
this is required only during the maven builds (In the current form the
dist-layout-stitching lines are duplicated. Fix me If I am wrong but the
compose files are copied twice{quote}
The two compose files are structured to handle in maven and in tarball
environment independently. With the recent changes to docker image build
process, we can remove -dev compose file.
{quote}Please use path which is relative to the py file instead of
getcwd:{quote}
In maven environment, it will try to use docker compose file in
${basedir}/target because it is localized with additional properties like
version number. The script path does not tell us where localized version of
docker compose file is relative to the script. This is the reason that the
script computes the current working directory for maven environment.
{quote}tests prefix is missing from README.md L38{quote}
Will check.
{quote} I didn't have time yet to understood ./start-build-env.sh changes. But
it may be better to do in a HADOOP jira to get more visibility. If I understood
well it's not directly required but it's a generic improvements to make it
possible to run the ozone tests in the build docker containers. What do you
think?{quote}
Ok, then we will need that patch check in before this one for maven verify to
work.
{quote}Can you please help me to understand why do we need to set OZONE_HOME in
hadoop-ozone/fault-injection-test/network-tests/pom.xml. The MAVEN_HOME seems
to be enough.{quote}
That is to make the script more proper, in the event that we want to run the
python script, and the docker compose files are not placed in the same location
as python script, it gives us a frame of reference to locate the required
files. I made a habit of using _HOME variable to look up relative path, in
case if we decided to move compose file to share/ozone/compose, it will be
easier to make reference change without depend on python script relative
location.
{quote} Not clear the expected relationship between the network-tests and dist.
Can we add a provided dependency between them to make it explicit?{quote}
They are independent of each other, there is no need to make explicit
dependencies. If we can do some more improvement to the docker compose files,
we might be able to do parallel build to speed up the time that it takes to run
fault injection tests: mvn -T 4 clean verify -Pit
> 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
> Fix For: 0.4.1
>
> Attachments: HDDS-1458.001.patch, HDDS-1458.002.patch,
> HDDS-1458.003.patch, HDDS-1458.004.patch, HDDS-1458.005.patch,
> HDDS-1458.006.patch, HDDS-1458.007.patch, HDDS-1458.008.patch,
> HDDS-1458.009.patch, HDDS-1458.010.patch
>
> Time Spent: 50m
> 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: hdfs-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
