Issue Details (XML | Word | Printable)

Key: HDFS-752
Type: New Feature New Feature
Status: Open Open
Priority: Major Major
Assignee: Suresh Srinivas
Reporter: Suresh Srinivas
Votes: 0
Watchers: 6
Operations

If you were logged in you would be able to see more operations.
Hadoop HDFS

Add interface classification stable & scope to HDFS

Created: 03/Nov/09 11:39 PM   Updated: 03/Nov/09 11:44 PM
Return to search
Component/s: None
Affects Version/s: 0.21.0, 0.22.0
Fix Version/s: 0.21.0, 0.22.0

Time Tracking:
Not Specified

File Attachments:
  Size
Text File Licensed for inclusion in ASF works hdfs.interface.txt 2009-11-03 11:44 PM Suresh Srinivas 10 kB
Issue Links:
Reference
 


 Description  « Hide
This jira addresses adding interface classification for the classes in hadoop hdfs, based on the mechanism described in Hadoop-5073.

 All   Comments   Work Log   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Suresh Srinivas added a comment - 03/Nov/09 11:44 PM
Attached file has details of interface labeling.

How InterfaceAudience classification was done:

  1. None of the current classes in HDFS are expected to directly used by Application or MapReduce. Hence all the classes are marked as private.

How InterfaceStability classification was done:

  1. Classes used for inter node communication, FSImage and edits log are marked as stable to ensure backward/forward compatibility between the nodes running different releases.
  2. All the super classes of Stable or Evolving classes, the return values and the parameters in public methods are recursively marked Stable/Evolving.

How labeling will be done:

  1. Classes that are private and unstable are not labelled.
  2. Classes that are marked as stable will need backward/forward compatibility tests.

Open issues:

  1. A separate jira is needed to track writing tests for backward/forward compatility of Stable classes.
  2. Labeling clarifies where a class can be used and the stability expectation. But there is no tool available to a user to check if class is being misused. Alternatively instead of tool, we could have separate jars (a jar for application, a jar for internal projects and a jar with all the classes?). Applications use a jar that includes only classes relevant to it, avoiding misuse of classes. tool or separate jars. How this will be resolved will be considered in a separate jira.