hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Yang (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HADOOP-16092) Move the source of hadoop/ozone containers to the same repository
Date Fri, 17 May 2019 23:12:00 GMT

    [ https://issues.apache.org/jira/browse/HADOOP-16092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16842799#comment-16842799

Eric Yang commented on HADOOP-16092:

{quote}The release process of older versions (eg. create hadoop 2.7.3 image is not addressed).{quote}

I keep getting stuck on this point.  Can you elaborate on creation of Hadoop 2.7.3 image?
 Do you mean creating an Docker image for Hadoop 2.7.3 release?  Official Hadoop 2.7.3 release,
that ship has sailed.  There is no re-release of a shipped version.  The unreleased version
like 2.7.8 can be generated from a maven docker submodule via Hadoop trunk backport.  Or do
you mean to create a Ozone Image that works with Hadoop 2.7.3?  If it's the later, then bind
mount Hadoop directory into Ozone container.  This can be done for fun, but it is not production
grade because there is no upper layer to manage orchestration and distribution of Ozone image
on Hadoop 2.7.3 cluster.

{quote}The option to update the underlying operating system of the containers are not addressed.{quote}

In Dockerfile, we can manage OS package version using apt-get install docker-ce=5:18.09.6~3-0~ubuntu-xenial.
 The Dockerfile is version controlled in Hadoop source code.  This means we can have accurate
package version dependency to keep image up to date.  If a company wants to use a different
version of curl, they can simply change Dockerfile to their specific version for their internal
builds.  They can also perform "yum update" inside the running container, if they desire to
hot patch a running container.  If I am not addressing your concern the right way, please
elaborate on the questions.

{quote}It worked well. You can test it:{quote}

Reaction to my complain does not mean the current arrangement is working.  I shouldn't have
to find out that it was not tag and released before release announcement (May 10th) went out.

{code}$ docker image inspect apache/ozone:0.4.0
        "Id": "sha256:2bb4cc4480eff377a6305f61ec9ca340904f95ff16c13d825599ad04fb709ede",
        "RepoTags": [
        "RepoDigests": [
        "Parent": "",
        "Comment": "",
        "Created": "2019-05-15T13:27:20.926054735Z",

> Move the source of hadoop/ozone containers to the same repository
> -----------------------------------------------------------------
>                 Key: HADOOP-16092
>                 URL: https://issues.apache.org/jira/browse/HADOOP-16092
>             Project: Hadoop Common
>          Issue Type: Improvement
>            Reporter: Elek, Marton
>            Assignee: Gabor Bota
>            Priority: Major
> This is proposed by [~eyang] in [this|https://lists.apache.org/thread.html/33ac54bdeacb4beb023ebd452464603aaffa095bd104cb43c22f484e@%3Chdfs-dev.hadoop.apache.org%3E]
mailing thread.
> bq. 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
> As of now the source of  hadoop docker images are stored in the hadoop git repository
(docker-* branches) for hadoop and in hadoop-docker-ozone git repository for ozone (all branches).
> As it's discussed in HDDS-851 the biggest challenge to solve here is the mapping between
git branches and dockerhub tags. It's not possible to use the captured part of a github branch.
> For example it's not possible to define a rule to build all the ozone-(.*) branches and
use a tag $1 for it. Without this support we need to create a new mapping for all the releases
manually (with the help of the INFRA).
> Note: HADOOP-16091 can solve this problem as it doesn't require branch mapping any more.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail: common-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-issues-help@hadoop.apache.org

View raw message