[
https://issues.apache.org/jira/browse/HDDS-1458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16838452#comment-16838452
]
Elek, Marton commented on HDDS-1458:
------------------------------------
{quote}Other smoketests base on docker-compose is also not easy to get them
running with docker swarm for distributed test because Docker documentation has
advice to [keep binary in docker image and remove Volume
requirement|https://docs.docker.com/compose/production/] for production
docker-compose to work with docker swarm. Hence, carrying any of the
integration tests in release tarball would not achieved the discussed end goals
from my point of view. I am in favor of defer the decision to carry tests in
release binary tarball to prevent us running in circular discussions. For the
moment, having a long path to start single node test for developer, is
inconvenient but we are not leading general users to a dead end.
{quote}
I would prefer to move out this discussion as well as I don't think it's
strongly related (we agreed to keep the support of the current structure)
# The key word in the link is "production". And I agree: keep binary in docker
image for production and use hadoop-runner for development. Running tests
during the vote is not a production use case.
# BTW, this is exactly the pattern what we follow. hadoop-runner is used for
dev (which provides faster and more consistent builds) and we provide
apache/ozone container and dev containres (k8s-dev profile) for real
distributed clusters.
# The definition of the smoke tests are split:
## robot framework defines small steps to execute commands and assert the
results
## Bash scripts (test.sh) define where the robot framework tests should be
executed
# In kubernetes, the same robot tests can be executed with different test.sh
(if the robot files are included in the distribution)
# Agree, the blockade tests can't be executed in kubernetes (chaos tests
should be implemented there), but I would prefer to keep them to make it easy
to execute them in any single-node environments.
> 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: 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: [email protected]
For additional commands, e-mail: [email protected]
