[ 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: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org