[
https://issues.apache.org/jira/browse/HDDS-1458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16833024#comment-16833024
]
Eric Yang commented on HDDS-1458:
---------------------------------
[~elek] {quote}1. The builds are slower, we would have huge number unnecessary
io operation.{quote}
Without running unit tests, Ozone maven build is about 2 minutes on my laptop
with virtualbox. The docker process adds 32 seconds. It is 26% increase in
build time, but user can use -DskipDocker flag to get exactly the same 2
minutes build. I don't think this is a deal breaker when docker build is
useful for integration test instead of unit test. Docker image building
frequency doesn't need to be as frequent, if code can be unit tested.
{quote}2. It's harder to test locally the patches. The reproducibility are
decreased. (Instead of the final build a local container is used).{quote}
Not true. Docker can use a local container or use official image by supplying
-DskipDocker flag, and let docker compose yaml file decide to use local image
or official released binary for fault-injection-test maven project. If you
want to apply patch to official released docker image, then you are are already
replacing binaries in docker image, it is no longer the official released
docker image. Therefore, what is wrong with using a local image that give you
exactly same version of everything that is described in Dockerfile of the
official image?
{quote}3. It's harder to test a release package from the smoketest
directory.{quote}
Smoketest can converted to another submodule of ozone. The same -DskipDocker
can run smoketest with official build without using local image. I will spend
some time on this part of the project to make sure that I didn't break anything.
{quote}4. Security fixes can be applied later to the docker containers.{quote}
The correct design is to swap out the docker container completely with a new
version. Patch and upgrade strategy should not be in-place modification of the
docker container that grows over time. Overlay file system will need to be
committed to retain state. By running container with in place binary
replacement can lead to inconsistent state of docker container when power
failure happens.
{quote}5. It conflicts if more than one builds are executed on the same machine
(docker images are shared but volume mounts are separated). (Even just this one
is a blocker problem for me){quote}
Does this mean you have multiple source tree running build? Why not use
multiple start-build-env.sh on parallel source trees? I think it can provide
the same multi-build process, but need to test it out.
{quote}6. Some tests can't be executed from the final tarball. (I would like to
execute tests from the released binary, as discussed earlier in the original
jira).{quote}
Same answer as before use -DskipDocker flag, or use mvn install final tarball,
and run docker build. Maybe I am missing something, please clarify.
I have a hard time with Ozone stable _environment_. Hadoop-runner is a read
only file system without symlink support, and all binaries and data are mounted
from external volume. What benefit does this provide? Everything is
interacting with outside of the container environment. What containment does
this style of docker image provides? I only see process namespace isolation,
network interface simulation. But it lacks of ability to make docker container
idempotent and reproducible else where. This can create problems that code
only works in one node but can not reproduce else where. I often see
distributed software being developed on one laptop, and having trouble to run
in cluster of nodes. The root cause is the mounted volume is shared between
containers, and developers often forgot about this and wrote code that does
local IO access. When it goes to QA, nothing works in distributed nodes. It
would be good to prevent ourselves from making this type of mistakes by not
sharing the same mount points between containers as base line. I know that you
may not have this problem with deeper understanding of distributed file system.
However, it is common mistake among junior system developers. Application
programmers may use shared volumes to exchange data between containers, but not
the team that suppose to build distributed file system. I would like to
prevent this type of silliness from happening by making sure that ozone
processes don't exchange data via shared volumes.
I haven't seen a project in Dockerhub that use the same technique as option 2.
Can you show me some examples of similar projects?
> 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,
> HDDS-1458.003.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]
