[
https://issues.apache.org/jira/browse/HDDS-1458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16832052#comment-16832052
]
Eric Yang commented on HDDS-1458:
---------------------------------
[~elek] {quote}starting docker based pseudo cluster from a (released or dev)
distribution. In this case the mount is not a problem. I think here we should
use mounting to ensure we have exactly the same bits inside and outside. I
can't see any problem here.{quote}
Dev can be tested with tarball. There is no need to involve docker until the
finished goods are ready for transport. Mount binaries outside of container is
making it more difficult to transport goods, hence defeats the purpose to use
container technology in the first place.
{quote}The second use case is to provide independent, portable docker-compose
files. We have this one even now:{quote}
Docker image is used as a configuration file transport mechanism. I think it's
convoluted process. There are more efficient way to transport config files
IMHO. Those instructions requires to run docker rm command to destroy the
instances as well.
{quote}5. The release tar file also contains the compose directory. I think
it's a very important part. With mounting the distribution package from the
docker-compose files we can provide the easiest UX to start a pseudo cluster
without any additional image creation.{quote}
Wouldn't it be better that we just give UX team yaml file, and let their
docker-compose fetch self contained docker images from dockerhub without
downloading the tarball? It seems that we are using the tools in most
inappropriate way of it's design that created more problems. There is no
guarantee for UX to get a successful run because tarballs and container images
may change overtime. There is no crc check or any transaction versioning
mechanism to ensure downloaded tarball can work with x version of docker image.
I am quite puzzle on the route chosen to mount binaries, it is like ordering a
container for moving between houses and put a key in container while leaving
all furniture outside of container. It works, but completely impractical.
> 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
> Attachments: HDDS-1458.001.patch, HDDS-1458.002.patch
>
>
> 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]
