[
https://issues.apache.org/jira/browse/HDDS-1521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16838807#comment-16838807
]
Eric Yang edited comment on HDDS-1521 at 5/13/19 6:52 PM:
----------------------------------------------------------
Filesystem Hierarchy Standard is also used by dynamic linked libraries to
determine what libraries to cache by ldconfig. Native libraries are
recommended to be placed in /lib, /usr/lib, or /usr/local/lib, or one of the
path specified in ld.so.conf. Modern linux uses
/etc/ld.so.conf.d/[program].conf to define path that needs to be cached. When
Ozone is ready to build native client library, it would be good idea to
organize the structure that is compatible with most Unix systems.
# Native libraries can be exposed as "lib" directory structure,
# Jar files in share directory for classpath sharing, and "ozone classpath" to
return path of Ozone classpath.
# Config files are placed in etc/ozone directory to avoid conflict with Hadoop
config files.
This gives system admin a way to extract ozone tarball in
/usr/local/ozone-[version] and tar xvf ozone-[version].tar.gz --strip 1 -C /usr
to make docker container look almost seamlessly integrated into /usr structure.
# The end result of the organization is allowing dynamic link cache to work as
intended.
# binary path can be referenced without additional setup in PATH variables for
the seamless integration scenario.
# log files can be redirect to a different disk than executable binaries to
improve some IO performance.
# ozone dependent jar files can be referenced from a standalone location.
# man page can be found at expected location.
I think doing some of those can help third party that tries to integrate with
Ozone client to have a easier time to call Ozone APIs.
was (Author: eyang):
Filesystem Hierarchy Standard is also used by dynamic linked libraries to
determine what libraries to cache by ldconfig. Native libraries are
recommended to be placed in /lib, /usr/lib, or /usr/local/lib, or one of the
path specified in ld.so.conf. Modern linux uses
/etc/ld.so.conf.d/[program].conf to define path that needs to be cached. When
Ozone is ready to build native client library, it would be good idea to
organize the structure that is compatible with most Unix systems.
# Native libraries can be exposed as "lib" directory structure,
# Jar files in share directory for classpath sharing, and "ozone classpath" to
return path of Ozone classpath.
# Config files are placed in etc/ozone directory to avoid conflict with Hadoop
config files.
This gives system admin a way to extract ozone tarball in
/usr/local/ozone-[version] and tar -xvf ozone-[version].tar.gz --strip 1 -C
/usr to make docker container look almost seamlessly integrated into /usr
structure.
# The end result of the organization is allowing dynamic link cache to work as
intended.
# binary path can be referenced without additional setup in PATH variables for
the seamless integration scenario.
# log files can be redirect to a different disk than executable binaries to
improve some IO performance.
# ozone dependent jar files can be referenced from a standalone location.
# man page can be found at expected location.
I think doing some of those can help third party that tries to integrate with
Ozone client to have a easier time to call Ozone APIs.
> Use more natural directory structure for ozone
> ----------------------------------------------
>
> Key: HDDS-1521
> URL: https://issues.apache.org/jira/browse/HDDS-1521
> Project: Hadoop Distributed Data Store
> Issue Type: Improvement
> Reporter: Elek, Marton
> Priority: Major
>
> The conversation of the current ozone directory structure is started here:
> HDDS-1458
> By [~eyang]
> {quote}The proposal is to generate test artifacts in
> ozone-[version]/share/ozone/tests for fault injection test framework in
> release binary tarball.
> {quote}
> By [~anu]:
> {quote}Let us drop the share and make it tests/blockade, and tests/smoketests
> etc. That way, all tests that we ship can be found easily. Otherwise I am +1
> on this change.
> {quote}
> By [~elek]
> {quote}I agree with Anu. I think It's time to revisit the current structure
> of ozone distribution tar files. The original structure is inherited from
> HADOOP-6255 which is defined for a project which includes multiple subproject
> (hadoop, yarn,...) and should support the creation of different RPM package
> from the same tar. I think for ozone we can improve the usability with
> reorganizing the dirs to a better structure.
> But I am fine to do it in a separated jira and keep it in the share/test
> until that to make progress.
> {quote}
> By [~eyang]
> {quote}The reason for HADOOP-6255 was more than just RPM packaging. The
> motivation behind the reorganization was to make a directory structure that
> can work as standalone tarball as well as follow the general guideline for
> [Filesystem Hierarchy
> Standard|https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard]. This
> was proposed because a several people saw the need to make the structure more
> unix like for sharing dependencies for larger eco-system to work. This is the
> reason that Hadoop HDFS, Mapreduce have good integration between projects to
> reduce shell script bootstrap cost. Earlier version of YARN did not follow
> the conventional wisdom and it was hard to integrate with rest of Hadoop,
> YARN community struggled on classpath issue for at least 2+ years and the
> time to hype YARN framework had already passed. Given there is a high
> probability that we want to make ozone as universal as possible for
> applications to integrate with us. It given us more incentive to make the
> structure as flexible as possible. This is only a advice from my own past
> scaring. There are no perfect solution, but the conventional wisdom usually
> have endure test of time and save energy.
> {quote}
> I propose the following method:
> # Start an independent discussion, let's don't mix this question with
> HDDS-1458 and don't block it.
> # Let's propose a more use friendly directory structure first
> # Let's ask [~eyang] to defined _technical_ problems regarding to the
> proposal.
> There are two different view here:
> # Technical limitations which were mentioned earlier
> # Theoretical questions (do we need to have the same structure for core
> Hadoop and Ozone packages)
> I propose to start the discussion with the first one.
--
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
