[
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-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org
