[
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.
{quote}
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.
{quote}
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
\[Unstable\](./InterfaceClassification.html#Unstable).
{quote}
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.
{quote}
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,
> InterfaceClassification.pdf
>
>
> 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
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
