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, 31 May 2019 17:50:00 GMT

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

Eric Yang commented on HADOOP-16092:
------------------------------------

[~elek] {quote}I am afraid that is not quite true. It's heavily used by Ozone which is a subproject
of Hadoop.{quote}

This is branding fasciation.  There is no code dependency in Hadoop common, HDFS, or YARN
that uses Hadoop-runner project.

{quote}I am not sure If I understand this well. No uid has been changed in hadoop-runner recently.
Only the directory of configs/logs are changed and I think it's still backward compatible
with 0.3.0/0.4.0.{quote}

Hadoop-runner:latest image is backward compatible for now, but it has privilege escalation
security issue.  If any data directory is mounted to host OS for developer to debug what is
going on in the docker container, it triggers the security bug.  Data would be written as
uid:1000, which could be someone else on host OS.  

Hadoop-runner:latest image will not be backward compatible when this security bug is fixed.
 This means user experience for Ozone 0.4.0 release is subject to change over time.  This
does not fit [Apache release policy|http://www.apache.org/legal/release-policy.html#compiled-packages],
which stated:

{quote}As a convenience to users that might not have the appropriate tools to build a compiled
version of the source, binary/bytecode packages MAY be distributed alongside official Apache
releases. In all such cases, the binary/bytecode package MUST have the same version number
as the source release and MUST only add binary/bytecode files that are the result of compiling
that version of the source code release and its dependencies.
{quote}

Convenience binary for hadoop-runner:latest does not have the same version number for Ozone
0.4.0 which is not compliant to Apache release policy.  Developer should not have to go through
rabbit holes to find Ozone 0.4.0 release is comprised of source code in 4 different branches
in Hadoop source code, and only one of the branch was voted for release.  The rest was not
voted.  Please reconsider to make the development and release process matching Apache release
policy.
 

> 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
>            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
(v7.6.3#76005)

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


Mime
View raw message