hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Kanter (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HADOOP-13714) Tighten up our compatibility guidelines for Hadoop 3
Date Thu, 14 Sep 2017 21:47:00 GMT

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

Robert Kanter commented on HADOOP-13714:

Thanks for putting all this work into writing all this [~templedf].  Here's some feedback/questions:
# {quote}
In addition to compatibility of the protocols themselves, maintaining
cross-version communications requires that the transports supported also be
stable. The most likely source of transport changes stems from secure
transports, such as SSL. Upgrading a service from SSLv2 to SSLv3 may break
existing SSLv2 clients. Supported transports MUST continue to be supported
across all minor releases within a major version.
What should we do then if a severe security bug is found with some version of SSL?  I don't
think we'd want to keep that version of SSL, right?  Perhaps some sort of exception should
be mentioned for security issues?  
# {quote}
Some user applications built against Hadoop might all Hadoop JAR files
(including Hadoop's library dependencies) to the application's classpath.
I think a word is missing somewhere in here: "... might \[add\] all ..."
# {quote}
Adding new dependencies or updating the versions of existing dependencies may
interfere with those in applications' classpaths and hence their correct
operation. Users are therefore discouraged from adopting this practice.

Hadoop dependencies SHALL be considered
\[Private\](./InterfaceClassification.html#Private) and
While this is great for us, I'm not sure we can do that until we have third party dependencies
shaded at least in the clients.  For example, if Hive includes yarn-client to talk to Yarn,
yarn-client will pull in some transitive dependencies.  Do we expect users and downstream
projects to always exclude these?  And if they do, yarn-client still depends on those dependencies,
so it probably will fail without them.  Perhaps we need to differentiate between client and
server parts of Hadoop?  For instance, client dependencies could be Public Evolving but server
dependencies could be Private Unstable.
# {quote}
A Stable
interface is expected to not change incompatibly within a major release and so
if a safe development target.
Typo: "... and so i\[s\] a safe ..."
# This may seem like a silly question, but both {{InterfaceAudience}} and {{InterfaceStability}}
are currently marked as Public Evolving.  Should we make them Public Stable?  We're not going
to change these incompatibly within a major release.

> Tighten up our compatibility guidelines for Hadoop 3
> ----------------------------------------------------
>                 Key: HADOOP-13714
>                 URL: https://issues.apache.org/jira/browse/HADOOP-13714
>             Project: Hadoop Common
>          Issue Type: Improvement
>          Components: documentation
>    Affects Versions: 2.7.3
>            Reporter: Karthik Kambatla
>            Assignee: Daniel Templeton
>            Priority: Blocker
>         Attachments: Compatibility.pdf, HADOOP-13714.001.patch, HADOOP-13714.002.patch,
HADOOP-13714.003.patch, HADOOP-13714.004.patch, HADOOP-13714.005.patch, HADOOP-13714.WIP-001.patch,
> Our current compatibility guidelines are incomplete and loose. For many categories, we
do not have a policy. It would be nice to actually define those policies so our users know
what to expect and the developers know what releases to target their changes. 

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