[jira] [Commented] (HDDS-1495) Create hadoop/ozone docker images with inline build process
[ https://issues.apache.org/jira/browse/HDDS-1495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16869682#comment-16869682 ] Eric Yang commented on HDDS-1495: - {quote}Current approach: no tarball creation is required to test everything in docker{quote} The current approach is risky from reproducibility point of view. This creates a directory structure of Ozone home that allows user to play in the sandbox without tarball creation. By making this two stage process, user can contaminated Ozone sandbox directory by running test or other operations. Hence, the resulting tarball creation may contain additional debris, if user allowed to play in the sandbox then run mvn package -Pdist without using clean. If mvn clean package -Pdist is performed, user still have to spend the extra time to create tarball, then play with the sandbox. By taking the tarball snapshot first, it is much safer to ensure no contamination of test result, or pyc files get included in tarball. {quote}Proposed approach: tarball creation (which is slow) is REQUIRED to run docker tests{quote} This is for sanitization to ensure user doesn't include addition debris when docker build is happening. The tarball creation is a out of band process. User can build tarball once, and focus on refining docker image without ever need to recreate the tarball when tarball requires no change. 5-7 seconds spent to include tarball binary in docker image ensure the test is carry out on docker image that closely represent distributed environment. Binary external of docker image creates many risk and limitations that hindered the process of testing docker image in real distributed environment. {quote}+1: the proposed approach has additional IO overhead, not just the tar file creation (copy tarball to the .m2/repository){quote} This is a user choice. User can choose to mvn install to populate .m2 cache, or use mvn package from the top level of Hadoop project. Mvn package doesn't generate the addition IO overhead and keep output in build directory. Maven designed the build system this way to enable user to produce modular component artifacts and work in small units without a full build. A well written maven project structure allows build from any of the submodules, which Hadoop project has the pride and joy to maintain this for 7+ years. Ozone dist project twisted meaning of dist-layout-stitching script is the worst kind of example to copy artifacts from hadoop-ozone-objectstore-service-${HDDS_VERSION} modules without given user the choice to use cache copy or the current build directory copy. This forces developer to use the only option to build entire Ozone project from top level of Hadoop project. The time wasted on building the entire project is what made development non-productive. I recommend to be more proficient in maven before making poor implementation choice for instant gratification that are hazard to developers health. {quote}+2: the proposed approach didn't address the earlier comments (use newer base image in case of a security issue){quote} Maven assembly plugin does address your question on how to build with newer OS image with released binary. Using maven assembly to build tarball, will allow deploy released binary tarball to maven central. There is no need to rebuild released Ozone tarball. User can simply rebuild Docker image using release Ozone tarball binary by specifying version of the tarball to build with. In my opinion, modularize docker build is a much better solution than current monolithic build that is incapable of reproducing dist project without a full build. {quote}+3: the proposed approach didn't address the other comments (make it possible to provide images for earlier hadoop releases){quote} Maven remote fetching technique can apply to download released Hadoop tarball by specifying remote URL to fetch. This is a standard technique used by almost all modern build tools, I don't see technical obstacle in the remote fetching solution. Please elaborate on the actual problem than provide blind statement that it doesn't work. > Create hadoop/ozone docker images with inline build process > --- > > Key: HDDS-1495 > URL: https://issues.apache.org/jira/browse/HDDS-1495 > Project: Hadoop Distributed Data Store > Issue Type: Sub-task >Reporter: Elek, Marton >Assignee: Eric Yang >Priority: Major > Attachments: HADOOP-16091.001.patch, HADOOP-16091.002.patch, > HDDS-1495.003.patch, HDDS-1495.004.patch, HDDS-1495.005.patch, > HDDS-1495.006.patch, HDDS-1495.007.patch, HDDS-1495.008.patch, Hadoop Docker > Image inline build process.pdf > > > This is proposed by [~eyang] in > [this|https://lists.apache.org/thread.html/33ac54bdeacb4beb023
[jira] [Commented] (HDDS-1495) Create hadoop/ozone docker images with inline build process
[ https://issues.apache.org/jira/browse/HDDS-1495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16869372#comment-16869372 ] Elek, Marton commented on HDDS-1495: Yes, but # Current approach: no tarball creation is required to test everything in docker # Proposed approach: tarball creation (which is slow) is REQUIRED to run docker tests +1: the proposed approach has additional IO overhead, not just the tar file creation (copy tarball to the .m2/repository) +2: the proposed approach didn't address the earlier comments (use newer base image in case of a security issue) +3: the proposed approach didn't address the other comments (make it possible to provide images for earlier hadoop releases) > Create hadoop/ozone docker images with inline build process > --- > > Key: HDDS-1495 > URL: https://issues.apache.org/jira/browse/HDDS-1495 > Project: Hadoop Distributed Data Store > Issue Type: Sub-task >Reporter: Elek, Marton >Assignee: Eric Yang >Priority: Major > Attachments: HADOOP-16091.001.patch, HADOOP-16091.002.patch, > HDDS-1495.003.patch, HDDS-1495.004.patch, HDDS-1495.005.patch, > HDDS-1495.006.patch, HDDS-1495.007.patch, HDDS-1495.008.patch, Hadoop Docker > Image inline build process.pdf > > > This is proposed by [~eyang] in > [this|https://lists.apache.org/thread.html/33ac54bdeacb4beb023ebd452464603aaffa095bd104cb43c22f484e@%3Chdfs-dev.hadoop.apache.org%3E] > mailing thread. > {quote}1, 3. There are 38 Apache projects hosting docker images on Docker hub > using Apache Organization. By browsing Apache github mirror. There are only 7 > projects using a separate repository for docker image build. Popular projects > official images are not from Apache organization, such as zookeeper, tomcat, > httpd. We may not disrupt what other Apache projects are doing, but it looks > like inline build process is widely employed by majority of projects such as > Nifi, Brooklyn, thrift, karaf, syncope and others. The situation seems a bit > chaotic for Apache as a whole. However, Hadoop community can decide what is > best for Hadoop. My preference is to remove ozone from source tree naming, if > Ozone is intended to be subproject of Hadoop for long period of time. This > enables Hadoop community to host docker images for various subproject without > having to check out several source tree to trigger a grand build. However, > inline build process seems more popular than separated process. Hence, I > highly recommend making docker build inline if possible. > {quote} > The main challenges are also discussed in the thread: > {code:java} > 3. Technically it would be possible to add the Dockerfile to the source > tree and publish the docker image together with the release by the > release manager but it's also problematic: > {code} > a) there is no easy way to stage the images for the vote > c) it couldn't be flagged as automated on dockerhub > d) It couldn't support the critical updates. > * Updating existing images (for example in case of an ssl bug, rebuild > all the existing images with exactly the same payload but updated base > image/os environment) > * Creating image for older releases (We would like to provide images, > for hadoop 2.6/2.7/2.7/2.8/2.9. Especially for doing automatic testing > with different versions). > {code:java} > {code} > The a) can be solved (as [~eyang] suggested) with using a personal docker > image during the vote and publish it to the dockerhub after the vote (in case > the permission can be set by the INFRA) > Note: based on LEGAL-270 and linked discussion both approaches (inline build > process / external build process) are compatible with the apache release. > Note: HDDS-851 and HADOOP-14898 contains more information about these > problems. -- 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
[jira] [Commented] (HDDS-1495) Create hadoop/ozone docker images with inline build process
[ https://issues.apache.org/jira/browse/HDDS-1495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16868943#comment-16868943 ] Eric Yang commented on HDDS-1495: - {quote}Care to explain why my core build path is slower with this patch? I am telling you the command that I use regularly to build, and my concern is really for the commands that I use.{quote} The current trunk takes a short cut that it keep binary tarball packaging a secondary step by invoking -Pdist profile. I think calling "mvn package", and not creating the package is a bit misleading, patch 005 was created prior to trunk made tarball creation optional. Patch 005 kept the tarball packaging inline of mvn package. The extra time was spent on making the tarball. It is possible to change the tarball creation to dist profile, and it would result in the same time spent. > Create hadoop/ozone docker images with inline build process > --- > > Key: HDDS-1495 > URL: https://issues.apache.org/jira/browse/HDDS-1495 > Project: Hadoop Distributed Data Store > Issue Type: Sub-task >Reporter: Elek, Marton >Assignee: Eric Yang >Priority: Major > Attachments: HADOOP-16091.001.patch, HADOOP-16091.002.patch, > HDDS-1495.003.patch, HDDS-1495.004.patch, HDDS-1495.005.patch, > HDDS-1495.006.patch, HDDS-1495.007.patch, HDDS-1495.008.patch, Hadoop Docker > Image inline build process.pdf > > > This is proposed by [~eyang] in > [this|https://lists.apache.org/thread.html/33ac54bdeacb4beb023ebd452464603aaffa095bd104cb43c22f484e@%3Chdfs-dev.hadoop.apache.org%3E] > mailing thread. > {quote}1, 3. There are 38 Apache projects hosting docker images on Docker hub > using Apache Organization. By browsing Apache github mirror. There are only 7 > projects using a separate repository for docker image build. Popular projects > official images are not from Apache organization, such as zookeeper, tomcat, > httpd. We may not disrupt what other Apache projects are doing, but it looks > like inline build process is widely employed by majority of projects such as > Nifi, Brooklyn, thrift, karaf, syncope and others. The situation seems a bit > chaotic for Apache as a whole. However, Hadoop community can decide what is > best for Hadoop. My preference is to remove ozone from source tree naming, if > Ozone is intended to be subproject of Hadoop for long period of time. This > enables Hadoop community to host docker images for various subproject without > having to check out several source tree to trigger a grand build. However, > inline build process seems more popular than separated process. Hence, I > highly recommend making docker build inline if possible. > {quote} > The main challenges are also discussed in the thread: > {code:java} > 3. Technically it would be possible to add the Dockerfile to the source > tree and publish the docker image together with the release by the > release manager but it's also problematic: > {code} > a) there is no easy way to stage the images for the vote > c) it couldn't be flagged as automated on dockerhub > d) It couldn't support the critical updates. > * Updating existing images (for example in case of an ssl bug, rebuild > all the existing images with exactly the same payload but updated base > image/os environment) > * Creating image for older releases (We would like to provide images, > for hadoop 2.6/2.7/2.7/2.8/2.9. Especially for doing automatic testing > with different versions). > {code:java} > {code} > The a) can be solved (as [~eyang] suggested) with using a personal docker > image during the vote and publish it to the dockerhub after the vote (in case > the permission can be set by the INFRA) > Note: based on LEGAL-270 and linked discussion both approaches (inline build > process / external build process) are compatible with the apache release. > Note: HDDS-851 and HADOOP-14898 contains more information about these > problems. -- 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
[jira] [Commented] (HDDS-1495) Create hadoop/ozone docker images with inline build process
[ https://issues.apache.org/jira/browse/HDDS-1495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16864592#comment-16864592 ] Anu Engineer commented on HDDS-1495: Care to explain why my core build path is slower with this patch? I am telling you the command that I use regularly to build, and my concern is really for the commands that I use. > Create hadoop/ozone docker images with inline build process > --- > > Key: HDDS-1495 > URL: https://issues.apache.org/jira/browse/HDDS-1495 > Project: Hadoop Distributed Data Store > Issue Type: Sub-task >Reporter: Elek, Marton >Assignee: Eric Yang >Priority: Major > Attachments: HADOOP-16091.001.patch, HADOOP-16091.002.patch, > HDDS-1495.003.patch, HDDS-1495.004.patch, HDDS-1495.005.patch, > HDDS-1495.006.patch, HDDS-1495.007.patch, HDDS-1495.008.patch, Hadoop Docker > Image inline build process.pdf > > > This is proposed by [~eyang] in > [this|https://lists.apache.org/thread.html/33ac54bdeacb4beb023ebd452464603aaffa095bd104cb43c22f484e@%3Chdfs-dev.hadoop.apache.org%3E] > mailing thread. > {quote}1, 3. There are 38 Apache projects hosting docker images on Docker hub > using Apache Organization. By browsing Apache github mirror. There are only 7 > projects using a separate repository for docker image build. Popular projects > official images are not from Apache organization, such as zookeeper, tomcat, > httpd. We may not disrupt what other Apache projects are doing, but it looks > like inline build process is widely employed by majority of projects such as > Nifi, Brooklyn, thrift, karaf, syncope and others. The situation seems a bit > chaotic for Apache as a whole. However, Hadoop community can decide what is > best for Hadoop. My preference is to remove ozone from source tree naming, if > Ozone is intended to be subproject of Hadoop for long period of time. This > enables Hadoop community to host docker images for various subproject without > having to check out several source tree to trigger a grand build. However, > inline build process seems more popular than separated process. Hence, I > highly recommend making docker build inline if possible. > {quote} > The main challenges are also discussed in the thread: > {code:java} > 3. Technically it would be possible to add the Dockerfile to the source > tree and publish the docker image together with the release by the > release manager but it's also problematic: > {code} > a) there is no easy way to stage the images for the vote > c) it couldn't be flagged as automated on dockerhub > d) It couldn't support the critical updates. > * Updating existing images (for example in case of an ssl bug, rebuild > all the existing images with exactly the same payload but updated base > image/os environment) > * Creating image for older releases (We would like to provide images, > for hadoop 2.6/2.7/2.7/2.8/2.9. Especially for doing automatic testing > with different versions). > {code:java} > {code} > The a) can be solved (as [~eyang] suggested) with using a personal docker > image during the vote and publish it to the dockerhub after the vote (in case > the permission can be set by the INFRA) > Note: based on LEGAL-270 and linked discussion both approaches (inline build > process / external build process) are compatible with the apache release. > Note: HDDS-851 and HADOOP-14898 contains more information about these > problems. -- 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
[jira] [Commented] (HDDS-1495) Create hadoop/ozone docker images with inline build process
[ https://issues.apache.org/jira/browse/HDDS-1495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16864518#comment-16864518 ] Eric Yang commented on HDDS-1495: - {quote}> mvn -f pom.ozone.xml clean package -DskipTests -Dmaven.javadoc.skip -Dskipshade{quote} The above command does not trigger docker build. It is a full build command except docker part. In order to trigger a docker build, you need to pass in -Pdocker-build for the current process. For the patched version, pass in -Pdocker The discussion of the performance improvement is about reiteration time spend for developer. If developer is working on Docker only, he can jump into docker module, and trigger build: {code} cd hadoop/hadoop-ozone/docker mvn package -Pdocker {code} This saves time for repeating the process without doing the full build. > Create hadoop/ozone docker images with inline build process > --- > > Key: HDDS-1495 > URL: https://issues.apache.org/jira/browse/HDDS-1495 > Project: Hadoop Distributed Data Store > Issue Type: Sub-task >Reporter: Elek, Marton >Assignee: Eric Yang >Priority: Major > Attachments: HADOOP-16091.001.patch, HADOOP-16091.002.patch, > HDDS-1495.003.patch, HDDS-1495.004.patch, HDDS-1495.005.patch, > HDDS-1495.006.patch, HDDS-1495.007.patch, HDDS-1495.008.patch, Hadoop Docker > Image inline build process.pdf > > > This is proposed by [~eyang] in > [this|https://lists.apache.org/thread.html/33ac54bdeacb4beb023ebd452464603aaffa095bd104cb43c22f484e@%3Chdfs-dev.hadoop.apache.org%3E] > mailing thread. > {quote}1, 3. There are 38 Apache projects hosting docker images on Docker hub > using Apache Organization. By browsing Apache github mirror. There are only 7 > projects using a separate repository for docker image build. Popular projects > official images are not from Apache organization, such as zookeeper, tomcat, > httpd. We may not disrupt what other Apache projects are doing, but it looks > like inline build process is widely employed by majority of projects such as > Nifi, Brooklyn, thrift, karaf, syncope and others. The situation seems a bit > chaotic for Apache as a whole. However, Hadoop community can decide what is > best for Hadoop. My preference is to remove ozone from source tree naming, if > Ozone is intended to be subproject of Hadoop for long period of time. This > enables Hadoop community to host docker images for various subproject without > having to check out several source tree to trigger a grand build. However, > inline build process seems more popular than separated process. Hence, I > highly recommend making docker build inline if possible. > {quote} > The main challenges are also discussed in the thread: > {code:java} > 3. Technically it would be possible to add the Dockerfile to the source > tree and publish the docker image together with the release by the > release manager but it's also problematic: > {code} > a) there is no easy way to stage the images for the vote > c) it couldn't be flagged as automated on dockerhub > d) It couldn't support the critical updates. > * Updating existing images (for example in case of an ssl bug, rebuild > all the existing images with exactly the same payload but updated base > image/os environment) > * Creating image for older releases (We would like to provide images, > for hadoop 2.6/2.7/2.7/2.8/2.9. Especially for doing automatic testing > with different versions). > {code:java} > {code} > The a) can be solved (as [~eyang] suggested) with using a personal docker > image during the vote and publish it to the dockerhub after the vote (in case > the permission can be set by the INFRA) > Note: based on LEGAL-270 and linked discussion both approaches (inline build > process / external build process) are compatible with the apache release. > Note: HDDS-851 and HADOOP-14898 contains more information about these > problems. -- 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
[jira] [Commented] (HDDS-1495) Create hadoop/ozone docker images with inline build process
[ https://issues.apache.org/jira/browse/HDDS-1495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16864502#comment-16864502 ] Anu Engineer commented on HDDS-1495: I did; Without this patch, I am able to do a build in 04:38 on my machine. With this patch, it takes 05:30 on the same machine. Looks like a 20% overhead to me, that is a very significant time consider that we are talking about the end-to-end build time. Here is the build command that I used. > mvn -f pom.ozone.xml clean package -DskipTests -Dmaven.javadoc.skip -Dskipshade > Create hadoop/ozone docker images with inline build process > --- > > Key: HDDS-1495 > URL: https://issues.apache.org/jira/browse/HDDS-1495 > Project: Hadoop Distributed Data Store > Issue Type: Sub-task >Reporter: Elek, Marton >Assignee: Eric Yang >Priority: Major > Attachments: HADOOP-16091.001.patch, HADOOP-16091.002.patch, > HDDS-1495.003.patch, HDDS-1495.004.patch, HDDS-1495.005.patch, > HDDS-1495.006.patch, HDDS-1495.007.patch, HDDS-1495.008.patch, Hadoop Docker > Image inline build process.pdf > > > This is proposed by [~eyang] in > [this|https://lists.apache.org/thread.html/33ac54bdeacb4beb023ebd452464603aaffa095bd104cb43c22f484e@%3Chdfs-dev.hadoop.apache.org%3E] > mailing thread. > {quote}1, 3. There are 38 Apache projects hosting docker images on Docker hub > using Apache Organization. By browsing Apache github mirror. There are only 7 > projects using a separate repository for docker image build. Popular projects > official images are not from Apache organization, such as zookeeper, tomcat, > httpd. We may not disrupt what other Apache projects are doing, but it looks > like inline build process is widely employed by majority of projects such as > Nifi, Brooklyn, thrift, karaf, syncope and others. The situation seems a bit > chaotic for Apache as a whole. However, Hadoop community can decide what is > best for Hadoop. My preference is to remove ozone from source tree naming, if > Ozone is intended to be subproject of Hadoop for long period of time. This > enables Hadoop community to host docker images for various subproject without > having to check out several source tree to trigger a grand build. However, > inline build process seems more popular than separated process. Hence, I > highly recommend making docker build inline if possible. > {quote} > The main challenges are also discussed in the thread: > {code:java} > 3. Technically it would be possible to add the Dockerfile to the source > tree and publish the docker image together with the release by the > release manager but it's also problematic: > {code} > a) there is no easy way to stage the images for the vote > c) it couldn't be flagged as automated on dockerhub > d) It couldn't support the critical updates. > * Updating existing images (for example in case of an ssl bug, rebuild > all the existing images with exactly the same payload but updated base > image/os environment) > * Creating image for older releases (We would like to provide images, > for hadoop 2.6/2.7/2.7/2.8/2.9. Especially for doing automatic testing > with different versions). > {code:java} > {code} > The a) can be solved (as [~eyang] suggested) with using a personal docker > image during the vote and publish it to the dockerhub after the vote (in case > the permission can be set by the INFRA) > Note: based on LEGAL-270 and linked discussion both approaches (inline build > process / external build process) are compatible with the apache release. > Note: HDDS-851 and HADOOP-14898 contains more information about these > problems. -- 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
[jira] [Commented] (HDDS-1495) Create hadoop/ozone docker images with inline build process
[ https://issues.apache.org/jira/browse/HDDS-1495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16864494#comment-16864494 ] Hadoop QA commented on HDDS-1495: - | (x) *{color:red}-1 overall{color}* | \\ \\ || Vote || Subsystem || Runtime || Comment || | {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 35s{color} | {color:blue} Docker mode activated. {color} | || || || || {color:brown} Prechecks {color} || | {color:green}+1{color} | {color:green} dupname {color} | {color:green} 0m 1s{color} | {color:green} No case conflicting files found. {color} | | {color:blue}0{color} | {color:blue} shelldocs {color} | {color:blue} 0m 0s{color} | {color:blue} Shelldocs was not available. {color} | | {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s{color} | {color:green} The patch does not contain any @author tags. {color} | | {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m 0s{color} | {color:red} The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch. {color} | || || || || {color:brown} trunk Compile Tests {color} || | {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 49s{color} | {color:blue} Maven dependency ordering for branch {color} | | {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 10m 1s{color} | {color:green} trunk passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 6m 5s{color} | {color:green} trunk passed {color} | | {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 0s{color} | {color:green} trunk passed {color} | | {color:green}+1{color} | {color:green} shadedclient {color} | {color:green} 15m 36s{color} | {color:green} branch has no errors when building and testing our client artifacts. {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 3m 36s{color} | {color:green} trunk passed {color} | || || || || {color:brown} Patch Compile Tests {color} || | {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 26s{color} | {color:blue} Maven dependency ordering for patch {color} | | {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 8m 51s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 6m 8s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} javac {color} | {color:green} 6m 8s{color} | {color:green} the patch passed {color} | | {color:red}-1{color} | {color:red} hadolint {color} | {color:red} 0m 2s{color} | {color:red} The patch generated 4 new + 0 unchanged - 0 fixed = 4 total (was 0) {color} | | {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 0s{color} | {color:green} the patch passed {color} | | {color:orange}-0{color} | {color:orange} pylint {color} | {color:orange} 0m 5s{color} | {color:orange} Error running pylint. Please check pylint stderr files. {color} | | {color:green}+1{color} | {color:green} pylint {color} | {color:green} 0m 5s{color} | {color:green} There were no new pylint issues. {color} | | {color:red}-1{color} | {color:red} shellcheck {color} | {color:red} 0m 0s{color} | {color:red} The patch generated 5 new + 0 unchanged - 0 fixed = 5 total (was 0) {color} | | {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m 0s{color} | {color:green} The patch has no whitespace issues. {color} | | {color:green}+1{color} | {color:green} xml {color} | {color:green} 0m 8s{color} | {color:green} The patch has no ill-formed XML file. {color} | | {color:green}+1{color} | {color:green} shadedclient {color} | {color:green} 13m 17s{color} | {color:green} patch has no errors when building and testing our client artifacts. {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 3m 45s{color} | {color:green} the patch passed {color} | || || || || {color:brown} Other Tests {color} || | {color:red}-1{color} | {color:red} unit {color} | {color:red} 3m 13s{color} | {color:red} hadoop-hdds in the patch failed. {color} | | {color:red}-1{color} | {color:red} unit {color} | {color:red} 22m 10s{color} | {color:red} hadoop-ozone in the patch failed. {color} | | {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 1m 25s{color} | {color:green} The patch does not generate ASF License warnings. {color} | | {color:black}{color} | {color:black} {color} | {color:black} 99m 20s{color} | {color:black} {color} | \\ \\ || Reason || Tests || | Failed junit tests | hadoop.ozone.container.common.impl.TestHddsDispatcher | | | hadoop.ozone.client.rpc.TestOzoneAtRestEncryption | | | hadoop.ozone.client.
[jira] [Commented] (HDDS-1495) Create hadoop/ozone docker images with inline build process
[ https://issues.apache.org/jira/browse/HDDS-1495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16864461#comment-16864461 ] Eric Yang commented on HDDS-1495: - [~anu] patch 8 is rebased to current trunk. 400mb saving were from excluding byteman, robot framework, dumb-init and async-profiler. Developer tools were the reason to make the image more bloated. Patch 8 added back those dependencies and keep the image as close to original as possible. Therefore, space saving doesn't exist. The speed of rebuilding is very close, current method takes about 14-35 seconds. Where, docker module build time is 19-21 seconds. The only improvements using this approach are: # It would be possible for someone to re-roll a image based on released tarball # Faster rebuild time by separating binary download from configuration steps. if there is more shell script commands to add to setup-image.sh # Reduced number of layers to download. Let me know if you want to give it a try. > Create hadoop/ozone docker images with inline build process > --- > > Key: HDDS-1495 > URL: https://issues.apache.org/jira/browse/HDDS-1495 > Project: Hadoop Distributed Data Store > Issue Type: Sub-task >Reporter: Elek, Marton >Assignee: Eric Yang >Priority: Major > Attachments: HADOOP-16091.001.patch, HADOOP-16091.002.patch, > HDDS-1495.003.patch, HDDS-1495.004.patch, HDDS-1495.005.patch, > HDDS-1495.006.patch, HDDS-1495.007.patch, HDDS-1495.008.patch, Hadoop Docker > Image inline build process.pdf > > > This is proposed by [~eyang] in > [this|https://lists.apache.org/thread.html/33ac54bdeacb4beb023ebd452464603aaffa095bd104cb43c22f484e@%3Chdfs-dev.hadoop.apache.org%3E] > mailing thread. > {quote}1, 3. There are 38 Apache projects hosting docker images on Docker hub > using Apache Organization. By browsing Apache github mirror. There are only 7 > projects using a separate repository for docker image build. Popular projects > official images are not from Apache organization, such as zookeeper, tomcat, > httpd. We may not disrupt what other Apache projects are doing, but it looks > like inline build process is widely employed by majority of projects such as > Nifi, Brooklyn, thrift, karaf, syncope and others. The situation seems a bit > chaotic for Apache as a whole. However, Hadoop community can decide what is > best for Hadoop. My preference is to remove ozone from source tree naming, if > Ozone is intended to be subproject of Hadoop for long period of time. This > enables Hadoop community to host docker images for various subproject without > having to check out several source tree to trigger a grand build. However, > inline build process seems more popular than separated process. Hence, I > highly recommend making docker build inline if possible. > {quote} > The main challenges are also discussed in the thread: > {code:java} > 3. Technically it would be possible to add the Dockerfile to the source > tree and publish the docker image together with the release by the > release manager but it's also problematic: > {code} > a) there is no easy way to stage the images for the vote > c) it couldn't be flagged as automated on dockerhub > d) It couldn't support the critical updates. > * Updating existing images (for example in case of an ssl bug, rebuild > all the existing images with exactly the same payload but updated base > image/os environment) > * Creating image for older releases (We would like to provide images, > for hadoop 2.6/2.7/2.7/2.8/2.9. Especially for doing automatic testing > with different versions). > {code:java} > {code} > The a) can be solved (as [~eyang] suggested) with using a personal docker > image during the vote and publish it to the dockerhub after the vote (in case > the permission can be set by the INFRA) > Note: based on LEGAL-270 and linked discussion both approaches (inline build > process / external build process) are compatible with the apache release. > Note: HDDS-851 and HADOOP-14898 contains more information about these > problems. -- 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
[jira] [Commented] (HDDS-1495) Create hadoop/ozone docker images with inline build process
[ https://issues.apache.org/jira/browse/HDDS-1495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16863625#comment-16863625 ] Anu Engineer commented on HDDS-1495: I am not able to reproduce any of these numbers since the patch does not apply to the trunk. So, sorry I cannot test and verify hence not able to lift my -1; > Create hadoop/ozone docker images with inline build process > --- > > Key: HDDS-1495 > URL: https://issues.apache.org/jira/browse/HDDS-1495 > Project: Hadoop Distributed Data Store > Issue Type: Sub-task >Reporter: Elek, Marton >Assignee: Eric Yang >Priority: Major > Attachments: HADOOP-16091.001.patch, HADOOP-16091.002.patch, > HDDS-1495.003.patch, HDDS-1495.004.patch, HDDS-1495.005.patch, > HDDS-1495.006.patch, HDDS-1495.007.patch, Hadoop Docker Image inline build > process.pdf > > > This is proposed by [~eyang] in > [this|https://lists.apache.org/thread.html/33ac54bdeacb4beb023ebd452464603aaffa095bd104cb43c22f484e@%3Chdfs-dev.hadoop.apache.org%3E] > mailing thread. > {quote}1, 3. There are 38 Apache projects hosting docker images on Docker hub > using Apache Organization. By browsing Apache github mirror. There are only 7 > projects using a separate repository for docker image build. Popular projects > official images are not from Apache organization, such as zookeeper, tomcat, > httpd. We may not disrupt what other Apache projects are doing, but it looks > like inline build process is widely employed by majority of projects such as > Nifi, Brooklyn, thrift, karaf, syncope and others. The situation seems a bit > chaotic for Apache as a whole. However, Hadoop community can decide what is > best for Hadoop. My preference is to remove ozone from source tree naming, if > Ozone is intended to be subproject of Hadoop for long period of time. This > enables Hadoop community to host docker images for various subproject without > having to check out several source tree to trigger a grand build. However, > inline build process seems more popular than separated process. Hence, I > highly recommend making docker build inline if possible. > {quote} > The main challenges are also discussed in the thread: > {code:java} > 3. Technically it would be possible to add the Dockerfile to the source > tree and publish the docker image together with the release by the > release manager but it's also problematic: > {code} > a) there is no easy way to stage the images for the vote > c) it couldn't be flagged as automated on dockerhub > d) It couldn't support the critical updates. > * Updating existing images (for example in case of an ssl bug, rebuild > all the existing images with exactly the same payload but updated base > image/os environment) > * Creating image for older releases (We would like to provide images, > for hadoop 2.6/2.7/2.7/2.8/2.9. Especially for doing automatic testing > with different versions). > {code:java} > {code} > The a) can be solved (as [~eyang] suggested) with using a personal docker > image during the vote and publish it to the dockerhub after the vote (in case > the permission can be set by the INFRA) > Note: based on LEGAL-270 and linked discussion both approaches (inline build > process / external build process) are compatible with the apache release. > Note: HDDS-851 and HADOOP-14898 contains more information about these > problems. -- 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
[jira] [Commented] (HDDS-1495) Create hadoop/ozone docker images with inline build process
[ https://issues.apache.org/jira/browse/HDDS-1495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16863495#comment-16863495 ] Eric Yang commented on HDDS-1495: - {quote}For the records: it's possible since HDDS-1629{quote} Sort of, the short cut is hackish. There is a constant time added to build up the ozone directory structure for each build. The process isn't free. If the content of ozone-${project.version} doesn't need to change, why spend the 35 seconds? Here is time spend for monolithic dist project building docker image (without tarball): {code} [INFO] --- docker-maven-plugin:0.29.0:build (default) @ hadoop-ozone-dist --- [INFO] Building tar: /home/eyang/hadoop/hadoop-ozone/dist/target/docker/eyang/ozone/0.5.0-SNAPSHOT/tmp/docker-build.tar [INFO] DOCKER> [eyang/ozone:0.5.0-SNAPSHOT]: Created docker-build.tar in 1 second [INFO] DOCKER> [eyang/ozone:0.5.0-SNAPSHOT]: Built image sha256:0196e [INFO] DOCKER> [eyang/ozone:0.5.0-SNAPSHOT]: Removed old image sha256:a20fa [INFO] [INFO] BUILD SUCCESS [INFO] [INFO] Total time: 35.808 s [INFO] Finished at: 2019-06-13T17:12:11-04:00 [INFO] Final Memory: 44M/748M [INFO] {code} Here is time for docker with dependency cache: [INFO] Detected build of image with id 7b3ff8fff705 [INFO] Successfully built apache/ozone:0.5.0-SNAPSHOT [INFO] [INFO] BUILD SUCCESS [INFO] [INFO] Total time: 20.298 s [INFO] Finished at: 2019-06-13T17:30:53-04:00 [INFO] Final Memory: 32M/446M [INFO] It is 43% time saving in my environment. Dependency copy time is constant time and cacheable. Where rebuild the entire ozone directory structure time changes depends on how complex the procedure becoming in the future. {code} REPOSITORY TAG IMAGE IDCREATED SIZE apache/ozone 0.5.0-SNAPSHOT7b3ff8fff70514 minutes ago 707MB eyang/ozone0.5.0-SNAPSHOT0196eb46a57431 minutes ago 1.28GB {code} The image generated by both process is also significantly different. Apache/ozone image was generated using docker submodule. The eyang/ozone image was generated by monolithic build. The test is done without doing any Dockerfile optimization. There is still plenty space optimization and time reduction when Docker layers are further optimized. The monolithic build process will only get more complicated if more stuff are dump into dist project. Please consider the request to make the build environment more workable for docker developers. > Create hadoop/ozone docker images with inline build process > --- > > Key: HDDS-1495 > URL: https://issues.apache.org/jira/browse/HDDS-1495 > Project: Hadoop Distributed Data Store > Issue Type: Sub-task >Reporter: Elek, Marton >Assignee: Eric Yang >Priority: Major > Attachments: HADOOP-16091.001.patch, HADOOP-16091.002.patch, > HDDS-1495.003.patch, HDDS-1495.004.patch, HDDS-1495.005.patch, > HDDS-1495.006.patch, HDDS-1495.007.patch, Hadoop Docker Image inline build > process.pdf > > > This is proposed by [~eyang] in > [this|https://lists.apache.org/thread.html/33ac54bdeacb4beb023ebd452464603aaffa095bd104cb43c22f484e@%3Chdfs-dev.hadoop.apache.org%3E] > mailing thread. > {quote}1, 3. There are 38 Apache projects hosting docker images on Docker hub > using Apache Organization. By browsing Apache github mirror. There are only 7 > projects using a separate repository for docker image build. Popular projects > official images are not from Apache organization, such as zookeeper, tomcat, > httpd. We may not disrupt what other Apache projects are doing, but it looks > like inline build process is widely employed by majority of projects such as > Nifi, Brooklyn, thrift, karaf, syncope and others. The situation seems a bit > chaotic for Apache as a whole. However, Hadoop community can decide what is > best for Hadoop. My preference is to remove ozone from source tree naming, if > Ozone is intended to be subproject of Hadoop for long period of time. This > enables Hadoop community to host docker images for various subproject without > having to check out several source tree to trigger a grand build. However, > inline build process seems more popular than separated process. Hence, I > highly recommend making docker build inline if possible. > {quote} > The main
[jira] [Commented] (HDDS-1495) Create hadoop/ozone docker images with inline build process
[ https://issues.apache.org/jira/browse/HDDS-1495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16862830#comment-16862830 ] Elek, Marton commented on HDDS-1495: bq. It is not possible to build docker only without building tarball in current implementation. For the records: it's possible since HDDS-1629 bq. Docker build is only slow, if Dockerfile is not optimized for efficiency Not exactly. Independently from the optimization, mvn install + maven-dependency-plugin would copy the cc. 4-500 MB artifact (IMHO at least twice for each build). bq. I very much prefer [...] avoid the monolithic build process I understand, but from my point of view, there is a technical issue (significant IO + support the upgrade of base OS of the container) with the proposed change. I respect your opinion/preference, but I prefer to collect the technical issues and solve them. And I can't see any big problem with the "monolithic" build process. > Create hadoop/ozone docker images with inline build process > --- > > Key: HDDS-1495 > URL: https://issues.apache.org/jira/browse/HDDS-1495 > Project: Hadoop Distributed Data Store > Issue Type: Sub-task >Reporter: Elek, Marton >Assignee: Eric Yang >Priority: Major > Attachments: HADOOP-16091.001.patch, HADOOP-16091.002.patch, > HDDS-1495.003.patch, HDDS-1495.004.patch, HDDS-1495.005.patch, > HDDS-1495.006.patch, HDDS-1495.007.patch, Hadoop Docker Image inline build > process.pdf > > > This is proposed by [~eyang] in > [this|https://lists.apache.org/thread.html/33ac54bdeacb4beb023ebd452464603aaffa095bd104cb43c22f484e@%3Chdfs-dev.hadoop.apache.org%3E] > mailing thread. > {quote}1, 3. There are 38 Apache projects hosting docker images on Docker hub > using Apache Organization. By browsing Apache github mirror. There are only 7 > projects using a separate repository for docker image build. Popular projects > official images are not from Apache organization, such as zookeeper, tomcat, > httpd. We may not disrupt what other Apache projects are doing, but it looks > like inline build process is widely employed by majority of projects such as > Nifi, Brooklyn, thrift, karaf, syncope and others. The situation seems a bit > chaotic for Apache as a whole. However, Hadoop community can decide what is > best for Hadoop. My preference is to remove ozone from source tree naming, if > Ozone is intended to be subproject of Hadoop for long period of time. This > enables Hadoop community to host docker images for various subproject without > having to check out several source tree to trigger a grand build. However, > inline build process seems more popular than separated process. Hence, I > highly recommend making docker build inline if possible. > {quote} > The main challenges are also discussed in the thread: > {code:java} > 3. Technically it would be possible to add the Dockerfile to the source > tree and publish the docker image together with the release by the > release manager but it's also problematic: > {code} > a) there is no easy way to stage the images for the vote > c) it couldn't be flagged as automated on dockerhub > d) It couldn't support the critical updates. > * Updating existing images (for example in case of an ssl bug, rebuild > all the existing images with exactly the same payload but updated base > image/os environment) > * Creating image for older releases (We would like to provide images, > for hadoop 2.6/2.7/2.7/2.8/2.9. Especially for doing automatic testing > with different versions). > {code:java} > {code} > The a) can be solved (as [~eyang] suggested) with using a personal docker > image during the vote and publish it to the dockerhub after the vote (in case > the permission can be set by the INFRA) > Note: based on LEGAL-270 and linked discussion both approaches (inline build > process / external build process) are compatible with the apache release. > Note: HDDS-851 and HADOOP-14898 contains more information about these > problems. -- 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
[jira] [Commented] (HDDS-1495) Create hadoop/ozone docker images with inline build process
[ https://issues.apache.org/jira/browse/HDDS-1495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16862536#comment-16862536 ] Eric Yang commented on HDDS-1495: - {quote}Actually, I am -1; on this change. Inline builds are slower creates more dependencies etc. Thanks for the great discussion and exploring this thought.{quote} [~anu] This statement is not true. Dist project is a monolithic project that builds, variety of artifacts. It is not possible to build docker only without building tarball in current implementation. If docker part is refactored into another submodule, then it would be possible to iterate docker portion of the build without incurring the cost of building jars and tarball. Docker build is only slow, if Dockerfile is not optimized for efficiency. HDDS-1648 offers solution to improve Dockerfile build performance and reduce current disk space usage by 25%. Ozone tarball can also be obtained from dist/target directory without using maven-dependency-plugin to avoid additional copy. Although it is possible to reach out to sibling project to find binary, I very much prefer to use maven dependency:copy to keep each sub module independent of each other to avoid the monolithic build process. Your reconsideration is appreciated. > Create hadoop/ozone docker images with inline build process > --- > > Key: HDDS-1495 > URL: https://issues.apache.org/jira/browse/HDDS-1495 > Project: Hadoop Distributed Data Store > Issue Type: Sub-task >Reporter: Elek, Marton >Assignee: Eric Yang >Priority: Major > Attachments: HADOOP-16091.001.patch, HADOOP-16091.002.patch, > HDDS-1495.003.patch, HDDS-1495.004.patch, HDDS-1495.005.patch, > HDDS-1495.006.patch, HDDS-1495.007.patch, Hadoop Docker Image inline build > process.pdf > > > This is proposed by [~eyang] in > [this|https://lists.apache.org/thread.html/33ac54bdeacb4beb023ebd452464603aaffa095bd104cb43c22f484e@%3Chdfs-dev.hadoop.apache.org%3E] > mailing thread. > {quote}1, 3. There are 38 Apache projects hosting docker images on Docker hub > using Apache Organization. By browsing Apache github mirror. There are only 7 > projects using a separate repository for docker image build. Popular projects > official images are not from Apache organization, such as zookeeper, tomcat, > httpd. We may not disrupt what other Apache projects are doing, but it looks > like inline build process is widely employed by majority of projects such as > Nifi, Brooklyn, thrift, karaf, syncope and others. The situation seems a bit > chaotic for Apache as a whole. However, Hadoop community can decide what is > best for Hadoop. My preference is to remove ozone from source tree naming, if > Ozone is intended to be subproject of Hadoop for long period of time. This > enables Hadoop community to host docker images for various subproject without > having to check out several source tree to trigger a grand build. However, > inline build process seems more popular than separated process. Hence, I > highly recommend making docker build inline if possible. > {quote} > The main challenges are also discussed in the thread: > {code:java} > 3. Technically it would be possible to add the Dockerfile to the source > tree and publish the docker image together with the release by the > release manager but it's also problematic: > {code} > a) there is no easy way to stage the images for the vote > c) it couldn't be flagged as automated on dockerhub > d) It couldn't support the critical updates. > * Updating existing images (for example in case of an ssl bug, rebuild > all the existing images with exactly the same payload but updated base > image/os environment) > * Creating image for older releases (We would like to provide images, > for hadoop 2.6/2.7/2.7/2.8/2.9. Especially for doing automatic testing > with different versions). > {code:java} > {code} > The a) can be solved (as [~eyang] suggested) with using a personal docker > image during the vote and publish it to the dockerhub after the vote (in case > the permission can be set by the INFRA) > Note: based on LEGAL-270 and linked discussion both approaches (inline build > process / external build process) are compatible with the apache release. > Note: HDDS-851 and HADOOP-14898 contains more information about these > problems. -- 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
[jira] [Commented] (HDDS-1495) Create hadoop/ozone docker images with inline build process
[ https://issues.apache.org/jira/browse/HDDS-1495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16861494#comment-16861494 ] Anu Engineer commented on HDDS-1495: Actually, I am -1; on this change. Inline builds are slower creates more dependencies etc. Thanks for the great discussion and exploring this thought. > Create hadoop/ozone docker images with inline build process > --- > > Key: HDDS-1495 > URL: https://issues.apache.org/jira/browse/HDDS-1495 > Project: Hadoop Distributed Data Store > Issue Type: Sub-task >Reporter: Elek, Marton >Assignee: Eric Yang >Priority: Major > Attachments: HADOOP-16091.001.patch, HADOOP-16091.002.patch, > HDDS-1495.003.patch, HDDS-1495.004.patch, HDDS-1495.005.patch, > HDDS-1495.006.patch, HDDS-1495.007.patch, Hadoop Docker Image inline build > process.pdf > > > This is proposed by [~eyang] in > [this|https://lists.apache.org/thread.html/33ac54bdeacb4beb023ebd452464603aaffa095bd104cb43c22f484e@%3Chdfs-dev.hadoop.apache.org%3E] > mailing thread. > {quote}1, 3. There are 38 Apache projects hosting docker images on Docker hub > using Apache Organization. By browsing Apache github mirror. There are only 7 > projects using a separate repository for docker image build. Popular projects > official images are not from Apache organization, such as zookeeper, tomcat, > httpd. We may not disrupt what other Apache projects are doing, but it looks > like inline build process is widely employed by majority of projects such as > Nifi, Brooklyn, thrift, karaf, syncope and others. The situation seems a bit > chaotic for Apache as a whole. However, Hadoop community can decide what is > best for Hadoop. My preference is to remove ozone from source tree naming, if > Ozone is intended to be subproject of Hadoop for long period of time. This > enables Hadoop community to host docker images for various subproject without > having to check out several source tree to trigger a grand build. However, > inline build process seems more popular than separated process. Hence, I > highly recommend making docker build inline if possible. > {quote} > The main challenges are also discussed in the thread: > {code:java} > 3. Technically it would be possible to add the Dockerfile to the source > tree and publish the docker image together with the release by the > release manager but it's also problematic: > {code} > a) there is no easy way to stage the images for the vote > c) it couldn't be flagged as automated on dockerhub > d) It couldn't support the critical updates. > * Updating existing images (for example in case of an ssl bug, rebuild > all the existing images with exactly the same payload but updated base > image/os environment) > * Creating image for older releases (We would like to provide images, > for hadoop 2.6/2.7/2.7/2.8/2.9. Especially for doing automatic testing > with different versions). > {code:java} > {code} > The a) can be solved (as [~eyang] suggested) with using a personal docker > image during the vote and publish it to the dockerhub after the vote (in case > the permission can be set by the INFRA) > Note: based on LEGAL-270 and linked discussion both approaches (inline build > process / external build process) are compatible with the apache release. > Note: HDDS-851 and HADOOP-14898 contains more information about these > problems. -- 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
[jira] [Commented] (HDDS-1495) Create hadoop/ozone docker images with inline build process
[ https://issues.apache.org/jira/browse/HDDS-1495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16861279#comment-16861279 ] Anu Engineer commented on HDDS-1495: Nope, I disagree. Inline builds add an extra step which adds no value. Dist project is very clean and easy to understand. I have no idea why you are struggling to work it it. Docker images are not part of K8s. They are part of docker hub in the default case, and if you really need to build them we are saying here are some samples for you to modify. we are not in the business of making official builds of docker images and supporting it as an inline build. > Create hadoop/ozone docker images with inline build process > --- > > Key: HDDS-1495 > URL: https://issues.apache.org/jira/browse/HDDS-1495 > Project: Hadoop Distributed Data Store > Issue Type: Sub-task >Reporter: Elek, Marton >Assignee: Eric Yang >Priority: Major > Attachments: HADOOP-16091.001.patch, HADOOP-16091.002.patch, > HDDS-1495.003.patch, HDDS-1495.004.patch, HDDS-1495.005.patch, > HDDS-1495.006.patch, HDDS-1495.007.patch, Hadoop Docker Image inline build > process.pdf > > > This is proposed by [~eyang] in > [this|https://lists.apache.org/thread.html/33ac54bdeacb4beb023ebd452464603aaffa095bd104cb43c22f484e@%3Chdfs-dev.hadoop.apache.org%3E] > mailing thread. > {quote}1, 3. There are 38 Apache projects hosting docker images on Docker hub > using Apache Organization. By browsing Apache github mirror. There are only 7 > projects using a separate repository for docker image build. Popular projects > official images are not from Apache organization, such as zookeeper, tomcat, > httpd. We may not disrupt what other Apache projects are doing, but it looks > like inline build process is widely employed by majority of projects such as > Nifi, Brooklyn, thrift, karaf, syncope and others. The situation seems a bit > chaotic for Apache as a whole. However, Hadoop community can decide what is > best for Hadoop. My preference is to remove ozone from source tree naming, if > Ozone is intended to be subproject of Hadoop for long period of time. This > enables Hadoop community to host docker images for various subproject without > having to check out several source tree to trigger a grand build. However, > inline build process seems more popular than separated process. Hence, I > highly recommend making docker build inline if possible. > {quote} > The main challenges are also discussed in the thread: > {code:java} > 3. Technically it would be possible to add the Dockerfile to the source > tree and publish the docker image together with the release by the > release manager but it's also problematic: > {code} > a) there is no easy way to stage the images for the vote > c) it couldn't be flagged as automated on dockerhub > d) It couldn't support the critical updates. > * Updating existing images (for example in case of an ssl bug, rebuild > all the existing images with exactly the same payload but updated base > image/os environment) > * Creating image for older releases (We would like to provide images, > for hadoop 2.6/2.7/2.7/2.8/2.9. Especially for doing automatic testing > with different versions). > {code:java} > {code} > The a) can be solved (as [~eyang] suggested) with using a personal docker > image during the vote and publish it to the dockerhub after the vote (in case > the permission can be set by the INFRA) > Note: based on LEGAL-270 and linked discussion both approaches (inline build > process / external build process) are compatible with the apache release. > Note: HDDS-851 and HADOOP-14898 contains more information about these > problems. -- 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
[jira] [Commented] (HDDS-1495) Create hadoop/ozone docker images with inline build process
[ https://issues.apache.org/jira/browse/HDDS-1495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16845026#comment-16845026 ] Eric Yang commented on HDDS-1495: - [~anu] I spent some time looking at k8s-dev profile in dist module. Dist project is overloaded in generating too many artifacts that will prevent the maven release process to run correctly. Docker and k8s are complementary system. I think it is best to build docker image, then having a separate module that generate k8s specific metadata instead of lumping everything in dist project. This will improve usability of Ozone docker image to work independently from k8s and improve conversation on area to improve upon without every conversation turn into blabber on about dist module. I opened HDDS-1567 to separate docker image from k8s development. HDDS-1567 to define the interfacing environment variables that k8s, docker swarm and YARN service can integrate with. > Create hadoop/ozone docker images with inline build process > --- > > Key: HDDS-1495 > URL: https://issues.apache.org/jira/browse/HDDS-1495 > Project: Hadoop Distributed Data Store > Issue Type: Sub-task >Reporter: Elek, Marton >Assignee: Eric Yang >Priority: Major > Attachments: HADOOP-16091.001.patch, HADOOP-16091.002.patch, > HDDS-1495.003.patch, HDDS-1495.004.patch, HDDS-1495.005.patch, > HDDS-1495.006.patch, HDDS-1495.007.patch, Hadoop Docker Image inline build > process.pdf > > > This is proposed by [~eyang] in > [this|https://lists.apache.org/thread.html/33ac54bdeacb4beb023ebd452464603aaffa095bd104cb43c22f484e@%3Chdfs-dev.hadoop.apache.org%3E] > mailing thread. > {quote}1, 3. There are 38 Apache projects hosting docker images on Docker hub > using Apache Organization. By browsing Apache github mirror. There are only 7 > projects using a separate repository for docker image build. Popular projects > official images are not from Apache organization, such as zookeeper, tomcat, > httpd. We may not disrupt what other Apache projects are doing, but it looks > like inline build process is widely employed by majority of projects such as > Nifi, Brooklyn, thrift, karaf, syncope and others. The situation seems a bit > chaotic for Apache as a whole. However, Hadoop community can decide what is > best for Hadoop. My preference is to remove ozone from source tree naming, if > Ozone is intended to be subproject of Hadoop for long period of time. This > enables Hadoop community to host docker images for various subproject without > having to check out several source tree to trigger a grand build. However, > inline build process seems more popular than separated process. Hence, I > highly recommend making docker build inline if possible. > {quote} > The main challenges are also discussed in the thread: > {code:java} > 3. Technically it would be possible to add the Dockerfile to the source > tree and publish the docker image together with the release by the > release manager but it's also problematic: > {code} > a) there is no easy way to stage the images for the vote > c) it couldn't be flagged as automated on dockerhub > d) It couldn't support the critical updates. > * Updating existing images (for example in case of an ssl bug, rebuild > all the existing images with exactly the same payload but updated base > image/os environment) > * Creating image for older releases (We would like to provide images, > for hadoop 2.6/2.7/2.7/2.8/2.9. Especially for doing automatic testing > with different versions). > {code:java} > {code} > The a) can be solved (as [~eyang] suggested) with using a personal docker > image during the vote and publish it to the dockerhub after the vote (in case > the permission can be set by the INFRA) > Note: based on LEGAL-270 and linked discussion both approaches (inline build > process / external build process) are compatible with the apache release. > Note: HDDS-851 and HADOOP-14898 contains more information about these > problems. -- 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
[jira] [Commented] (HDDS-1495) Create hadoop/ozone docker images with inline build process
[ https://issues.apache.org/jira/browse/HDDS-1495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16841766#comment-16841766 ] Anu Engineer commented on HDDS-1495: bq. Release manager can build docker image and upload to docker hub from the same source code with synchronized versioning. Elek, Marton Anu Engineer Do you agree that this is practical solution to resolve the source code repository fragmentation issue? Nope, does not work. Release managers change all the time and Apache Infra manager the Apache Account in the DockerHub. So we cannot push anything into docker hub. We built the current hadoop-runner approach based on what Apache Infra told us. They have GitHub hooks to rebuild and update dockerhub images, also Binary releases are just convenience artifacts and having them in DockerHub allows us to run Ozone for testing easily. If you really want to use docker to run Ozone, you can use the k8s support that is being worked on. > Create hadoop/ozone docker images with inline build process > --- > > Key: HDDS-1495 > URL: https://issues.apache.org/jira/browse/HDDS-1495 > Project: Hadoop Distributed Data Store > Issue Type: Sub-task >Reporter: Elek, Marton >Assignee: Eric Yang >Priority: Major > Attachments: HADOOP-16091.001.patch, HADOOP-16091.002.patch, > HDDS-1495.003.patch, HDDS-1495.004.patch, HDDS-1495.005.patch, > HDDS-1495.006.patch, HDDS-1495.007.patch, Hadoop Docker Image inline build > process.pdf > > > This is proposed by [~eyang] in > [this|https://lists.apache.org/thread.html/33ac54bdeacb4beb023ebd452464603aaffa095bd104cb43c22f484e@%3Chdfs-dev.hadoop.apache.org%3E] > mailing thread. > {quote}1, 3. There are 38 Apache projects hosting docker images on Docker hub > using Apache Organization. By browsing Apache github mirror. There are only 7 > projects using a separate repository for docker image build. Popular projects > official images are not from Apache organization, such as zookeeper, tomcat, > httpd. We may not disrupt what other Apache projects are doing, but it looks > like inline build process is widely employed by majority of projects such as > Nifi, Brooklyn, thrift, karaf, syncope and others. The situation seems a bit > chaotic for Apache as a whole. However, Hadoop community can decide what is > best for Hadoop. My preference is to remove ozone from source tree naming, if > Ozone is intended to be subproject of Hadoop for long period of time. This > enables Hadoop community to host docker images for various subproject without > having to check out several source tree to trigger a grand build. However, > inline build process seems more popular than separated process. Hence, I > highly recommend making docker build inline if possible. > {quote} > The main challenges are also discussed in the thread: > {code:java} > 3. Technically it would be possible to add the Dockerfile to the source > tree and publish the docker image together with the release by the > release manager but it's also problematic: > {code} > a) there is no easy way to stage the images for the vote > c) it couldn't be flagged as automated on dockerhub > d) It couldn't support the critical updates. > * Updating existing images (for example in case of an ssl bug, rebuild > all the existing images with exactly the same payload but updated base > image/os environment) > * Creating image for older releases (We would like to provide images, > for hadoop 2.6/2.7/2.7/2.8/2.9. Especially for doing automatic testing > with different versions). > {code:java} > {code} > The a) can be solved (as [~eyang] suggested) with using a personal docker > image during the vote and publish it to the dockerhub after the vote (in case > the permission can be set by the INFRA) > Note: based on LEGAL-270 and linked discussion both approaches (inline build > process / external build process) are compatible with the apache release. > Note: HDDS-851 and HADOOP-14898 contains more information about these > problems. -- 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
[jira] [Commented] (HDDS-1495) Create hadoop/ozone docker images with inline build process
[ https://issues.apache.org/jira/browse/HDDS-1495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16841733#comment-16841733 ] Elek, Marton commented on HDDS-1495: Thanks [~ccondit] the ideas. Ozone can be run as a plugin or as standalone. Usually we test is as standalone but we definitely need some way to test it together with older hadoop version. (For example to be sure that ozonefs works well with older hadoop version, and spark and hive versions, or -- as you wrote -- test the plugin approach) I didn't think about your idea until now but it could work. It may require many different containers (like a matrix build: ozone (0.3.0,.0.4.0) + hadoop (2.7.3,2.7.0,2.8.0) which can be solved in different way (for example with many different patches or with some kind of matrix builds) > Create hadoop/ozone docker images with inline build process > --- > > Key: HDDS-1495 > URL: https://issues.apache.org/jira/browse/HDDS-1495 > Project: Hadoop Distributed Data Store > Issue Type: Sub-task >Reporter: Elek, Marton >Assignee: Eric Yang >Priority: Major > Attachments: HADOOP-16091.001.patch, HADOOP-16091.002.patch, > HDDS-1495.003.patch, HDDS-1495.004.patch, HDDS-1495.005.patch, > HDDS-1495.006.patch, HDDS-1495.007.patch, Hadoop Docker Image inline build > process.pdf > > > This is proposed by [~eyang] in > [this|https://lists.apache.org/thread.html/33ac54bdeacb4beb023ebd452464603aaffa095bd104cb43c22f484e@%3Chdfs-dev.hadoop.apache.org%3E] > mailing thread. > {quote}1, 3. There are 38 Apache projects hosting docker images on Docker hub > using Apache Organization. By browsing Apache github mirror. There are only 7 > projects using a separate repository for docker image build. Popular projects > official images are not from Apache organization, such as zookeeper, tomcat, > httpd. We may not disrupt what other Apache projects are doing, but it looks > like inline build process is widely employed by majority of projects such as > Nifi, Brooklyn, thrift, karaf, syncope and others. The situation seems a bit > chaotic for Apache as a whole. However, Hadoop community can decide what is > best for Hadoop. My preference is to remove ozone from source tree naming, if > Ozone is intended to be subproject of Hadoop for long period of time. This > enables Hadoop community to host docker images for various subproject without > having to check out several source tree to trigger a grand build. However, > inline build process seems more popular than separated process. Hence, I > highly recommend making docker build inline if possible. > {quote} > The main challenges are also discussed in the thread: > {code:java} > 3. Technically it would be possible to add the Dockerfile to the source > tree and publish the docker image together with the release by the > release manager but it's also problematic: > {code} > a) there is no easy way to stage the images for the vote > c) it couldn't be flagged as automated on dockerhub > d) It couldn't support the critical updates. > * Updating existing images (for example in case of an ssl bug, rebuild > all the existing images with exactly the same payload but updated base > image/os environment) > * Creating image for older releases (We would like to provide images, > for hadoop 2.6/2.7/2.7/2.8/2.9. Especially for doing automatic testing > with different versions). > {code:java} > {code} > The a) can be solved (as [~eyang] suggested) with using a personal docker > image during the vote and publish it to the dockerhub after the vote (in case > the permission can be set by the INFRA) > Note: based on LEGAL-270 and linked discussion both approaches (inline build > process / external build process) are compatible with the apache release. > Note: HDDS-851 and HADOOP-14898 contains more information about these > problems. -- 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
[jira] [Commented] (HDDS-1495) Create hadoop/ozone docker images with inline build process
[ https://issues.apache.org/jira/browse/HDDS-1495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16841728#comment-16841728 ] Elek, Marton commented on HDDS-1495: Sorry, I don't believe that "source code repository fragmentation" is a problem. I think it worked well until now. > Create hadoop/ozone docker images with inline build process > --- > > Key: HDDS-1495 > URL: https://issues.apache.org/jira/browse/HDDS-1495 > Project: Hadoop Distributed Data Store > Issue Type: Sub-task >Reporter: Elek, Marton >Assignee: Eric Yang >Priority: Major > Attachments: HADOOP-16091.001.patch, HADOOP-16091.002.patch, > HDDS-1495.003.patch, HDDS-1495.004.patch, HDDS-1495.005.patch, > HDDS-1495.006.patch, HDDS-1495.007.patch, Hadoop Docker Image inline build > process.pdf > > > This is proposed by [~eyang] in > [this|https://lists.apache.org/thread.html/33ac54bdeacb4beb023ebd452464603aaffa095bd104cb43c22f484e@%3Chdfs-dev.hadoop.apache.org%3E] > mailing thread. > {quote}1, 3. There are 38 Apache projects hosting docker images on Docker hub > using Apache Organization. By browsing Apache github mirror. There are only 7 > projects using a separate repository for docker image build. Popular projects > official images are not from Apache organization, such as zookeeper, tomcat, > httpd. We may not disrupt what other Apache projects are doing, but it looks > like inline build process is widely employed by majority of projects such as > Nifi, Brooklyn, thrift, karaf, syncope and others. The situation seems a bit > chaotic for Apache as a whole. However, Hadoop community can decide what is > best for Hadoop. My preference is to remove ozone from source tree naming, if > Ozone is intended to be subproject of Hadoop for long period of time. This > enables Hadoop community to host docker images for various subproject without > having to check out several source tree to trigger a grand build. However, > inline build process seems more popular than separated process. Hence, I > highly recommend making docker build inline if possible. > {quote} > The main challenges are also discussed in the thread: > {code:java} > 3. Technically it would be possible to add the Dockerfile to the source > tree and publish the docker image together with the release by the > release manager but it's also problematic: > {code} > a) there is no easy way to stage the images for the vote > c) it couldn't be flagged as automated on dockerhub > d) It couldn't support the critical updates. > * Updating existing images (for example in case of an ssl bug, rebuild > all the existing images with exactly the same payload but updated base > image/os environment) > * Creating image for older releases (We would like to provide images, > for hadoop 2.6/2.7/2.7/2.8/2.9. Especially for doing automatic testing > with different versions). > {code:java} > {code} > The a) can be solved (as [~eyang] suggested) with using a personal docker > image during the vote and publish it to the dockerhub after the vote (in case > the permission can be set by the INFRA) > Note: based on LEGAL-270 and linked discussion both approaches (inline build > process / external build process) are compatible with the apache release. > Note: HDDS-851 and HADOOP-14898 contains more information about these > problems. -- 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
[jira] [Commented] (HDDS-1495) Create hadoop/ozone docker images with inline build process
[ https://issues.apache.org/jira/browse/HDDS-1495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16841513#comment-16841513 ] Eric Yang commented on HDDS-1495: - [~ccondit] Thank you for the fresh perspective. I will change from -Pdist to -Pdocker, and that will build ozone:${project.version} image, and Ozone maven version will materialize to docker tag. This arrangement allows hadoop-docker-ozone source to be part of hadoop source, and doesn't make docker mandatory build. Release manager can build docker image and upload to docker hub from the same source code with synchronized versioning. [~elek] [~anu] Do you agree that this is practical solution to resolve the source code repository fragmentation issue? > Create hadoop/ozone docker images with inline build process > --- > > Key: HDDS-1495 > URL: https://issues.apache.org/jira/browse/HDDS-1495 > Project: Hadoop Distributed Data Store > Issue Type: Sub-task >Reporter: Elek, Marton >Assignee: Eric Yang >Priority: Major > Attachments: HADOOP-16091.001.patch, HADOOP-16091.002.patch, > HDDS-1495.003.patch, HDDS-1495.004.patch, HDDS-1495.005.patch, > HDDS-1495.006.patch, HDDS-1495.007.patch, Hadoop Docker Image inline build > process.pdf > > > This is proposed by [~eyang] in > [this|https://lists.apache.org/thread.html/33ac54bdeacb4beb023ebd452464603aaffa095bd104cb43c22f484e@%3Chdfs-dev.hadoop.apache.org%3E] > mailing thread. > {quote}1, 3. There are 38 Apache projects hosting docker images on Docker hub > using Apache Organization. By browsing Apache github mirror. There are only 7 > projects using a separate repository for docker image build. Popular projects > official images are not from Apache organization, such as zookeeper, tomcat, > httpd. We may not disrupt what other Apache projects are doing, but it looks > like inline build process is widely employed by majority of projects such as > Nifi, Brooklyn, thrift, karaf, syncope and others. The situation seems a bit > chaotic for Apache as a whole. However, Hadoop community can decide what is > best for Hadoop. My preference is to remove ozone from source tree naming, if > Ozone is intended to be subproject of Hadoop for long period of time. This > enables Hadoop community to host docker images for various subproject without > having to check out several source tree to trigger a grand build. However, > inline build process seems more popular than separated process. Hence, I > highly recommend making docker build inline if possible. > {quote} > The main challenges are also discussed in the thread: > {code:java} > 3. Technically it would be possible to add the Dockerfile to the source > tree and publish the docker image together with the release by the > release manager but it's also problematic: > {code} > a) there is no easy way to stage the images for the vote > c) it couldn't be flagged as automated on dockerhub > d) It couldn't support the critical updates. > * Updating existing images (for example in case of an ssl bug, rebuild > all the existing images with exactly the same payload but updated base > image/os environment) > * Creating image for older releases (We would like to provide images, > for hadoop 2.6/2.7/2.7/2.8/2.9. Especially for doing automatic testing > with different versions). > {code:java} > {code} > The a) can be solved (as [~eyang] suggested) with using a personal docker > image during the vote and publish it to the dockerhub after the vote (in case > the permission can be set by the INFRA) > Note: based on LEGAL-270 and linked discussion both approaches (inline build > process / external build process) are compatible with the apache release. > Note: HDDS-851 and HADOOP-14898 contains more information about these > problems. -- 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
[jira] [Commented] (HDDS-1495) Create hadoop/ozone docker images with inline build process
[ https://issues.apache.org/jira/browse/HDDS-1495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16840870#comment-16840870 ] Craig Condit commented on HDDS-1495: I realize I'm probably a little late to this party, but maybe that means I'll have a fresh perspective on this... I think it bears looking at what the purpose of the various Docker images we're creating are. First, we have the Docker image which is created by _*start-build-env.sh*_ in the root of the Hadoop project. This is extremely useful for ensuring a consisten_t *build*_ ** environment, but is not suitable for public distribution. Additionally, I think there are valid uses for other images which include local testing, integration testing, pre-commit testing, etc. Finally, we have public images which are meant for end users to build upon.** How exactly each of these images is created is IMO not that important – this should probably be dictated by those who are acting as release managers. As a local developer, I'd prefer a solution that doesn't involve automatic creation of downstream images on every build (even on dist builds). I think using something *-Pdocker* to activate building is fine, as it's opt-in rather than opt-out. All of the above applies to Hadoop proper, so now for the Ozone-specific bits... Since Ozone is meant to run as a plugin to an existing Hadoop installation, I think it's worth considering publishing multiple images with different underlying Hadoop base versions. Today this might include: * ozone:0.4-hadoop-3.0.3 * ozone:0.4-hadoop-3.1.2 * ozone:0.4-hadoop-3.2.0 These could serve as reference implementations, suitable for publishing on DockerHub,etc. (along with associated Dockerfiles). Distributions and users who are more security conscious would probably rebuild based on security patches in underlying OS, etc. This pattern tracks closely with how many other complex open source projects release images (even openjdk typically comes in several different flavors (alpine, ubuntu, slim, etc.). > Create hadoop/ozone docker images with inline build process > --- > > Key: HDDS-1495 > URL: https://issues.apache.org/jira/browse/HDDS-1495 > Project: Hadoop Distributed Data Store > Issue Type: Sub-task >Reporter: Elek, Marton >Assignee: Eric Yang >Priority: Major > Attachments: HADOOP-16091.001.patch, HADOOP-16091.002.patch, > HDDS-1495.003.patch, HDDS-1495.004.patch, HDDS-1495.005.patch, > HDDS-1495.006.patch, HDDS-1495.007.patch, Hadoop Docker Image inline build > process.pdf > > > This is proposed by [~eyang] in > [this|https://lists.apache.org/thread.html/33ac54bdeacb4beb023ebd452464603aaffa095bd104cb43c22f484e@%3Chdfs-dev.hadoop.apache.org%3E] > mailing thread. > {quote}1, 3. There are 38 Apache projects hosting docker images on Docker hub > using Apache Organization. By browsing Apache github mirror. There are only 7 > projects using a separate repository for docker image build. Popular projects > official images are not from Apache organization, such as zookeeper, tomcat, > httpd. We may not disrupt what other Apache projects are doing, but it looks > like inline build process is widely employed by majority of projects such as > Nifi, Brooklyn, thrift, karaf, syncope and others. The situation seems a bit > chaotic for Apache as a whole. However, Hadoop community can decide what is > best for Hadoop. My preference is to remove ozone from source tree naming, if > Ozone is intended to be subproject of Hadoop for long period of time. This > enables Hadoop community to host docker images for various subproject without > having to check out several source tree to trigger a grand build. However, > inline build process seems more popular than separated process. Hence, I > highly recommend making docker build inline if possible. > {quote} > The main challenges are also discussed in the thread: > {code:java} > 3. Technically it would be possible to add the Dockerfile to the source > tree and publish the docker image together with the release by the > release manager but it's also problematic: > {code} > a) there is no easy way to stage the images for the vote > c) it couldn't be flagged as automated on dockerhub > d) It couldn't support the critical updates. > * Updating existing images (for example in case of an ssl bug, rebuild > all the existing images with exactly the same payload but updated base > image/os environment) > * Creating image for older releases (We would like to provide images, > for hadoop 2.6/2.7/2.7/2.8/2.9. Especially for doing automatic testing > with different versions). > {code:java} > {code} > The a) can be solved (as [~eyang] suggested) with using a personal docker > image during the vote and publish it to the docker
[jira] [Commented] (HDDS-1495) Create hadoop/ozone docker images with inline build process
[ https://issues.apache.org/jira/browse/HDDS-1495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16840030#comment-16840030 ] Eric Yang commented on HDDS-1495: - {quote}IIUC there are no Ozone bits inside the docker image. The docker image is used for running tests only, and it will use the Ozone bits from the distro where it is invoked via the mount. So the Apache release process is not being bypassed. {quote} Someone can change /opt/starter.sh to do something completely different for hadoop-runner image. It can end up doing something completely different and not call any ozone script. Ozone 0.4.0 release will not work as intended using Ozone 0.4.0 binary tarball supplied docker-compose script. There is no reliable way to run Ozone 0.4.0 release because hadoop-runner source code and docker image for Ozone 0.4.0 were not version controlled in Ozone 0.4.0 source tarball. Please see [release policy for source package|http://www.apache.org/legal/release-policy.html#source-packages]. You can release one or more tarball packages, and they MUST be sufficient for user to build and test. If hadoop-runner:latest image ever changes by another committer, Ozone 0.4.0 source tarball can not rebuild complete Ozone 0.4.0 behavior. We can't promise that Hadoop-runner:latest image never change because it contains hard coded uid/gid, and next revision will not have the hard coded value. This means Ozone 0.4.0 source tarball is already not meeting the "MUST be sufficient for user to build" statement in Apache release policy. > Create hadoop/ozone docker images with inline build process > --- > > Key: HDDS-1495 > URL: https://issues.apache.org/jira/browse/HDDS-1495 > Project: Hadoop Distributed Data Store > Issue Type: Sub-task >Reporter: Elek, Marton >Assignee: Eric Yang >Priority: Major > Attachments: HADOOP-16091.001.patch, HADOOP-16091.002.patch, > HDDS-1495.003.patch, HDDS-1495.004.patch, HDDS-1495.005.patch, > HDDS-1495.006.patch, HDDS-1495.007.patch, Hadoop Docker Image inline build > process.pdf > > > This is proposed by [~eyang] in > [this|https://lists.apache.org/thread.html/33ac54bdeacb4beb023ebd452464603aaffa095bd104cb43c22f484e@%3Chdfs-dev.hadoop.apache.org%3E] > mailing thread. > {quote}1, 3. There are 38 Apache projects hosting docker images on Docker hub > using Apache Organization. By browsing Apache github mirror. There are only 7 > projects using a separate repository for docker image build. Popular projects > official images are not from Apache organization, such as zookeeper, tomcat, > httpd. We may not disrupt what other Apache projects are doing, but it looks > like inline build process is widely employed by majority of projects such as > Nifi, Brooklyn, thrift, karaf, syncope and others. The situation seems a bit > chaotic for Apache as a whole. However, Hadoop community can decide what is > best for Hadoop. My preference is to remove ozone from source tree naming, if > Ozone is intended to be subproject of Hadoop for long period of time. This > enables Hadoop community to host docker images for various subproject without > having to check out several source tree to trigger a grand build. However, > inline build process seems more popular than separated process. Hence, I > highly recommend making docker build inline if possible. > {quote} > The main challenges are also discussed in the thread: > {code:java} > 3. Technically it would be possible to add the Dockerfile to the source > tree and publish the docker image together with the release by the > release manager but it's also problematic: > {code} > a) there is no easy way to stage the images for the vote > c) it couldn't be flagged as automated on dockerhub > d) It couldn't support the critical updates. > * Updating existing images (for example in case of an ssl bug, rebuild > all the existing images with exactly the same payload but updated base > image/os environment) > * Creating image for older releases (We would like to provide images, > for hadoop 2.6/2.7/2.7/2.8/2.9. Especially for doing automatic testing > with different versions). > {code:java} > {code} > The a) can be solved (as [~eyang] suggested) with using a personal docker > image during the vote and publish it to the dockerhub after the vote (in case > the permission can be set by the INFRA) > Note: based on LEGAL-270 and linked discussion both approaches (inline build > process / external build process) are compatible with the apache release. > Note: HDDS-851 and HADOOP-14898 contains more information about these > problems. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: hdfs-issues-unsubs
[jira] [Commented] (HDDS-1495) Create hadoop/ozone docker images with inline build process
[ https://issues.apache.org/jira/browse/HDDS-1495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16840005#comment-16840005 ] Arpit Agarwal commented on HDDS-1495: - bq. I disagree. I shouldn't have to find out that we made a release vote on Ozone 0.4.0 then to find out that the blockade test is testing on apache/hadoop-runner:latest docker image instead of apache/ozone:0.4.0 release. This arrangement completely breaks the Apache release voting process because it allows someone to make changes to hadoop-runner docker image to change the definition of Ozone 0.4.0 release on Docker hub. IIUC there are no Ozone bits inside the docker image. The docker image is used for running tests only, and it will use the Ozone bits from the distro where it is invoked via the mount. So the Apache release process is not being bypassed. > Create hadoop/ozone docker images with inline build process > --- > > Key: HDDS-1495 > URL: https://issues.apache.org/jira/browse/HDDS-1495 > Project: Hadoop Distributed Data Store > Issue Type: Sub-task >Reporter: Elek, Marton >Assignee: Eric Yang >Priority: Major > Attachments: HADOOP-16091.001.patch, HADOOP-16091.002.patch, > HDDS-1495.003.patch, HDDS-1495.004.patch, HDDS-1495.005.patch, > HDDS-1495.006.patch, HDDS-1495.007.patch, Hadoop Docker Image inline build > process.pdf > > > This is proposed by [~eyang] in > [this|https://lists.apache.org/thread.html/33ac54bdeacb4beb023ebd452464603aaffa095bd104cb43c22f484e@%3Chdfs-dev.hadoop.apache.org%3E] > mailing thread. > {quote}1, 3. There are 38 Apache projects hosting docker images on Docker hub > using Apache Organization. By browsing Apache github mirror. There are only 7 > projects using a separate repository for docker image build. Popular projects > official images are not from Apache organization, such as zookeeper, tomcat, > httpd. We may not disrupt what other Apache projects are doing, but it looks > like inline build process is widely employed by majority of projects such as > Nifi, Brooklyn, thrift, karaf, syncope and others. The situation seems a bit > chaotic for Apache as a whole. However, Hadoop community can decide what is > best for Hadoop. My preference is to remove ozone from source tree naming, if > Ozone is intended to be subproject of Hadoop for long period of time. This > enables Hadoop community to host docker images for various subproject without > having to check out several source tree to trigger a grand build. However, > inline build process seems more popular than separated process. Hence, I > highly recommend making docker build inline if possible. > {quote} > The main challenges are also discussed in the thread: > {code:java} > 3. Technically it would be possible to add the Dockerfile to the source > tree and publish the docker image together with the release by the > release manager but it's also problematic: > {code} > a) there is no easy way to stage the images for the vote > c) it couldn't be flagged as automated on dockerhub > d) It couldn't support the critical updates. > * Updating existing images (for example in case of an ssl bug, rebuild > all the existing images with exactly the same payload but updated base > image/os environment) > * Creating image for older releases (We would like to provide images, > for hadoop 2.6/2.7/2.7/2.8/2.9. Especially for doing automatic testing > with different versions). > {code:java} > {code} > The a) can be solved (as [~eyang] suggested) with using a personal docker > image during the vote and publish it to the dockerhub after the vote (in case > the permission can be set by the INFRA) > Note: based on LEGAL-270 and linked discussion both approaches (inline build > process / external build process) are compatible with the apache release. > Note: HDDS-851 and HADOOP-14898 contains more information about these > problems. -- 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
[jira] [Commented] (HDDS-1495) Create hadoop/ozone docker images with inline build process
[ https://issues.apache.org/jira/browse/HDDS-1495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16839991#comment-16839991 ] Eric Yang commented on HDDS-1495: - {quote}The current approach allows us to build the docker images independent of the code base, allows management by Apache Infra, but allows the flexibility for us to check-in and build/publish apache Images at will.\{quote} I disagree. I shouldn't have to find out that we made a release vote on Ozone 0.4.0 then to find out that the blockade test is testing on apache/hadoop-runner:latest docker image instead of apache/ozone:0.4.0 release. This arrangement completely breaks the Apache release voting process because it allows someone to make changes to hadoop-runner docker image to change the definition of Ozone 0.4.0 release on Docker hub. {quote}I am well aware of that, it was a lot of entertainment to read those emails. Let us not drag ozone into that for now; at least until we have GA release. We have more high priority items to deal with now.\{quote} The release process must be inline with Apache release process. You can generate the source tarball from hadoop-docker-ozone, and also the docker save command to ensure the missing code are voted on. Without doing the proper packaging of hadoop-docker-ozone and docker-compose file version tagging, it is hollow to vote on any Ozone releases. The binary that runs from Ozone release tarball can differ from day to day depending on what is uploaded in apache/hadoop-runner. The current approach can not be claimed as working because the community hasn't been able to follow through its own release process design, and breaks Apache release voting process. If Ozone community does not follow through then I would have no choice but withdrew my own vote for Ozone 0.4.0 release. > Create hadoop/ozone docker images with inline build process > --- > > Key: HDDS-1495 > URL: https://issues.apache.org/jira/browse/HDDS-1495 > Project: Hadoop Distributed Data Store > Issue Type: Sub-task >Reporter: Elek, Marton >Assignee: Eric Yang >Priority: Major > Attachments: HADOOP-16091.001.patch, HADOOP-16091.002.patch, > HDDS-1495.003.patch, HDDS-1495.004.patch, HDDS-1495.005.patch, > HDDS-1495.006.patch, HDDS-1495.007.patch, Hadoop Docker Image inline build > process.pdf > > > This is proposed by [~eyang] in > [this|https://lists.apache.org/thread.html/33ac54bdeacb4beb023ebd452464603aaffa095bd104cb43c22f484e@%3Chdfs-dev.hadoop.apache.org%3E] > mailing thread. > {quote}1, 3. There are 38 Apache projects hosting docker images on Docker hub > using Apache Organization. By browsing Apache github mirror. There are only 7 > projects using a separate repository for docker image build. Popular projects > official images are not from Apache organization, such as zookeeper, tomcat, > httpd. We may not disrupt what other Apache projects are doing, but it looks > like inline build process is widely employed by majority of projects such as > Nifi, Brooklyn, thrift, karaf, syncope and others. The situation seems a bit > chaotic for Apache as a whole. However, Hadoop community can decide what is > best for Hadoop. My preference is to remove ozone from source tree naming, if > Ozone is intended to be subproject of Hadoop for long period of time. This > enables Hadoop community to host docker images for various subproject without > having to check out several source tree to trigger a grand build. However, > inline build process seems more popular than separated process. Hence, I > highly recommend making docker build inline if possible. > {quote} > The main challenges are also discussed in the thread: > {code:java} > 3. Technically it would be possible to add the Dockerfile to the source > tree and publish the docker image together with the release by the > release manager but it's also problematic: > {code} > a) there is no easy way to stage the images for the vote > c) it couldn't be flagged as automated on dockerhub > d) It couldn't support the critical updates. > * Updating existing images (for example in case of an ssl bug, rebuild > all the existing images with exactly the same payload but updated base > image/os environment) > * Creating image for older releases (We would like to provide images, > for hadoop 2.6/2.7/2.7/2.8/2.9. Especially for doing automatic testing > with different versions). > {code:java} > {code} > The a) can be solved (as [~eyang] suggested) with using a personal docker > image during the vote and publish it to the dockerhub after the vote (in case > the permission can be set by the INFRA) > Note: based on LEGAL-270 and linked discussion both approaches (inline build > process / external build process) are compatible with the
[jira] [Commented] (HDDS-1495) Create hadoop/ozone docker images with inline build process
[ https://issues.apache.org/jira/browse/HDDS-1495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16839877#comment-16839877 ] Anu Engineer commented on HDDS-1495: The current approach allows us to build the docker images independent of the code base, allows management by Apache Infra, but allows the flexibility for us to check-in and build/publish apache Images at will. {quote} I was in front and center of that battle and have made every adjustment to keep everyone happy. Please provide good reasons if you like to revisit the consensus decision that had been made. {quote} I am well aware of that, it was a lot of entertainment to read those emails. Let us not drag ozone into that for now; at least until we have GA release. We have more high priority items to deal with now. > Create hadoop/ozone docker images with inline build process > --- > > Key: HDDS-1495 > URL: https://issues.apache.org/jira/browse/HDDS-1495 > Project: Hadoop Distributed Data Store > Issue Type: Sub-task >Reporter: Elek, Marton >Assignee: Eric Yang >Priority: Major > Attachments: HADOOP-16091.001.patch, HADOOP-16091.002.patch, > HDDS-1495.003.patch, HDDS-1495.004.patch, HDDS-1495.005.patch, > HDDS-1495.006.patch, HDDS-1495.007.patch, Hadoop Docker Image inline build > process.pdf > > > This is proposed by [~eyang] in > [this|https://lists.apache.org/thread.html/33ac54bdeacb4beb023ebd452464603aaffa095bd104cb43c22f484e@%3Chdfs-dev.hadoop.apache.org%3E] > mailing thread. > {quote}1, 3. There are 38 Apache projects hosting docker images on Docker hub > using Apache Organization. By browsing Apache github mirror. There are only 7 > projects using a separate repository for docker image build. Popular projects > official images are not from Apache organization, such as zookeeper, tomcat, > httpd. We may not disrupt what other Apache projects are doing, but it looks > like inline build process is widely employed by majority of projects such as > Nifi, Brooklyn, thrift, karaf, syncope and others. The situation seems a bit > chaotic for Apache as a whole. However, Hadoop community can decide what is > best for Hadoop. My preference is to remove ozone from source tree naming, if > Ozone is intended to be subproject of Hadoop for long period of time. This > enables Hadoop community to host docker images for various subproject without > having to check out several source tree to trigger a grand build. However, > inline build process seems more popular than separated process. Hence, I > highly recommend making docker build inline if possible. > {quote} > The main challenges are also discussed in the thread: > {code:java} > 3. Technically it would be possible to add the Dockerfile to the source > tree and publish the docker image together with the release by the > release manager but it's also problematic: > {code} > a) there is no easy way to stage the images for the vote > c) it couldn't be flagged as automated on dockerhub > d) It couldn't support the critical updates. > * Updating existing images (for example in case of an ssl bug, rebuild > all the existing images with exactly the same payload but updated base > image/os environment) > * Creating image for older releases (We would like to provide images, > for hadoop 2.6/2.7/2.7/2.8/2.9. Especially for doing automatic testing > with different versions). > {code:java} > {code} > The a) can be solved (as [~eyang] suggested) with using a personal docker > image during the vote and publish it to the dockerhub after the vote (in case > the permission can be set by the INFRA) > Note: based on LEGAL-270 and linked discussion both approaches (inline build > process / external build process) are compatible with the apache release. > Note: HDDS-851 and HADOOP-14898 contains more information about these > problems. -- 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
[jira] [Commented] (HDDS-1495) Create hadoop/ozone docker images with inline build process
[ https://issues.apache.org/jira/browse/HDDS-1495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16839874#comment-16839874 ] Eric Yang commented on HDDS-1495: - [~anu], the current implementation in YARN has reached consensus to provide a flag to build docker images, and docker images can be built by passing -Pdocker. I was in front and center of that battle and have made every adjustment to keep everyone happy. Please provide good reasons if you like to revisit the consensus decision that had been made. > Create hadoop/ozone docker images with inline build process > --- > > Key: HDDS-1495 > URL: https://issues.apache.org/jira/browse/HDDS-1495 > Project: Hadoop Distributed Data Store > Issue Type: Sub-task >Reporter: Elek, Marton >Assignee: Eric Yang >Priority: Major > Attachments: HADOOP-16091.001.patch, HADOOP-16091.002.patch, > HDDS-1495.003.patch, HDDS-1495.004.patch, HDDS-1495.005.patch, > HDDS-1495.006.patch, HDDS-1495.007.patch, Hadoop Docker Image inline build > process.pdf > > > This is proposed by [~eyang] in > [this|https://lists.apache.org/thread.html/33ac54bdeacb4beb023ebd452464603aaffa095bd104cb43c22f484e@%3Chdfs-dev.hadoop.apache.org%3E] > mailing thread. > {quote}1, 3. There are 38 Apache projects hosting docker images on Docker hub > using Apache Organization. By browsing Apache github mirror. There are only 7 > projects using a separate repository for docker image build. Popular projects > official images are not from Apache organization, such as zookeeper, tomcat, > httpd. We may not disrupt what other Apache projects are doing, but it looks > like inline build process is widely employed by majority of projects such as > Nifi, Brooklyn, thrift, karaf, syncope and others. The situation seems a bit > chaotic for Apache as a whole. However, Hadoop community can decide what is > best for Hadoop. My preference is to remove ozone from source tree naming, if > Ozone is intended to be subproject of Hadoop for long period of time. This > enables Hadoop community to host docker images for various subproject without > having to check out several source tree to trigger a grand build. However, > inline build process seems more popular than separated process. Hence, I > highly recommend making docker build inline if possible. > {quote} > The main challenges are also discussed in the thread: > {code:java} > 3. Technically it would be possible to add the Dockerfile to the source > tree and publish the docker image together with the release by the > release manager but it's also problematic: > {code} > a) there is no easy way to stage the images for the vote > c) it couldn't be flagged as automated on dockerhub > d) It couldn't support the critical updates. > * Updating existing images (for example in case of an ssl bug, rebuild > all the existing images with exactly the same payload but updated base > image/os environment) > * Creating image for older releases (We would like to provide images, > for hadoop 2.6/2.7/2.7/2.8/2.9. Especially for doing automatic testing > with different versions). > {code:java} > {code} > The a) can be solved (as [~eyang] suggested) with using a personal docker > image during the vote and publish it to the dockerhub after the vote (in case > the permission can be set by the INFRA) > Note: based on LEGAL-270 and linked discussion both approaches (inline build > process / external build process) are compatible with the apache release. > Note: HDDS-851 and HADOOP-14898 contains more information about these > problems. -- 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
[jira] [Commented] (HDDS-1495) Create hadoop/ozone docker images with inline build process
[ https://issues.apache.org/jira/browse/HDDS-1495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16839865#comment-16839865 ] Anu Engineer commented on HDDS-1495: {quote}The goal is to fold [hadoop-docker-ozone repository|https://github.com/apache/hadoop-docker-ozone] and [hadoop-runner-latest branch|https://github.com/apache/hadoop/tree/docker-hadoop-runner-latest] into hadoop trunk. {quote} I am a strong -1; on this. In the YARN community thread, there was already too much opposition in bringing the docker code to mainline. Ozone is part of the Hadoop and we must respect the community opinion. > Create hadoop/ozone docker images with inline build process > --- > > Key: HDDS-1495 > URL: https://issues.apache.org/jira/browse/HDDS-1495 > Project: Hadoop Distributed Data Store > Issue Type: Sub-task >Reporter: Elek, Marton >Assignee: Eric Yang >Priority: Major > Attachments: HADOOP-16091.001.patch, HADOOP-16091.002.patch, > HDDS-1495.003.patch, HDDS-1495.004.patch, HDDS-1495.005.patch, > HDDS-1495.006.patch, HDDS-1495.007.patch, Hadoop Docker Image inline build > process.pdf > > > This is proposed by [~eyang] in > [this|https://lists.apache.org/thread.html/33ac54bdeacb4beb023ebd452464603aaffa095bd104cb43c22f484e@%3Chdfs-dev.hadoop.apache.org%3E] > mailing thread. > {quote}1, 3. There are 38 Apache projects hosting docker images on Docker hub > using Apache Organization. By browsing Apache github mirror. There are only 7 > projects using a separate repository for docker image build. Popular projects > official images are not from Apache organization, such as zookeeper, tomcat, > httpd. We may not disrupt what other Apache projects are doing, but it looks > like inline build process is widely employed by majority of projects such as > Nifi, Brooklyn, thrift, karaf, syncope and others. The situation seems a bit > chaotic for Apache as a whole. However, Hadoop community can decide what is > best for Hadoop. My preference is to remove ozone from source tree naming, if > Ozone is intended to be subproject of Hadoop for long period of time. This > enables Hadoop community to host docker images for various subproject without > having to check out several source tree to trigger a grand build. However, > inline build process seems more popular than separated process. Hence, I > highly recommend making docker build inline if possible. > {quote} > The main challenges are also discussed in the thread: > {code:java} > 3. Technically it would be possible to add the Dockerfile to the source > tree and publish the docker image together with the release by the > release manager but it's also problematic: > {code} > a) there is no easy way to stage the images for the vote > c) it couldn't be flagged as automated on dockerhub > d) It couldn't support the critical updates. > * Updating existing images (for example in case of an ssl bug, rebuild > all the existing images with exactly the same payload but updated base > image/os environment) > * Creating image for older releases (We would like to provide images, > for hadoop 2.6/2.7/2.7/2.8/2.9. Especially for doing automatic testing > with different versions). > {code:java} > {code} > The a) can be solved (as [~eyang] suggested) with using a personal docker > image during the vote and publish it to the dockerhub after the vote (in case > the permission can be set by the INFRA) > Note: based on LEGAL-270 and linked discussion both approaches (inline build > process / external build process) are compatible with the apache release. > Note: HDDS-851 and HADOOP-14898 contains more information about these > problems. -- 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
[jira] [Commented] (HDDS-1495) Create hadoop/ozone docker images with inline build process
[ https://issues.apache.org/jira/browse/HDDS-1495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16839804#comment-16839804 ] Eric Yang commented on HDDS-1495: - {quote} a) As I wrote earler the statement is not true, the source of hadoop-runner is part of hadoop repository as discussed on the mailing list{quote} Hadoop-runner is not building from hadoop-docker-ozone. Build.sh builds apache/ozone:latest, not apache/hadoop-runner:latest. I am confused by your statement above. {quote} b) As discussed earlier it can be risky for all the downstream tests where we need to set the classpath. This change should be very carefully tested. And this is just not required because in containerized world the version is defined by the container not the content.{quote} We can continue to track CLASSPATH issue in HDDS-1520. I don't believe closing it as can not reproduce is the right solution because some of the issues with CLASSPATH bloat were identified and have solutions and recommendation in HADOOP-7939, HADOOP-6255 and even earlier that I have lost track. {quote} d) I think it's very important to define the scope of the provided docker images. Until now it was clearly defined as developer tools and not for production. I think for production use case most of the enterprise users have own processes to create standard images (according to defined security policies). To providing production-ready docker images are harder than removing default sudo privileges (IMHO).{quote} Hadoop already define developer tools by running start-build-env.sh in HADOOP-11843. Attempt to redefine development process seems redundant. Official Ozone image has been publishing to docker hub as official Ozone docker build in HDDS-851. HDDS-1526 also intend to create Ozone 0.4.0 docker image while maintain a separate code change and branch process from the 0.4.0 release vote. This puts the release process at risk that we may have difficulty to reproduce Ozone 0.4.0 docker image, when someone forget to tag multiple source code repositories with the same version or the released code didn't get voted on. The goal is to fold [hadoop-docker-ozone repository|https://github.com/apache/hadoop-docker-ozone] and [hadoop-runner-latest branch|https://github.com/apache/hadoop/tree/docker-hadoop-runner-latest] into hadoop trunk. The consecutive versioning of Ozone releases can apply to docker submodule in ozone-0.4 branches. I admit that I didn't like ozone-0.4 branch in Hadoop source code, but I did not ask for separating repository. In my view, a separate repository means a separate incubation project in Apache. I did not predict that hadoop-docker-ozone repository to be created, but I would be ok if hadoop-ozone repository contains all Ozone related code. I am inclined to agree that ozone-0.4 branch is still far better than having hadoop-docker-ozone repository or hadoop-runner-latest branch for now. [~elek] Do we agree on bring those code into [ozone-0.4 branch|https://github.com/apache/hadoop/tree/ozone-0.4] and [trunk|https://github.com/apache/hadoop/]? > Create hadoop/ozone docker images with inline build process > --- > > Key: HDDS-1495 > URL: https://issues.apache.org/jira/browse/HDDS-1495 > Project: Hadoop Distributed Data Store > Issue Type: Sub-task >Reporter: Elek, Marton >Assignee: Eric Yang >Priority: Major > Attachments: HADOOP-16091.001.patch, HADOOP-16091.002.patch, > HDDS-1495.003.patch, HDDS-1495.004.patch, HDDS-1495.005.patch, > HDDS-1495.006.patch, HDDS-1495.007.patch, Hadoop Docker Image inline build > process.pdf > > > This is proposed by [~eyang] in > [this|https://lists.apache.org/thread.html/33ac54bdeacb4beb023ebd452464603aaffa095bd104cb43c22f484e@%3Chdfs-dev.hadoop.apache.org%3E] > mailing thread. > {quote}1, 3. There are 38 Apache projects hosting docker images on Docker hub > using Apache Organization. By browsing Apache github mirror. There are only 7 > projects using a separate repository for docker image build. Popular projects > official images are not from Apache organization, such as zookeeper, tomcat, > httpd. We may not disrupt what other Apache projects are doing, but it looks > like inline build process is widely employed by majority of projects such as > Nifi, Brooklyn, thrift, karaf, syncope and others. The situation seems a bit > chaotic for Apache as a whole. However, Hadoop community can decide what is > best for Hadoop. My preference is to remove ozone from source tree naming, if > Ozone is intended to be subproject of Hadoop for long period of time. This > enables Hadoop community to host docker images for various subproject without > having to check out several source tree to trigger a grand build. However, > inl
[jira] [Commented] (HDDS-1495) Create hadoop/ozone docker images with inline build process
[ https://issues.apache.org/jira/browse/HDDS-1495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16838466#comment-16838466 ] Elek, Marton commented on HDDS-1495: One of my problem with the "design document" that it combines multiple issues which are loosely connected. I propose to discuss them under separated issues: The "Clean up existing issues" contains 4 steps: a) As I wrote earler the statement is not true, the source of hadoop-runner is part of hadoop repository as discussed on the mailing list b) As discussed earlier it can be risky for all the downstream tests where we need to set the classpath. This change should be very carefully tested. And this is just not required because in containerized world the version is defined by the container not the content. c) Created a separated issue: HADOOP-16312, please discuss it there d) I think it's very important to define the scope of the provided docker images. Until now it was clearly defined as developer tools and not for production. I think for production use case most of the enterprise users have own processes to create standard images (according to defined security policies). To providing production-ready docker images are harder than removing default sudo privileges (IMHO). > Create hadoop/ozone docker images with inline build process > --- > > Key: HDDS-1495 > URL: https://issues.apache.org/jira/browse/HDDS-1495 > Project: Hadoop Distributed Data Store > Issue Type: New Feature >Reporter: Elek, Marton >Assignee: Eric Yang >Priority: Major > Attachments: HADOOP-16091.001.patch, HADOOP-16091.002.patch, > HDDS-1495.003.patch, HDDS-1495.004.patch, HDDS-1495.005.patch, > HDDS-1495.006.patch, HDDS-1495.007.patch, Hadoop Docker Image inline build > process.pdf > > > This is proposed by [~eyang] in > [this|https://lists.apache.org/thread.html/33ac54bdeacb4beb023ebd452464603aaffa095bd104cb43c22f484e@%3Chdfs-dev.hadoop.apache.org%3E] > mailing thread. > {quote}1, 3. There are 38 Apache projects hosting docker images on Docker hub > using Apache Organization. By browsing Apache github mirror. There are only 7 > projects using a separate repository for docker image build. Popular projects > official images are not from Apache organization, such as zookeeper, tomcat, > httpd. We may not disrupt what other Apache projects are doing, but it looks > like inline build process is widely employed by majority of projects such as > Nifi, Brooklyn, thrift, karaf, syncope and others. The situation seems a bit > chaotic for Apache as a whole. However, Hadoop community can decide what is > best for Hadoop. My preference is to remove ozone from source tree naming, if > Ozone is intended to be subproject of Hadoop for long period of time. This > enables Hadoop community to host docker images for various subproject without > having to check out several source tree to trigger a grand build. However, > inline build process seems more popular than separated process. Hence, I > highly recommend making docker build inline if possible. > {quote} > The main challenges are also discussed in the thread: > {code:java} > 3. Technically it would be possible to add the Dockerfile to the source > tree and publish the docker image together with the release by the > release manager but it's also problematic: > {code} > a) there is no easy way to stage the images for the vote > c) it couldn't be flagged as automated on dockerhub > d) It couldn't support the critical updates. > * Updating existing images (for example in case of an ssl bug, rebuild > all the existing images with exactly the same payload but updated base > image/os environment) > * Creating image for older releases (We would like to provide images, > for hadoop 2.6/2.7/2.7/2.8/2.9. Especially for doing automatic testing > with different versions). > {code:java} > {code} > The a) can be solved (as [~eyang] suggested) with using a personal docker > image during the vote and publish it to the dockerhub after the vote (in case > the permission can be set by the INFRA) > Note: based on LEGAL-270 and linked discussion both approaches (inline build > process / external build process) are compatible with the apache release. > Note: HDDS-851 and HADOOP-14898 contains more information about these > problems. -- 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
[jira] [Commented] (HDDS-1495) Create hadoop/ozone docker images with inline build process
[ https://issues.apache.org/jira/browse/HDDS-1495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16837331#comment-16837331 ] Elek, Marton commented on HDDS-1495: IMHO The uploaded design doc ignores many of the previous comments, therefore it requires additional discussion IMHO. > Create hadoop/ozone docker images with inline build process > --- > > Key: HDDS-1495 > URL: https://issues.apache.org/jira/browse/HDDS-1495 > Project: Hadoop Distributed Data Store > Issue Type: New Feature >Reporter: Elek, Marton >Assignee: Eric Yang >Priority: Major > Attachments: HADOOP-16091.001.patch, HADOOP-16091.002.patch, > HDDS-1495.003.patch, HDDS-1495.004.patch, HDDS-1495.005.patch, > HDDS-1495.006.patch, HDDS-1495.007.patch, Hadoop Docker Image inline build > process.pdf > > > This is proposed by [~eyang] in > [this|https://lists.apache.org/thread.html/33ac54bdeacb4beb023ebd452464603aaffa095bd104cb43c22f484e@%3Chdfs-dev.hadoop.apache.org%3E] > mailing thread. > {quote}1, 3. There are 38 Apache projects hosting docker images on Docker hub > using Apache Organization. By browsing Apache github mirror. There are only 7 > projects using a separate repository for docker image build. Popular projects > official images are not from Apache organization, such as zookeeper, tomcat, > httpd. We may not disrupt what other Apache projects are doing, but it looks > like inline build process is widely employed by majority of projects such as > Nifi, Brooklyn, thrift, karaf, syncope and others. The situation seems a bit > chaotic for Apache as a whole. However, Hadoop community can decide what is > best for Hadoop. My preference is to remove ozone from source tree naming, if > Ozone is intended to be subproject of Hadoop for long period of time. This > enables Hadoop community to host docker images for various subproject without > having to check out several source tree to trigger a grand build. However, > inline build process seems more popular than separated process. Hence, I > highly recommend making docker build inline if possible. > {quote} > The main challenges are also discussed in the thread: > {code:java} > 3. Technically it would be possible to add the Dockerfile to the source > tree and publish the docker image together with the release by the > release manager but it's also problematic: > {code} > a) there is no easy way to stage the images for the vote > c) it couldn't be flagged as automated on dockerhub > d) It couldn't support the critical updates. > * Updating existing images (for example in case of an ssl bug, rebuild > all the existing images with exactly the same payload but updated base > image/os environment) > * Creating image for older releases (We would like to provide images, > for hadoop 2.6/2.7/2.7/2.8/2.9. Especially for doing automatic testing > with different versions). > {code:java} > {code} > The a) can be solved (as [~eyang] suggested) with using a personal docker > image during the vote and publish it to the dockerhub after the vote (in case > the permission can be set by the INFRA) > Note: based on LEGAL-270 and linked discussion both approaches (inline build > process / external build process) are compatible with the apache release. > Note: HDDS-851 and HADOOP-14898 contains more information about these > problems. -- 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
[jira] [Commented] (HDDS-1495) Create hadoop/ozone docker images with inline build process
[ https://issues.apache.org/jira/browse/HDDS-1495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16837201#comment-16837201 ] Elek, Marton commented on HDDS-1495: bq. Anu Engineer I put up a design document to ensure that apache/ozone docker image is reproducible using Apache source code. Please note that apache/ozone images are reproducible even now based on the voted and approved artifacts. I like in the current approach as the dockerhub automated build guarantees that the builds are reproducible, there is a link to the source repository and the hadoop version shows the exact release version. bq. The current arrangement depends on a third party source code to build apache/hadoop-runner image is unnatural and subject to GPL terms because it includes byteman. Put on my Apache member hat, the technical and political deficiency must be addressed in Ozone community source code. 1. AFAIK byteman is LGPL and not GPL. IANAL but LGPL can be linked (it's category x) and byteman is used just as a runtime tool (java agent) the source code/ozone doesn't depend on byteman in any way. But I agree to remove. We may need a LEGAL confirmation if it's a violation. But again: I agree, it's an important question and thanks to start the discussion about it. 2. This is the repository of the hadoop-runner image: https://github.com/apache/hadoop-docker-ozone This is part of the hadoop project. The creation of the repository was discussed not just in the related jira but on the dev mailing list: https://mail-archives.apache.org/mod_mbox/hadoop-hdfs-dev/201901.mbox/%3Cc0bce845-34b3-e8d3-e438-77f8a0c28be0%40apache.org%3E bq. Elek, Marton k8s-dev profiles doesn't exist until a few days ago that I point out the deficiency in Hadoop binary tarball creation. Please don't try to build everything on your own. It would not be productive for the community. 1. First of all I apologize if you feel the creation of the k8s-dev profile is just an offensive step as a result of this discussion. It was definitely not the intention and sorry if it seemed to be a message. 2. k8s-dev profile creation was part of a longer process. Originally we started to use skaffold but it turned it's not flexible enough to support multiple different environment. See HDDS-1412 and related jiras especially HDDS-1384 and HDDS-829. 3. I like to work together with others. I know that I have strength and weaknesses. And I enjoy when others help me to avoid my mistakes. 4. I am reading all of the comments during a debate and trying to learn from arguments of others (including yours). I am pretty sure that my view is modified by your ideas. Please don't blame me for this one... 5. For example I think the k8s-dev and k8s-dev-push profile names are not very good. I think I am influenced by your idea and I think it should be docker-image-build and docker-push. Maybe in an other place, but I think we need one place where we create the _development docker images and it should be usable both by kubernetes and any other components. bq. I also ran into a secondary issue that smoketest tries to download multi-gigabytes of third party docker images. It caused my vm development environment to run out of space (with 20 of 50GB free). I waited 45 minutes for the download, and have to spend half day to try to clean up the debris. I don't think bring in the entire Hadoop ecosystem to run test on one machine is the correct way to perform development. I would happily pay the 30 seconds initial wait time to build locally than 45 minutes download time of third party flokkr/hadoop images that we have no access to make modification. 1. Download time: Please open a separated issue for this. I agree that we need to improve this page. I have same experiments to reduce the size of hadoop images (for example with removing docs + aws dependencies) 2. 3rd party image: flokkr/hadoop is the only way to use older hadoop versions. As of now we have only apache/hadoop:2 (latest release from 2.x branch) and apache//hadoop:3.x images. I agree that we should improve it. I think the easiest way to generate more apache/hadoop images with the current approach. This is blocked by https://issues.apache.org/jira/browse/HADOOP-16092 This is opened based on your comment and I asked your help in the last comment. 3. While this is true that we can use apache/hadoop instead of flokkr/hadoop, this is not true for all the dependencies. We couldn't create docker images for all the downstream projects (spark, hive, tensorflow) but we need them to create scripted compatibility tests. I think it's acceptable to use 3rdparty docker images. (not for hadoop) > Create hadoop/ozone docker images with inline build process > --- > > Key: HDDS-1495 > URL: https://issues.apache.org/jira/bro
[jira] [Commented] (HDDS-1495) Create hadoop/ozone docker images with inline build process
[ https://issues.apache.org/jira/browse/HDDS-1495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16836788#comment-16836788 ] Hadoop QA commented on HDDS-1495: - | (x) *{color:red}-1 overall{color}* | \\ \\ || Vote || Subsystem || Runtime || Comment || | {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 32s{color} | {color:blue} Docker mode activated. {color} | || || || || {color:brown} Prechecks {color} || | {color:green}+1{color} | {color:green} dupname {color} | {color:green} 0m 0s{color} | {color:green} No case conflicting files found. {color} | | {color:blue}0{color} | {color:blue} shelldocs {color} | {color:blue} 0m 0s{color} | {color:blue} Shelldocs was not available. {color} | | {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s{color} | {color:green} The patch does not contain any @author tags. {color} | | {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m 0s{color} | {color:red} The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch. {color} | || || || || {color:brown} trunk Compile Tests {color} || | {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 51s{color} | {color:blue} Maven dependency ordering for branch {color} | | {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 6m 59s{color} | {color:green} trunk passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m 31s{color} | {color:green} trunk passed {color} | | {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 0s{color} | {color:green} trunk passed {color} | | {color:green}+1{color} | {color:green} shadedclient {color} | {color:green} 12m 51s{color} | {color:green} branch has no errors when building and testing our client artifacts. {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m 17s{color} | {color:green} trunk passed {color} | || || || || {color:brown} Patch Compile Tests {color} || | {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 21s{color} | {color:blue} Maven dependency ordering for patch {color} | | {color:red}-1{color} | {color:red} mvninstall {color} | {color:red} 5m 45s{color} | {color:red} hadoop-ozone in the patch failed. {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m 43s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} javac {color} | {color:green} 3m 43s{color} | {color:green} the patch passed {color} | | {color:red}-1{color} | {color:red} hadolint {color} | {color:red} 0m 2s{color} | {color:red} The patch generated 12 new + 0 unchanged - 0 fixed = 12 total (was 0) {color} | | {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 0s{color} | {color:green} the patch passed {color} | | {color:orange}-0{color} | {color:orange} pylint {color} | {color:orange} 0m 3s{color} | {color:orange} The patch generated 156 new + 0 unchanged - 0 fixed = 156 total (was 0) {color} | | {color:red}-1{color} | {color:red} shellcheck {color} | {color:red} 0m 1s{color} | {color:red} The patch generated 5 new + 0 unchanged - 0 fixed = 5 total (was 0) {color} | | {color:red}-1{color} | {color:red} whitespace {color} | {color:red} 0m 0s{color} | {color:red} The patch has 1 line(s) that end in whitespace. Use git apply --whitespace=fix <>. Refer https://git-scm.com/docs/git-apply {color} | | {color:green}+1{color} | {color:green} xml {color} | {color:green} 0m 7s{color} | {color:green} The patch has no ill-formed XML file. {color} | | {color:green}+1{color} | {color:green} shadedclient {color} | {color:green} 11m 18s{color} | {color:green} patch has no errors when building and testing our client artifacts. {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m 16s{color} | {color:green} the patch passed {color} | || || || || {color:brown} Other Tests {color} || | {color:red}-1{color} | {color:red} unit {color} | {color:red} 2m 30s{color} | {color:red} hadoop-hdds in the patch failed. {color} | | {color:red}-1{color} | {color:red} unit {color} | {color:red} 19m 12s{color} | {color:red} hadoop-ozone in the patch failed. {color} | | {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m 36s{color} | {color:green} The patch does not generate ASF License warnings. {color} | | {color:black}{color} | {color:black} {color} | {color:black} 76m 43s{color} | {color:black} {color} | \\ \\ || Subsystem || Report/Notes || | Docker | Client=17.05.0-ce Server=17.05.0-ce base: https://builds.apache.org/job/PreCommit-HDDS-Build/2682/artifact/out/Dockerfile | | JIRA Issue | HDDS-1495 | | JIRA Patch URL | https:/
[jira] [Commented] (HDDS-1495) Create hadoop/ozone docker images with inline build process
[ https://issues.apache.org/jira/browse/HDDS-1495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16836747#comment-16836747 ] Eric Yang commented on HDDS-1495: - Patch 007 imports docker-hadoop-runner branch code into docker image build. This will generate apache/ozone image same as apache/hadoop-runner:latest image for development purpose. The release image will not have hardcoded uid/gid, dumb-init, or byteman dependency. > Create hadoop/ozone docker images with inline build process > --- > > Key: HDDS-1495 > URL: https://issues.apache.org/jira/browse/HDDS-1495 > Project: Hadoop Distributed Data Store > Issue Type: New Feature >Reporter: Elek, Marton >Assignee: Eric Yang >Priority: Major > Attachments: HADOOP-16091.001.patch, HADOOP-16091.002.patch, > HDDS-1495.003.patch, HDDS-1495.004.patch, HDDS-1495.005.patch, > HDDS-1495.006.patch, HDDS-1495.007.patch, Hadoop Docker Image inline build > process.pdf > > > This is proposed by [~eyang] in > [this|https://lists.apache.org/thread.html/33ac54bdeacb4beb023ebd452464603aaffa095bd104cb43c22f484e@%3Chdfs-dev.hadoop.apache.org%3E] > mailing thread. > {quote}1, 3. There are 38 Apache projects hosting docker images on Docker hub > using Apache Organization. By browsing Apache github mirror. There are only 7 > projects using a separate repository for docker image build. Popular projects > official images are not from Apache organization, such as zookeeper, tomcat, > httpd. We may not disrupt what other Apache projects are doing, but it looks > like inline build process is widely employed by majority of projects such as > Nifi, Brooklyn, thrift, karaf, syncope and others. The situation seems a bit > chaotic for Apache as a whole. However, Hadoop community can decide what is > best for Hadoop. My preference is to remove ozone from source tree naming, if > Ozone is intended to be subproject of Hadoop for long period of time. This > enables Hadoop community to host docker images for various subproject without > having to check out several source tree to trigger a grand build. However, > inline build process seems more popular than separated process. Hence, I > highly recommend making docker build inline if possible. > {quote} > The main challenges are also discussed in the thread: > {code:java} > 3. Technically it would be possible to add the Dockerfile to the source > tree and publish the docker image together with the release by the > release manager but it's also problematic: > {code} > a) there is no easy way to stage the images for the vote > c) it couldn't be flagged as automated on dockerhub > d) It couldn't support the critical updates. > * Updating existing images (for example in case of an ssl bug, rebuild > all the existing images with exactly the same payload but updated base > image/os environment) > * Creating image for older releases (We would like to provide images, > for hadoop 2.6/2.7/2.7/2.8/2.9. Especially for doing automatic testing > with different versions). > {code:java} > {code} > The a) can be solved (as [~eyang] suggested) with using a personal docker > image during the vote and publish it to the dockerhub after the vote (in case > the permission can be set by the INFRA) > Note: based on LEGAL-270 and linked discussion both approaches (inline build > process / external build process) are compatible with the apache release. > Note: HDDS-851 and HADOOP-14898 contains more information about these > problems. -- 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
[jira] [Commented] (HDDS-1495) Create hadoop/ozone docker images with inline build process
[ https://issues.apache.org/jira/browse/HDDS-1495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16835976#comment-16835976 ] Hadoop QA commented on HDDS-1495: - | (x) *{color:red}-1 overall{color}* | \\ \\ || Vote || Subsystem || Runtime || Comment || | {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 24s{color} | {color:blue} Docker mode activated. {color} | || || || || {color:brown} Prechecks {color} || | {color:green}+1{color} | {color:green} dupname {color} | {color:green} 0m 0s{color} | {color:green} No case conflicting files found. {color} | | {color:blue}0{color} | {color:blue} shelldocs {color} | {color:blue} 0m 1s{color} | {color:blue} Shelldocs was not available. {color} | | {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s{color} | {color:green} The patch does not contain any @author tags. {color} | | {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m 0s{color} | {color:red} The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch. {color} | || || || || {color:brown} trunk Compile Tests {color} || | {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 51s{color} | {color:blue} Maven dependency ordering for branch {color} | | {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 7m 0s{color} | {color:green} trunk passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m 38s{color} | {color:green} trunk passed {color} | | {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 0s{color} | {color:green} trunk passed {color} | | {color:green}+1{color} | {color:green} shadedclient {color} | {color:green} 12m 55s{color} | {color:green} branch has no errors when building and testing our client artifacts. {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m 19s{color} | {color:green} trunk passed {color} | || || || || {color:brown} Patch Compile Tests {color} || | {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 20s{color} | {color:blue} Maven dependency ordering for patch {color} | | {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 6m 59s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m 44s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} javac {color} | {color:green} 3m 44s{color} | {color:green} the patch passed {color} | | {color:red}-1{color} | {color:red} hadolint {color} | {color:red} 0m 2s{color} | {color:red} The patch generated 3 new + 0 unchanged - 0 fixed = 3 total (was 0) {color} | | {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 0s{color} | {color:green} the patch passed {color} | | {color:red}-1{color} | {color:red} shellcheck {color} | {color:red} 0m 1s{color} | {color:red} The patch generated 1 new + 0 unchanged - 0 fixed = 1 total (was 0) {color} | | {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m 0s{color} | {color:green} The patch has no whitespace issues. {color} | | {color:green}+1{color} | {color:green} xml {color} | {color:green} 0m 7s{color} | {color:green} The patch has no ill-formed XML file. {color} | | {color:green}+1{color} | {color:green} shadedclient {color} | {color:green} 11m 13s{color} | {color:green} patch has no errors when building and testing our client artifacts. {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m 16s{color} | {color:green} the patch passed {color} | || || || || {color:brown} Other Tests {color} || | {color:red}-1{color} | {color:red} unit {color} | {color:red} 2m 26s{color} | {color:red} hadoop-hdds in the patch failed. {color} | | {color:red}-1{color} | {color:red} unit {color} | {color:red} 19m 11s{color} | {color:red} hadoop-ozone in the patch failed. {color} | | {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m 47s{color} | {color:green} The patch does not generate ASF License warnings. {color} | | {color:black}{color} | {color:black} {color} | {color:black} 76m 4s{color} | {color:black} {color} | \\ \\ || Subsystem || Report/Notes || | Docker | Client=17.05.0-ce Server=17.05.0-ce base: https://builds.apache.org/job/PreCommit-HDDS-Build/2680/artifact/out/Dockerfile | | JIRA Issue | HDDS-1495 | | JIRA Patch URL | https://issues.apache.org/jira/secure/attachment/12968235/HDDS-1495.006.patch | | Optional Tests | dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient xml hadolint shellcheck shelldocs | | uname | Linux 1115305b1227 4.4.0-138-generic #164-Ubuntu SMP Tue Oct 2 17:
[jira] [Commented] (HDDS-1495) Create hadoop/ozone docker images with inline build process
[ https://issues.apache.org/jira/browse/HDDS-1495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16835949#comment-16835949 ] Eric Yang commented on HDDS-1495: - Patch 006 added entrypoint.sh and also include full Dockerfile instead of depending on apache/hadoop-runner binary. > Create hadoop/ozone docker images with inline build process > --- > > Key: HDDS-1495 > URL: https://issues.apache.org/jira/browse/HDDS-1495 > Project: Hadoop Distributed Data Store > Issue Type: New Feature >Reporter: Elek, Marton >Assignee: Eric Yang >Priority: Major > Attachments: HADOOP-16091.001.patch, HADOOP-16091.002.patch, > HDDS-1495.003.patch, HDDS-1495.004.patch, HDDS-1495.005.patch, > HDDS-1495.006.patch, Hadoop Docker Image inline build process.pdf > > > This is proposed by [~eyang] in > [this|https://lists.apache.org/thread.html/33ac54bdeacb4beb023ebd452464603aaffa095bd104cb43c22f484e@%3Chdfs-dev.hadoop.apache.org%3E] > mailing thread. > {quote}1, 3. There are 38 Apache projects hosting docker images on Docker hub > using Apache Organization. By browsing Apache github mirror. There are only 7 > projects using a separate repository for docker image build. Popular projects > official images are not from Apache organization, such as zookeeper, tomcat, > httpd. We may not disrupt what other Apache projects are doing, but it looks > like inline build process is widely employed by majority of projects such as > Nifi, Brooklyn, thrift, karaf, syncope and others. The situation seems a bit > chaotic for Apache as a whole. However, Hadoop community can decide what is > best for Hadoop. My preference is to remove ozone from source tree naming, if > Ozone is intended to be subproject of Hadoop for long period of time. This > enables Hadoop community to host docker images for various subproject without > having to check out several source tree to trigger a grand build. However, > inline build process seems more popular than separated process. Hence, I > highly recommend making docker build inline if possible. > {quote} > The main challenges are also discussed in the thread: > {code:java} > 3. Technically it would be possible to add the Dockerfile to the source > tree and publish the docker image together with the release by the > release manager but it's also problematic: > {code} > a) there is no easy way to stage the images for the vote > c) it couldn't be flagged as automated on dockerhub > d) It couldn't support the critical updates. > * Updating existing images (for example in case of an ssl bug, rebuild > all the existing images with exactly the same payload but updated base > image/os environment) > * Creating image for older releases (We would like to provide images, > for hadoop 2.6/2.7/2.7/2.8/2.9. Especially for doing automatic testing > with different versions). > {code:java} > {code} > The a) can be solved (as [~eyang] suggested) with using a personal docker > image during the vote and publish it to the dockerhub after the vote (in case > the permission can be set by the INFRA) > Note: based on LEGAL-270 and linked discussion both approaches (inline build > process / external build process) are compatible with the apache release. > Note: HDDS-851 and HADOOP-14898 contains more information about these > problems. -- 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
[jira] [Commented] (HDDS-1495) Create hadoop/ozone docker images with inline build process
[ https://issues.apache.org/jira/browse/HDDS-1495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16835808#comment-16835808 ] Eric Yang commented on HDDS-1495: - [~anu] I put up a design document to ensure that apache/ozone docker image is reproducible using Apache source code. The current arrangement depends on a third party source code to build apache/hadoop-runner image is unnatural and subject to GPL terms because it includes byteman. Put on my Apache member hat, the technical and political deficiency must be addressed in Ozone community source code. [~elek] k8s-dev profiles doesn't exist until a few days ago that I point out the deficiency in Hadoop binary tarball creation. Please don't try to build everything on your own. It would not be productive for the community. I also ran into a secondary issue that smoketest tries to download multi-gigabytes of third party docker images. It caused my vm development environment to run out of space (with 20 of 50GB free). I waited 45 minutes for the download, and have to spend half day to try to clean up the debris. I don't think bring in the entire Hadoop ecosystem to run test on one machine is the correct way to perform development. I would happily pay the 30 seconds initial wait time to build locally than 45 minutes download time of third party flokkr/hadoop images that we have no access to make modification. > Create hadoop/ozone docker images with inline build process > --- > > Key: HDDS-1495 > URL: https://issues.apache.org/jira/browse/HDDS-1495 > Project: Hadoop Distributed Data Store > Issue Type: New Feature >Reporter: Elek, Marton >Assignee: Eric Yang >Priority: Major > Attachments: HADOOP-16091.001.patch, HADOOP-16091.002.patch, > HDDS-1495.003.patch, HDDS-1495.004.patch, HDDS-1495.005.patch, Hadoop Docker > Image inline build process.pdf > > > This is proposed by [~eyang] in > [this|https://lists.apache.org/thread.html/33ac54bdeacb4beb023ebd452464603aaffa095bd104cb43c22f484e@%3Chdfs-dev.hadoop.apache.org%3E] > mailing thread. > {quote}1, 3. There are 38 Apache projects hosting docker images on Docker hub > using Apache Organization. By browsing Apache github mirror. There are only 7 > projects using a separate repository for docker image build. Popular projects > official images are not from Apache organization, such as zookeeper, tomcat, > httpd. We may not disrupt what other Apache projects are doing, but it looks > like inline build process is widely employed by majority of projects such as > Nifi, Brooklyn, thrift, karaf, syncope and others. The situation seems a bit > chaotic for Apache as a whole. However, Hadoop community can decide what is > best for Hadoop. My preference is to remove ozone from source tree naming, if > Ozone is intended to be subproject of Hadoop for long period of time. This > enables Hadoop community to host docker images for various subproject without > having to check out several source tree to trigger a grand build. However, > inline build process seems more popular than separated process. Hence, I > highly recommend making docker build inline if possible. > {quote} > The main challenges are also discussed in the thread: > {code:java} > 3. Technically it would be possible to add the Dockerfile to the source > tree and publish the docker image together with the release by the > release manager but it's also problematic: > {code} > a) there is no easy way to stage the images for the vote > c) it couldn't be flagged as automated on dockerhub > d) It couldn't support the critical updates. > * Updating existing images (for example in case of an ssl bug, rebuild > all the existing images with exactly the same payload but updated base > image/os environment) > * Creating image for older releases (We would like to provide images, > for hadoop 2.6/2.7/2.7/2.8/2.9. Especially for doing automatic testing > with different versions). > {code:java} > {code} > The a) can be solved (as [~eyang] suggested) with using a personal docker > image during the vote and publish it to the dockerhub after the vote (in case > the permission can be set by the INFRA) > Note: based on LEGAL-270 and linked discussion both approaches (inline build > process / external build process) are compatible with the apache release. > Note: HDDS-851 and HADOOP-14898 contains more information about these > problems. -- 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
[jira] [Commented] (HDDS-1495) Create hadoop/ozone docker images with inline build process
[ https://issues.apache.org/jira/browse/HDDS-1495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16835653#comment-16835653 ] Elek, Marton commented on HDDS-1495: BTW this patch seems to do the same as the k8s-dev profile in the hadoop-ozone/dist/pom.xml just in a *less effective* way (with a lot of local copies). It duplicates the already implemented logic which increases the maintenance cost. I like to part to use maven assembly instead of the tar bash script. I agree that there are needs to create docker images as part of the build process (Only for development not for the releases), but I think we need to do it only once which supports the requirements of kubernetes and potential test cases. I don't like to use symbolic links. We don't need symbolic links as one container shouldn't include multiple versions of ozone. (And I am not sure if this change is tested with all the smoketest/downstream use cases and kubernetes). I am not sure about the tar artifact. Seems to be an unnecessary copy. Even with using maven assemby plugin we can exclude the created tar file from the artifacts list. I think it's better to have only the apache distribution side as a canonical distribution of the tar file. > Create hadoop/ozone docker images with inline build process > --- > > Key: HDDS-1495 > URL: https://issues.apache.org/jira/browse/HDDS-1495 > Project: Hadoop Distributed Data Store > Issue Type: New Feature >Reporter: Elek, Marton >Assignee: Eric Yang >Priority: Major > Attachments: HADOOP-16091.001.patch, HADOOP-16091.002.patch, > HDDS-1495.003.patch, HDDS-1495.004.patch, HDDS-1495.005.patch > > > This is proposed by [~eyang] in > [this|https://lists.apache.org/thread.html/33ac54bdeacb4beb023ebd452464603aaffa095bd104cb43c22f484e@%3Chdfs-dev.hadoop.apache.org%3E] > mailing thread. > {quote}1, 3. There are 38 Apache projects hosting docker images on Docker hub > using Apache Organization. By browsing Apache github mirror. There are only 7 > projects using a separate repository for docker image build. Popular projects > official images are not from Apache organization, such as zookeeper, tomcat, > httpd. We may not disrupt what other Apache projects are doing, but it looks > like inline build process is widely employed by majority of projects such as > Nifi, Brooklyn, thrift, karaf, syncope and others. The situation seems a bit > chaotic for Apache as a whole. However, Hadoop community can decide what is > best for Hadoop. My preference is to remove ozone from source tree naming, if > Ozone is intended to be subproject of Hadoop for long period of time. This > enables Hadoop community to host docker images for various subproject without > having to check out several source tree to trigger a grand build. However, > inline build process seems more popular than separated process. Hence, I > highly recommend making docker build inline if possible. > {quote} > The main challenges are also discussed in the thread: > {code:java} > 3. Technically it would be possible to add the Dockerfile to the source > tree and publish the docker image together with the release by the > release manager but it's also problematic: > {code} > a) there is no easy way to stage the images for the vote > c) it couldn't be flagged as automated on dockerhub > d) It couldn't support the critical updates. > * Updating existing images (for example in case of an ssl bug, rebuild > all the existing images with exactly the same payload but updated base > image/os environment) > * Creating image for older releases (We would like to provide images, > for hadoop 2.6/2.7/2.7/2.8/2.9. Especially for doing automatic testing > with different versions). > {code:java} > {code} > The a) can be solved (as [~eyang] suggested) with using a personal docker > image during the vote and publish it to the dockerhub after the vote (in case > the permission can be set by the INFRA) > Note: based on LEGAL-270 and linked discussion both approaches (inline build > process / external build process) are compatible with the apache release. > Note: HDDS-851 and HADOOP-14898 contains more information about these > problems. -- 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
[jira] [Commented] (HDDS-1495) Create hadoop/ozone docker images with inline build process
[ https://issues.apache.org/jira/browse/HDDS-1495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16835646#comment-16835646 ] Elek, Marton commented on HDDS-1495: Sure, I am happy to create a design doc to describe the current behaviour and alternatives and the potential risk. > Create hadoop/ozone docker images with inline build process > --- > > Key: HDDS-1495 > URL: https://issues.apache.org/jira/browse/HDDS-1495 > Project: Hadoop Distributed Data Store > Issue Type: New Feature >Reporter: Elek, Marton >Assignee: Eric Yang >Priority: Major > Attachments: HADOOP-16091.001.patch, HADOOP-16091.002.patch, > HDDS-1495.003.patch, HDDS-1495.004.patch, HDDS-1495.005.patch > > > This is proposed by [~eyang] in > [this|https://lists.apache.org/thread.html/33ac54bdeacb4beb023ebd452464603aaffa095bd104cb43c22f484e@%3Chdfs-dev.hadoop.apache.org%3E] > mailing thread. > {quote}1, 3. There are 38 Apache projects hosting docker images on Docker hub > using Apache Organization. By browsing Apache github mirror. There are only 7 > projects using a separate repository for docker image build. Popular projects > official images are not from Apache organization, such as zookeeper, tomcat, > httpd. We may not disrupt what other Apache projects are doing, but it looks > like inline build process is widely employed by majority of projects such as > Nifi, Brooklyn, thrift, karaf, syncope and others. The situation seems a bit > chaotic for Apache as a whole. However, Hadoop community can decide what is > best for Hadoop. My preference is to remove ozone from source tree naming, if > Ozone is intended to be subproject of Hadoop for long period of time. This > enables Hadoop community to host docker images for various subproject without > having to check out several source tree to trigger a grand build. However, > inline build process seems more popular than separated process. Hence, I > highly recommend making docker build inline if possible. > {quote} > The main challenges are also discussed in the thread: > {code:java} > 3. Technically it would be possible to add the Dockerfile to the source > tree and publish the docker image together with the release by the > release manager but it's also problematic: > {code} > a) there is no easy way to stage the images for the vote > c) it couldn't be flagged as automated on dockerhub > d) It couldn't support the critical updates. > * Updating existing images (for example in case of an ssl bug, rebuild > all the existing images with exactly the same payload but updated base > image/os environment) > * Creating image for older releases (We would like to provide images, > for hadoop 2.6/2.7/2.7/2.8/2.9. Especially for doing automatic testing > with different versions). > {code:java} > {code} > The a) can be solved (as [~eyang] suggested) with using a personal docker > image during the vote and publish it to the dockerhub after the vote (in case > the permission can be set by the INFRA) > Note: based on LEGAL-270 and linked discussion both approaches (inline build > process / external build process) are compatible with the apache release. > Note: HDDS-851 and HADOOP-14898 contains more information about these > problems. -- 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
[jira] [Commented] (HDDS-1495) Create hadoop/ozone docker images with inline build process
[ https://issues.apache.org/jira/browse/HDDS-1495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16835352#comment-16835352 ] Anu Engineer commented on HDDS-1495: My apologies if this is clear to everyone else. Since this discussion is split between the mailing lists and the JIRA, I am very confused about what we are doing here. 1. Can someone summarize the pros and cons of this approach ? 2. or perhaps write a summary of the evil we are addressing here 3. or perhaps post a design doc explaining what we are planning to do ? Thanks > Create hadoop/ozone docker images with inline build process > --- > > Key: HDDS-1495 > URL: https://issues.apache.org/jira/browse/HDDS-1495 > Project: Hadoop Distributed Data Store > Issue Type: New Feature >Reporter: Elek, Marton >Assignee: Eric Yang >Priority: Major > Attachments: HADOOP-16091.001.patch, HADOOP-16091.002.patch, > HDDS-1495.003.patch, HDDS-1495.004.patch, HDDS-1495.005.patch > > > This is proposed by [~eyang] in > [this|https://lists.apache.org/thread.html/33ac54bdeacb4beb023ebd452464603aaffa095bd104cb43c22f484e@%3Chdfs-dev.hadoop.apache.org%3E] > mailing thread. > {quote}1, 3. There are 38 Apache projects hosting docker images on Docker hub > using Apache Organization. By browsing Apache github mirror. There are only 7 > projects using a separate repository for docker image build. Popular projects > official images are not from Apache organization, such as zookeeper, tomcat, > httpd. We may not disrupt what other Apache projects are doing, but it looks > like inline build process is widely employed by majority of projects such as > Nifi, Brooklyn, thrift, karaf, syncope and others. The situation seems a bit > chaotic for Apache as a whole. However, Hadoop community can decide what is > best for Hadoop. My preference is to remove ozone from source tree naming, if > Ozone is intended to be subproject of Hadoop for long period of time. This > enables Hadoop community to host docker images for various subproject without > having to check out several source tree to trigger a grand build. However, > inline build process seems more popular than separated process. Hence, I > highly recommend making docker build inline if possible. > {quote} > The main challenges are also discussed in the thread: > {code:java} > 3. Technically it would be possible to add the Dockerfile to the source > tree and publish the docker image together with the release by the > release manager but it's also problematic: > {code} > a) there is no easy way to stage the images for the vote > c) it couldn't be flagged as automated on dockerhub > d) It couldn't support the critical updates. > * Updating existing images (for example in case of an ssl bug, rebuild > all the existing images with exactly the same payload but updated base > image/os environment) > * Creating image for older releases (We would like to provide images, > for hadoop 2.6/2.7/2.7/2.8/2.9. Especially for doing automatic testing > with different versions). > {code:java} > {code} > The a) can be solved (as [~eyang] suggested) with using a personal docker > image during the vote and publish it to the dockerhub after the vote (in case > the permission can be set by the INFRA) > Note: based on LEGAL-270 and linked discussion both approaches (inline build > process / external build process) are compatible with the apache release. > Note: HDDS-851 and HADOOP-14898 contains more information about these > problems. -- 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
[jira] [Commented] (HDDS-1495) Create hadoop/ozone docker images with inline build process
[ https://issues.apache.org/jira/browse/HDDS-1495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16835173#comment-16835173 ] Hadoop QA commented on HDDS-1495: - | (x) *{color:red}-1 overall{color}* | \\ \\ || Vote || Subsystem || Runtime || Comment || | {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 24s{color} | {color:blue} Docker mode activated. {color} | || || || || {color:brown} Prechecks {color} || | {color:green}+1{color} | {color:green} dupname {color} | {color:green} 0m 0s{color} | {color:green} No case conflicting files found. {color} | | {color:blue}0{color} | {color:blue} shelldocs {color} | {color:blue} 0m 1s{color} | {color:blue} Shelldocs was not available. {color} | | {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s{color} | {color:green} The patch does not contain any @author tags. {color} | | {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m 0s{color} | {color:red} The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch. {color} | || || || || {color:brown} trunk Compile Tests {color} || | {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 3m 8s{color} | {color:blue} Maven dependency ordering for branch {color} | | {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 9m 26s{color} | {color:green} trunk passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m 25s{color} | {color:green} trunk passed {color} | | {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 0s{color} | {color:green} trunk passed {color} | | {color:green}+1{color} | {color:green} shadedclient {color} | {color:green} 13m 33s{color} | {color:green} branch has no errors when building and testing our client artifacts. {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m 7s{color} | {color:green} trunk passed {color} | || || || || {color:brown} Patch Compile Tests {color} || | {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 15s{color} | {color:blue} Maven dependency ordering for patch {color} | | {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 6m 36s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m 18s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} javac {color} | {color:green} 3m 18s{color} | {color:green} the patch passed {color} | | {color:red}-1{color} | {color:red} hadolint {color} | {color:red} 0m 2s{color} | {color:red} The patch generated 2 new + 0 unchanged - 0 fixed = 2 total (was 0) {color} | | {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 0s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} shellcheck {color} | {color:green} 0m 0s{color} | {color:green} There were no new shellcheck issues. {color} | | {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m 0s{color} | {color:green} The patch has no whitespace issues. {color} | | {color:green}+1{color} | {color:green} xml {color} | {color:green} 0m 6s{color} | {color:green} The patch has no ill-formed XML file. {color} | | {color:green}+1{color} | {color:green} shadedclient {color} | {color:green} 10m 1s{color} | {color:green} patch has no errors when building and testing our client artifacts. {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 56s{color} | {color:green} the patch passed {color} | || || || || {color:brown} Other Tests {color} || | {color:red}-1{color} | {color:red} unit {color} | {color:red} 2m 7s{color} | {color:red} hadoop-hdds in the patch failed. {color} | | {color:red}-1{color} | {color:red} unit {color} | {color:red} 23m 12s{color} | {color:red} hadoop-ozone in the patch failed. {color} | | {color:red}-1{color} | {color:red} asflicense {color} | {color:red} 0m 45s{color} | {color:red} The patch generated 1 ASF License warnings. {color} | | {color:black}{color} | {color:black} {color} | {color:black} 81m 54s{color} | {color:black} {color} | \\ \\ || Reason || Tests || | Failed junit tests | hadoop.ozone.client.rpc.TestOzoneClientRetriesOnException | | | hadoop.ozone.container.TestContainerReplication | \\ \\ || Subsystem || Report/Notes || | Docker | Client=17.05.0-ce Server=17.05.0-ce base: https://builds.apache.org/job/PreCommit-HDDS-Build/2678/artifact/out/Dockerfile | | JIRA Issue | HDDS-1495 | | JIRA Patch URL | https://issues.apache.org/jira/secure/attachment/12968104/HDDS-1495.005.patch | | Optional Tests | dupname asflicense compile javac javadoc mvninstall mvnsite un
[jira] [Commented] (HDDS-1495) Create hadoop/ozone docker images with inline build process
[ https://issues.apache.org/jira/browse/HDDS-1495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16835163#comment-16835163 ] Hadoop QA commented on HDDS-1495: - | (x) *{color:red}-1 overall{color}* | \\ \\ || Vote || Subsystem || Runtime || Comment || | {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 52s{color} | {color:blue} Docker mode activated. {color} | || || || || {color:brown} Prechecks {color} || | {color:green}+1{color} | {color:green} dupname {color} | {color:green} 0m 0s{color} | {color:green} No case conflicting files found. {color} | | {color:blue}0{color} | {color:blue} shelldocs {color} | {color:blue} 0m 0s{color} | {color:blue} Shelldocs was not available. {color} | | {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s{color} | {color:green} The patch does not contain any @author tags. {color} | | {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m 0s{color} | {color:red} The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch. {color} | || || || || {color:brown} trunk Compile Tests {color} || | {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 3m 12s{color} | {color:blue} Maven dependency ordering for branch {color} | | {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 9m 28s{color} | {color:green} trunk passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m 31s{color} | {color:green} trunk passed {color} | | {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 0s{color} | {color:green} trunk passed {color} | | {color:green}+1{color} | {color:green} shadedclient {color} | {color:green} 14m 39s{color} | {color:green} branch has no errors when building and testing our client artifacts. {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 3m 13s{color} | {color:green} trunk passed {color} | || || || || {color:brown} Patch Compile Tests {color} || | {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 17s{color} | {color:blue} Maven dependency ordering for patch {color} | | {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 6m 34s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m 25s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} javac {color} | {color:green} 3m 25s{color} | {color:green} the patch passed {color} | | {color:red}-1{color} | {color:red} hadolint {color} | {color:red} 0m 1s{color} | {color:red} The patch generated 1 new + 0 unchanged - 0 fixed = 1 total (was 0) {color} | | {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 0s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} shellcheck {color} | {color:green} 0m 1s{color} | {color:green} There were no new shellcheck issues. {color} | | {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m 0s{color} | {color:green} The patch has no whitespace issues. {color} | | {color:green}+1{color} | {color:green} xml {color} | {color:green} 0m 8s{color} | {color:green} The patch has no ill-formed XML file. {color} | | {color:green}+1{color} | {color:green} shadedclient {color} | {color:green} 11m 7s{color} | {color:green} patch has no errors when building and testing our client artifacts. {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m 4s{color} | {color:green} the patch passed {color} | || || || || {color:brown} Other Tests {color} || | {color:red}-1{color} | {color:red} unit {color} | {color:red} 2m 42s{color} | {color:red} hadoop-hdds in the patch failed. {color} | | {color:red}-1{color} | {color:red} unit {color} | {color:red} 24m 17s{color} | {color:red} hadoop-ozone in the patch failed. {color} | | {color:red}-1{color} | {color:red} asflicense {color} | {color:red} 0m 44s{color} | {color:red} The patch generated 1 ASF License warnings. {color} | | {color:black}{color} | {color:black} {color} | {color:black} 87m 46s{color} | {color:black} {color} | \\ \\ || Reason || Tests || | Failed junit tests | hadoop.hdds.scm.pipeline.TestRatisPipelineProvider | | | hadoop.ozone.client.rpc.TestBlockOutputStreamWithFailures | \\ \\ || Subsystem || Report/Notes || | Docker | Client=17.05.0-ce Server=17.05.0-ce base: https://builds.apache.org/job/PreCommit-HDDS-Build/2677/artifact/out/Dockerfile | | JIRA Issue | HDDS-1495 | | JIRA Patch URL | https://issues.apache.org/jira/secure/attachment/12968103/HDDS-1495.004.patch | | Optional Tests | dupname asflicense compile javac javadoc mvninstall mvnsite
[jira] [Commented] (HDDS-1495) Create hadoop/ozone docker images with inline build process
[ https://issues.apache.org/jira/browse/HDDS-1495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16835129#comment-16835129 ] Eric Yang commented on HDDS-1495: - Patch 005 added a missing Dockerfile for development environment. > Create hadoop/ozone docker images with inline build process > --- > > Key: HDDS-1495 > URL: https://issues.apache.org/jira/browse/HDDS-1495 > Project: Hadoop Distributed Data Store > Issue Type: New Feature >Reporter: Elek, Marton >Assignee: Eric Yang >Priority: Major > Attachments: HADOOP-16091.001.patch, HADOOP-16091.002.patch, > HDDS-1495.003.patch, HDDS-1495.004.patch, HDDS-1495.005.patch > > > This is proposed by [~eyang] in > [this|https://lists.apache.org/thread.html/33ac54bdeacb4beb023ebd452464603aaffa095bd104cb43c22f484e@%3Chdfs-dev.hadoop.apache.org%3E] > mailing thread. > {quote}1, 3. There are 38 Apache projects hosting docker images on Docker hub > using Apache Organization. By browsing Apache github mirror. There are only 7 > projects using a separate repository for docker image build. Popular projects > official images are not from Apache organization, such as zookeeper, tomcat, > httpd. We may not disrupt what other Apache projects are doing, but it looks > like inline build process is widely employed by majority of projects such as > Nifi, Brooklyn, thrift, karaf, syncope and others. The situation seems a bit > chaotic for Apache as a whole. However, Hadoop community can decide what is > best for Hadoop. My preference is to remove ozone from source tree naming, if > Ozone is intended to be subproject of Hadoop for long period of time. This > enables Hadoop community to host docker images for various subproject without > having to check out several source tree to trigger a grand build. However, > inline build process seems more popular than separated process. Hence, I > highly recommend making docker build inline if possible. > {quote} > The main challenges are also discussed in the thread: > {code:java} > 3. Technically it would be possible to add the Dockerfile to the source > tree and publish the docker image together with the release by the > release manager but it's also problematic: > {code} > a) there is no easy way to stage the images for the vote > c) it couldn't be flagged as automated on dockerhub > d) It couldn't support the critical updates. > * Updating existing images (for example in case of an ssl bug, rebuild > all the existing images with exactly the same payload but updated base > image/os environment) > * Creating image for older releases (We would like to provide images, > for hadoop 2.6/2.7/2.7/2.8/2.9. Especially for doing automatic testing > with different versions). > {code:java} > {code} > The a) can be solved (as [~eyang] suggested) with using a personal docker > image during the vote and publish it to the dockerhub after the vote (in case > the permission can be set by the INFRA) > Note: based on LEGAL-270 and linked discussion both approaches (inline build > process / external build process) are compatible with the apache release. > Note: HDDS-851 and HADOOP-14898 contains more information about these > problems. -- 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
[jira] [Commented] (HDDS-1495) Create hadoop/ozone docker images with inline build process
[ https://issues.apache.org/jira/browse/HDDS-1495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16835107#comment-16835107 ] Eric Yang commented on HDDS-1495: - The unit tests failures are not related to this patch. Apache license are not related to this patch, but tracked in YARN-9513. Hadolint error are false positive. The value of ${project.version} is substituted by maven resource plugin during build. Patch 004 added hadolint ignore to suppress the errors. > Create hadoop/ozone docker images with inline build process > --- > > Key: HDDS-1495 > URL: https://issues.apache.org/jira/browse/HDDS-1495 > Project: Hadoop Distributed Data Store > Issue Type: New Feature >Reporter: Elek, Marton >Assignee: Eric Yang >Priority: Major > Attachments: HADOOP-16091.001.patch, HADOOP-16091.002.patch, > HDDS-1495.003.patch, HDDS-1495.004.patch > > > This is proposed by [~eyang] in > [this|https://lists.apache.org/thread.html/33ac54bdeacb4beb023ebd452464603aaffa095bd104cb43c22f484e@%3Chdfs-dev.hadoop.apache.org%3E] > mailing thread. > {quote}1, 3. There are 38 Apache projects hosting docker images on Docker hub > using Apache Organization. By browsing Apache github mirror. There are only 7 > projects using a separate repository for docker image build. Popular projects > official images are not from Apache organization, such as zookeeper, tomcat, > httpd. We may not disrupt what other Apache projects are doing, but it looks > like inline build process is widely employed by majority of projects such as > Nifi, Brooklyn, thrift, karaf, syncope and others. The situation seems a bit > chaotic for Apache as a whole. However, Hadoop community can decide what is > best for Hadoop. My preference is to remove ozone from source tree naming, if > Ozone is intended to be subproject of Hadoop for long period of time. This > enables Hadoop community to host docker images for various subproject without > having to check out several source tree to trigger a grand build. However, > inline build process seems more popular than separated process. Hence, I > highly recommend making docker build inline if possible. > {quote} > The main challenges are also discussed in the thread: > {code:java} > 3. Technically it would be possible to add the Dockerfile to the source > tree and publish the docker image together with the release by the > release manager but it's also problematic: > {code} > a) there is no easy way to stage the images for the vote > c) it couldn't be flagged as automated on dockerhub > d) It couldn't support the critical updates. > * Updating existing images (for example in case of an ssl bug, rebuild > all the existing images with exactly the same payload but updated base > image/os environment) > * Creating image for older releases (We would like to provide images, > for hadoop 2.6/2.7/2.7/2.8/2.9. Especially for doing automatic testing > with different versions). > {code:java} > {code} > The a) can be solved (as [~eyang] suggested) with using a personal docker > image during the vote and publish it to the dockerhub after the vote (in case > the permission can be set by the INFRA) > Note: based on LEGAL-270 and linked discussion both approaches (inline build > process / external build process) are compatible with the apache release. > Note: HDDS-851 and HADOOP-14898 contains more information about these > problems. -- 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
[jira] [Commented] (HDDS-1495) Create hadoop/ozone docker images with inline build process
[ https://issues.apache.org/jira/browse/HDDS-1495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16835053#comment-16835053 ] Hadoop QA commented on HDDS-1495: - | (x) *{color:red}-1 overall{color}* | \\ \\ || Vote || Subsystem || Runtime || Comment || | {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 33s{color} | {color:blue} Docker mode activated. {color} | || || || || {color:brown} Prechecks {color} || | {color:green}+1{color} | {color:green} dupname {color} | {color:green} 0m 0s{color} | {color:green} No case conflicting files found. {color} | | {color:blue}0{color} | {color:blue} shelldocs {color} | {color:blue} 0m 1s{color} | {color:blue} Shelldocs was not available. {color} | | {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s{color} | {color:green} The patch does not contain any @author tags. {color} | | {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m 0s{color} | {color:red} The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch. {color} | || || || || {color:brown} trunk Compile Tests {color} || | {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 42s{color} | {color:blue} Maven dependency ordering for branch {color} | | {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 7m 13s{color} | {color:green} trunk passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m 26s{color} | {color:green} trunk passed {color} | | {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 0s{color} | {color:green} trunk passed {color} | | {color:green}+1{color} | {color:green} shadedclient {color} | {color:green} 13m 55s{color} | {color:green} branch has no errors when building and testing our client artifacts. {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m 9s{color} | {color:green} trunk passed {color} | || || || || {color:brown} Patch Compile Tests {color} || | {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 18s{color} | {color:blue} Maven dependency ordering for patch {color} | | {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 6m 46s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m 30s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} javac {color} | {color:green} 3m 30s{color} | {color:green} the patch passed {color} | | {color:red}-1{color} | {color:red} hadolint {color} | {color:red} 0m 1s{color} | {color:red} The patch generated 2 new + 0 unchanged - 0 fixed = 2 total (was 0) {color} | | {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 0s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} shellcheck {color} | {color:green} 0m 0s{color} | {color:green} There were no new shellcheck issues. {color} | | {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m 0s{color} | {color:green} The patch has no whitespace issues. {color} | | {color:green}+1{color} | {color:green} xml {color} | {color:green} 0m 6s{color} | {color:green} The patch has no ill-formed XML file. {color} | | {color:green}+1{color} | {color:green} shadedclient {color} | {color:green} 12m 6s{color} | {color:green} patch has no errors when building and testing our client artifacts. {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m 9s{color} | {color:green} the patch passed {color} | || || || || {color:brown} Other Tests {color} || | {color:red}-1{color} | {color:red} unit {color} | {color:red} 2m 36s{color} | {color:red} hadoop-hdds in the patch failed. {color} | | {color:red}-1{color} | {color:red} unit {color} | {color:red} 18m 5s{color} | {color:red} hadoop-ozone in the patch failed. {color} | | {color:red}-1{color} | {color:red} asflicense {color} | {color:red} 0m 40s{color} | {color:red} The patch generated 1 ASF License warnings. {color} | | {color:black}{color} | {color:black} {color} | {color:black} 75m 53s{color} | {color:black} {color} | \\ \\ || Reason || Tests || | Failed junit tests | hadoop.ozone.client.rpc.TestOzoneClientRetriesOnException | | | hadoop.ozone.scm.TestXceiverClientMetrics | | | hadoop.hdds.scm.pipeline.TestRatisPipelineProvider | \\ \\ || Subsystem || Report/Notes || | Docker | Client=17.05.0-ce Server=17.05.0-ce base: https://builds.apache.org/job/PreCommit-HDDS-Build/2676/artifact/out/Dockerfile | | JIRA Issue | HDDS-1495 | | JIRA Patch URL | https://issues.apache.org/jira/secure/attachment/12968084/HDDS-1495.003.patch | | Optional Tests | dupname as
[jira] [Commented] (HDDS-1495) Create hadoop/ozone docker images with inline build process
[ https://issues.apache.org/jira/browse/HDDS-1495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16834993#comment-16834993 ] Eric Yang commented on HDDS-1495: - Patch 003 fixed hadolint warning, and added ability to create dev docker image as well as release docker image. [~elek] The dev image is a empty container image based on centos:7, and release image will include ozone binaries in /opt/apache/ozone. Javadoc and unit tests errors in precommit test build for patch 002 is not related to the patch. Dev image can be built with: {code}mvn clean [package|install]{code} Release image can be built with: {code}mvn clean [package|install] -Pdist{code} Ozone has a separated parent pom and build flow from Hadoop mainline build, hence, the inline build is no op for non-Ozone developer. > Create hadoop/ozone docker images with inline build process > --- > > Key: HDDS-1495 > URL: https://issues.apache.org/jira/browse/HDDS-1495 > Project: Hadoop Distributed Data Store > Issue Type: New Feature >Reporter: Elek, Marton >Assignee: Eric Yang >Priority: Major > Attachments: HADOOP-16091.001.patch, HADOOP-16091.002.patch, > HDDS-1495.003.patch > > > This is proposed by [~eyang] in > [this|https://lists.apache.org/thread.html/33ac54bdeacb4beb023ebd452464603aaffa095bd104cb43c22f484e@%3Chdfs-dev.hadoop.apache.org%3E] > mailing thread. > {quote}1, 3. There are 38 Apache projects hosting docker images on Docker hub > using Apache Organization. By browsing Apache github mirror. There are only 7 > projects using a separate repository for docker image build. Popular projects > official images are not from Apache organization, such as zookeeper, tomcat, > httpd. We may not disrupt what other Apache projects are doing, but it looks > like inline build process is widely employed by majority of projects such as > Nifi, Brooklyn, thrift, karaf, syncope and others. The situation seems a bit > chaotic for Apache as a whole. However, Hadoop community can decide what is > best for Hadoop. My preference is to remove ozone from source tree naming, if > Ozone is intended to be subproject of Hadoop for long period of time. This > enables Hadoop community to host docker images for various subproject without > having to check out several source tree to trigger a grand build. However, > inline build process seems more popular than separated process. Hence, I > highly recommend making docker build inline if possible. > {quote} > The main challenges are also discussed in the thread: > {code:java} > 3. Technically it would be possible to add the Dockerfile to the source > tree and publish the docker image together with the release by the > release manager but it's also problematic: > {code} > a) there is no easy way to stage the images for the vote > c) it couldn't be flagged as automated on dockerhub > d) It couldn't support the critical updates. > * Updating existing images (for example in case of an ssl bug, rebuild > all the existing images with exactly the same payload but updated base > image/os environment) > * Creating image for older releases (We would like to provide images, > for hadoop 2.6/2.7/2.7/2.8/2.9. Especially for doing automatic testing > with different versions). > {code:java} > {code} > The a) can be solved (as [~eyang] suggested) with using a personal docker > image during the vote and publish it to the dockerhub after the vote (in case > the permission can be set by the INFRA) > Note: based on LEGAL-270 and linked discussion both approaches (inline build > process / external build process) are compatible with the apache release. > Note: HDDS-851 and HADOOP-14898 contains more information about these > problems. -- 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
[jira] [Commented] (HDDS-1495) Create hadoop/ozone docker images with inline build process
[ https://issues.apache.org/jira/browse/HDDS-1495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16834223#comment-16834223 ] Hadoop QA commented on HDDS-1495: - | (x) *{color:red}-1 overall{color}* | \\ \\ || Vote || Subsystem || Runtime || Comment || | {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 22s{color} | {color:blue} Docker mode activated. {color} | || || || || {color:brown} Prechecks {color} || | {color:green}+1{color} | {color:green} dupname {color} | {color:green} 0m 0s{color} | {color:green} No case conflicting files found. {color} | | {color:blue}0{color} | {color:blue} shelldocs {color} | {color:blue} 0m 1s{color} | {color:blue} Shelldocs was not available. {color} | | {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s{color} | {color:green} The patch does not contain any @author tags. {color} | | {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m 0s{color} | {color:red} The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch. {color} | || || || || {color:brown} trunk Compile Tests {color} || | {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 41s{color} | {color:blue} Maven dependency ordering for branch {color} | | {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 6m 54s{color} | {color:green} trunk passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m 33s{color} | {color:green} trunk passed {color} | | {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 0s{color} | {color:green} trunk passed {color} | | {color:green}+1{color} | {color:green} shadedclient {color} | {color:green} 13m 44s{color} | {color:green} branch has no errors when building and testing our client artifacts. {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m 31s{color} | {color:green} trunk passed {color} | || || || || {color:brown} Patch Compile Tests {color} || | {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 17s{color} | {color:blue} Maven dependency ordering for patch {color} | | {color:red}-1{color} | {color:red} mvninstall {color} | {color:red} 5m 40s{color} | {color:red} hadoop-ozone in the patch failed. {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 4m 17s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} javac {color} | {color:green} 4m 17s{color} | {color:green} the patch passed {color} | | {color:red}-1{color} | {color:red} hadolint {color} | {color:red} 0m 1s{color} | {color:red} The patch generated 1 new + 0 unchanged - 0 fixed = 1 total (was 0) {color} | | {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 0s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} shellcheck {color} | {color:green} 0m 0s{color} | {color:green} There were no new shellcheck issues. {color} | | {color:red}-1{color} | {color:red} whitespace {color} | {color:red} 0m 0s{color} | {color:red} The patch has 1 line(s) that end in whitespace. Use git apply --whitespace=fix <>. Refer https://git-scm.com/docs/git-apply {color} | | {color:green}+1{color} | {color:green} xml {color} | {color:green} 0m 7s{color} | {color:green} The patch has no ill-formed XML file. {color} | | {color:green}+1{color} | {color:green} shadedclient {color} | {color:green} 12m 56s{color} | {color:green} patch has no errors when building and testing our client artifacts. {color} | | {color:red}-1{color} | {color:red} javadoc {color} | {color:red} 1m 20s{color} | {color:red} hadoop-ozone in the patch failed. {color} | || || || || {color:brown} Other Tests {color} || | {color:red}-1{color} | {color:red} unit {color} | {color:red} 2m 53s{color} | {color:red} hadoop-hdds in the patch failed. {color} | | {color:red}-1{color} | {color:red} unit {color} | {color:red} 18m 48s{color} | {color:red} hadoop-ozone in the patch failed. {color} | | {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m 44s{color} | {color:green} The patch does not generate ASF License warnings. {color} | | {color:black}{color} | {color:black} {color} | {color:black} 79m 56s{color} | {color:black} {color} | \\ \\ || Reason || Tests || | Failed junit tests | hadoop.ozone.client.rpc.TestCloseContainerHandlingByClient | | | hadoop.ozone.om.TestScmSafeMode | \\ \\ || Subsystem || Report/Notes || | Docker | Client=17.05.0-ce Server=17.05.0-ce base: https://builds.apache.org/job/PreCommit-HDDS-Build/2673/artifact/out/Dockerfile | | JIRA Issue | HDDS-1495 | | JIRA Patch URL | https://issues.apache.org/jira/secure/attachment/12967808/HADO