Hadoop HDFS
  1. Hadoop HDFS
  2. HDFS-2576

Namenode should have a favored nodes hint to enable clients to have control over block placement.

    Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.1.0-beta
    • Component/s: hdfs-client, namenode
    • Labels:
      None
    • Hadoop Flags:
      Reviewed

      Description

      Sometimes Clients like HBase are required to dynamically compute the datanodes it wishes to place the blocks for a file for higher level of locality. For this purpose there is a need of a way to give the Namenode a hint in terms of a favoredNodes parameter about the locations where the client wants to put each block. The proposed solution is a favored nodes parameter in the addBlock() method and in the create() file method to enable the clients to give the hints to the NameNode about the locations of each replica of the block. Note that this would be just a hint and finally the NameNode would look at disk usage, datanode load etc. and decide whether it can respect the hints or not.

      1. hdfs-2576-trunk-8.3.patch
        44 kB
        Devaraj Das
      2. hdfs-2576-trunk-8.2.patch
        44 kB
        Devaraj Das
      3. hdfs-2576-trunk-8.1.patch
        43 kB
        Devaraj Das
      4. hdfs-2576-trunk-8.patch
        43 kB
        Devaraj Das
      5. hdfs-2576-trunk-7.1.patch
        32 kB
        Devaraj Das
      6. hdfs-2576-trunk-7.patch
        32 kB
        Devaraj Das
      7. hdfs-2576-trunk-2.patch
        28 kB
        Devaraj Das
      8. hdfs-2576-trunk-1.patch
        25 kB
        Devaraj Das
      9. hdfs-2576-1.txt
        19 kB
        Devaraj Das

        Issue Links

          Activity

          Hide
          Devaraj Das added a comment -

          This is a work-in-progress patch. It is mostly a rebase of the relevant code from https://github.com/facebook/hadoop-20.git (branch production).

          Show
          Devaraj Das added a comment - This is a work-in-progress patch. It is mostly a rebase of the relevant code from https://github.com/facebook/hadoop-20.git (branch production).
          Hide
          Devaraj Das added a comment -

          Had attached an incorrect patch earlier. This is the right one.

          Show
          Devaraj Das added a comment - Had attached an incorrect patch earlier. This is the right one.
          Hide
          stack added a comment -

          Do you think this could cause us issue Devaraj:

          +        favoredNodeInfos[i] = new DatanodeInfo(new DatanodeID(
          +            favoredNodes[i].getAddress().getHostAddress() + ":" +
          +            favoredNodes[i].getPort()));
          

          Here we are doing resolve from the client's POV. It might come up w/ a different hostname than that which the NN has for the favored node (vagaries of the local resolve setup). Anything we can do to make it so we for sure have same name for the favored node as NN has?

          nit: presize w/ replication count?

          + List<DatanodeDescriptor> results = new ArrayList<DatanodeDescriptor>();

          I am unclear on the comment below:

          +        // Choose a single node which is local to favoredNode.
          +        DatanodeDescriptor[] locations = replicator.chooseTarget(1,
          +            favoredNode, new ArrayList<DatanodeDescriptor>(),
          +            excludedNodes, blockSize);
          

          Does it mean local to the supplied favoredNode? If so, why not "Choose the favored node". Or is it saying choose as one of the replicas, the node that is making the request; i.e. enforcing a replica local to the location the dfsclient is making the request from? If the latter, I have further comment but will hold for clarification (and looking at code, it is the former it seems).

          Patch looks great DD.

          Show
          stack added a comment - Do you think this could cause us issue Devaraj: + favoredNodeInfos[i] = new DatanodeInfo( new DatanodeID( + favoredNodes[i].getAddress().getHostAddress() + ":" + + favoredNodes[i].getPort())); Here we are doing resolve from the client's POV. It might come up w/ a different hostname than that which the NN has for the favored node (vagaries of the local resolve setup). Anything we can do to make it so we for sure have same name for the favored node as NN has? nit: presize w/ replication count? + List<DatanodeDescriptor> results = new ArrayList<DatanodeDescriptor>(); I am unclear on the comment below: + // Choose a single node which is local to favoredNode. + DatanodeDescriptor[] locations = replicator.chooseTarget(1, + favoredNode, new ArrayList<DatanodeDescriptor>(), + excludedNodes, blockSize); Does it mean local to the supplied favoredNode? If so, why not "Choose the favored node". Or is it saying choose as one of the replicas, the node that is making the request; i.e. enforcing a replica local to the location the dfsclient is making the request from? If the latter, I have further comment but will hold for clarification (and looking at code, it is the former it seems). Patch looks great DD.
          Hide
          Devaraj Das added a comment -

          Thanks stack for the review, and sorry for the delay in getting back. I was busy with getting the hbase side in shape to use this feature..

          On your comments:

          Here we are doing resolve from the client's POV. It might come up w/ a different hostname than that which the NN has for the favored node (vagaries of the local resolve setup). Anything we can do to make it so we for sure have same name for the favored node as NN has?

          I can't see how we can easily handle this problem. But the good news is that the resolution problem shouldn't bite the HBase use case. In the HBase use case, the HBase Master (most likely co-located in the same cluster as the Namenode) does the favored nodes assignment for regions. The Master and the Namenode should see the same address/hostname...

          I am unclear on the comment below. Does it mean local to the supplied favoredNode?

          Yes. Look at the implementation of chooseTarget that is invoked from there. Finally, a call to chooseLocalNode is made. This is done for all the favored nodes (for loop over the favored nodes).

          Show
          Devaraj Das added a comment - Thanks stack for the review, and sorry for the delay in getting back. I was busy with getting the hbase side in shape to use this feature.. On your comments: Here we are doing resolve from the client's POV. It might come up w/ a different hostname than that which the NN has for the favored node (vagaries of the local resolve setup). Anything we can do to make it so we for sure have same name for the favored node as NN has? I can't see how we can easily handle this problem. But the good news is that the resolution problem shouldn't bite the HBase use case. In the HBase use case, the HBase Master (most likely co-located in the same cluster as the Namenode) does the favored nodes assignment for regions. The Master and the Namenode should see the same address/hostname... I am unclear on the comment below. Does it mean local to the supplied favoredNode? Yes. Look at the implementation of chooseTarget that is invoked from there. Finally, a call to chooseLocalNode is made. This is done for all the favored nodes (for loop over the favored nodes).
          Hide
          stack added a comment -

          I can't see how we can easily handle this problem.

          I am not sure we can; we cannot fix fellas resolve for them. It would be good though if you could do something to make it so when the problem is present, it is noted somehow. A WARN log saying I sent you a list of favored nodes and you ignored it would probably get pretty annoying pretty quickly but maybe in a trace-level log adding to an existing log whether or not favored nodes is being respected would help us know if this feature is working or not (or say, adding to 'LOG.debug(src + ": masked=" + masked);' if favoredNodes are being asked for) or in the NN, it could note a DN is asking us to use favored nodes not part of the cluster? For example when you do this:

          + // If the current cluster doesn't contain the node, fallback to
          + // something machine local and then rack local.

          Do you think there could be a log here – its pretty odd being asked use a node not part of the cluster?

          On comment, if a new patch, would suggest an edit to make your intent more clear.

          Patch still good by me. Good on you Devaraj

          Show
          stack added a comment - I can't see how we can easily handle this problem. I am not sure we can; we cannot fix fellas resolve for them. It would be good though if you could do something to make it so when the problem is present, it is noted somehow. A WARN log saying I sent you a list of favored nodes and you ignored it would probably get pretty annoying pretty quickly but maybe in a trace-level log adding to an existing log whether or not favored nodes is being respected would help us know if this feature is working or not (or say, adding to 'LOG.debug(src + ": masked=" + masked);' if favoredNodes are being asked for) or in the NN, it could note a DN is asking us to use favored nodes not part of the cluster? For example when you do this: + // If the current cluster doesn't contain the node, fallback to + // something machine local and then rack local. Do you think there could be a log here – its pretty odd being asked use a node not part of the cluster? On comment, if a new patch, would suggest an edit to make your intent more clear. Patch still good by me. Good on you Devaraj
          Hide
          Aaron T. Myers added a comment -

          Any thoughts about making these hints persistent on the NN? It looks like the current patch would only come into play at file creation time, which means that after the file is written DN failures or running the balancer would cause HDFS to no longer know which DNs should be favored for the replicas of a given file.

          Show
          Aaron T. Myers added a comment - Any thoughts about making these hints persistent on the NN? It looks like the current patch would only come into play at file creation time, which means that after the file is written DN failures or running the balancer would cause HDFS to no longer know which DNs should be favored for the replicas of a given file.
          Hide
          Jonathan Hsieh added a comment -

          Would the making this persistent be addressed here or as a follow on issue?

          From a design point of view would it be possible to just add an attribute or flag on hdfs files or directories that specify an block affinity group? This would seem cheaper than an alternative that specifies specific favored dn's lists for block replicas. This would seem more robust than something specified only at file creation time, and more managable in the long term if data nodes membership changes over time.

          Show
          Jonathan Hsieh added a comment - Would the making this persistent be addressed here or as a follow on issue? From a design point of view would it be possible to just add an attribute or flag on hdfs files or directories that specify an block affinity group? This would seem cheaper than an alternative that specifies specific favored dn's lists for block replicas. This would seem more robust than something specified only at file creation time, and more managable in the long term if data nodes membership changes over time.
          Hide
          Devaraj Das added a comment -

          Aaron T. Myers and Jonathan Hsieh, in the current patch, persistence is not handled. But in the use case of HBase, region files are rewritten as part of compaction, and that would again create the blocks in the favored nodes...

          On how to handle persistence, yes, adding attributes to the directories/files would work, but let me get to the next level of detail on that.

          Show
          Devaraj Das added a comment - Aaron T. Myers and Jonathan Hsieh , in the current patch, persistence is not handled. But in the use case of HBase, region files are rewritten as part of compaction, and that would again create the blocks in the favored nodes... On how to handle persistence, yes, adding attributes to the directories/files would work, but let me get to the next level of detail on that.
          Hide
          Aaron T. Myers added a comment -

          From a design point of view would it be possible to just add an attribute or flag on hdfs files or directories that specify an block affinity group? This would seem cheaper than an alternative that specifies specific favored dn's lists for block replicas. This would seem more robust than something specified only at file creation time, and more managable in the long term if data nodes membership changes over time.

          +1, all of this makes sense to me.

          in the use case of HBase, region files are rewritten as part of compaction, and that would again create the blocks in the favored nodes...

          True, though I can imagine other uses besides just HBase region files that could benefit from a feature like this, e.g. some file formats which will be used in joins could benefit from HDFS trying to place the replicas of a few separate files on the same set of DNs. In that case we shouldn't assume that the files will be short-lived/rewritten during a compaction process.

          Of course persistence of these hints could be done as a separate JIRA, but we might consider as part of this JIRA whether the API could be made appropriate for both use cases - long-lived and short-lived files. For that matter, we might deliberately make these hints non-persistent in the branch-1 implementation so as to avoid having to bump the edit log version number, but persistent in the trunk/branch-2 implementation.

          but let me get to the next level of detail on that.

          Sorry, I don't understand. What do you mean by this?

          Also, I realize that the current patch is intended to be WIP, but it also appears to be targeted at branch-1. Before we can commit this to branch-1, we'll need to have a trunk/branch-2 patch.

          Show
          Aaron T. Myers added a comment - From a design point of view would it be possible to just add an attribute or flag on hdfs files or directories that specify an block affinity group? This would seem cheaper than an alternative that specifies specific favored dn's lists for block replicas. This would seem more robust than something specified only at file creation time, and more managable in the long term if data nodes membership changes over time. +1, all of this makes sense to me. in the use case of HBase, region files are rewritten as part of compaction, and that would again create the blocks in the favored nodes... True, though I can imagine other uses besides just HBase region files that could benefit from a feature like this, e.g. some file formats which will be used in joins could benefit from HDFS trying to place the replicas of a few separate files on the same set of DNs. In that case we shouldn't assume that the files will be short-lived/rewritten during a compaction process. Of course persistence of these hints could be done as a separate JIRA, but we might consider as part of this JIRA whether the API could be made appropriate for both use cases - long-lived and short-lived files. For that matter, we might deliberately make these hints non-persistent in the branch-1 implementation so as to avoid having to bump the edit log version number, but persistent in the trunk/branch-2 implementation. but let me get to the next level of detail on that. Sorry, I don't understand. What do you mean by this? Also, I realize that the current patch is intended to be WIP, but it also appears to be targeted at branch-1. Before we can commit this to branch-1, we'll need to have a trunk/branch-2 patch.
          Hide
          Jonathan Hsieh added a comment -

          Sorry, I don't understand. What do you mean by this?

          I believe DD is referring to discussion on the related HBASE-4755 jira.

          I think we should define what the goal API is for this in HDFS, and for that we probably need more HBase context. The HDFS API's we choose here may limit the possibilities for HBase, or require exposing even more more HDFS internals.

          The DD's current approach seems like a reasonable first step – HBase hints HDFS, but in the longer run the balancers at the different levels may "fight".

          For the HBase use case it seems that the two extreme design points are:

          • HBase is oblivious of physical placement but has the ability to asks HDFS for the "next most local" node (so that HBase can reassign the region assoiciated with the files to that machine). Maybe HBase provides HDFS a block placement policy plug-in that provides mechanism to get the "next most local" api. (encapsulation approach)
          • HDFS provides a raw block placement api, and HBase completely manages block placement with an balancing/block interrogation in HDFS. We may need some override to prevent the HDFS block balancer from doing anything on particular files/subdirs. (end-to-end principle approach)

          Do you guys have opinions on which direction we want to head? (DD, ATM?)

          Show
          Jonathan Hsieh added a comment - Sorry, I don't understand. What do you mean by this? I believe DD is referring to discussion on the related HBASE-4755 jira. I think we should define what the goal API is for this in HDFS, and for that we probably need more HBase context. The HDFS API's we choose here may limit the possibilities for HBase, or require exposing even more more HDFS internals. The DD's current approach seems like a reasonable first step – HBase hints HDFS, but in the longer run the balancers at the different levels may "fight". For the HBase use case it seems that the two extreme design points are: HBase is oblivious of physical placement but has the ability to asks HDFS for the "next most local" node (so that HBase can reassign the region assoiciated with the files to that machine). Maybe HBase provides HDFS a block placement policy plug-in that provides mechanism to get the "next most local" api. (encapsulation approach) HDFS provides a raw block placement api, and HBase completely manages block placement with an balancing/block interrogation in HDFS. We may need some override to prevent the HDFS block balancer from doing anything on particular files/subdirs. (end-to-end principle approach) Do you guys have opinions on which direction we want to head? (DD, ATM?)
          Hide
          stack added a comment -

          From a design point of view would it be possible to just add an attribute or flag on hdfs files or directories that specify an block affinity group?

          How would this work? FS would have to expose these markings and client would have to be able to ask the FS who the group members were so could make use of this information; e.g. in hbase we would want to open a region on a server that was sitting beside a dn that had a local replica. Would group member count == replication count? If members > replication, then could get a member that didn't have a local replica? Would NN figure out group members? If DNs go away, it would rebalance group members?

          Show
          stack added a comment - From a design point of view would it be possible to just add an attribute or flag on hdfs files or directories that specify an block affinity group? How would this work? FS would have to expose these markings and client would have to be able to ask the FS who the group members were so could make use of this information; e.g. in hbase we would want to open a region on a server that was sitting beside a dn that had a local replica. Would group member count == replication count? If members > replication, then could get a member that didn't have a local replica? Would NN figure out group members? If DNs go away, it would rebalance group members?
          Hide
          Andrew Purtell added a comment -

          If block device type affinity hints are available, then this could be an additional factor for a future block placement algorithm. See HDFS-2832 and HBASE-6572 for relevant discussion. If device affinity hints might have a path component (e.g. xattr in the namespace that associates a path with a block device type affinity hint), then this could be related here too.

          A couple of questions fall out:

          • What of the notion of xattrs in the namespace?
          • What if xattr handling were pluggable?
          • Would a favored node hint be a candidate for a plug in handler for an xattr for same?
          Show
          Andrew Purtell added a comment - If block device type affinity hints are available, then this could be an additional factor for a future block placement algorithm. See HDFS-2832 and HBASE-6572 for relevant discussion. If device affinity hints might have a path component (e.g. xattr in the namespace that associates a path with a block device type affinity hint), then this could be related here too. A couple of questions fall out: What of the notion of xattrs in the namespace? What if xattr handling were pluggable? Would a favored node hint be a candidate for a plug in handler for an xattr for same?
          Hide
          Jonathan Hsieh added a comment -

          Stack

          How would this work? FS would have to expose these markings and client would have to be able to ask the FS who the group members were so could make use of this information; e.g. in hbase we would want to open a region on a server that was sitting beside a dn that had a local replica. Would group member count == replication count? If members > replication, then could get a member that didn't have a local replica? Would NN figure out group members? If DNs go away, it would rebalance group members?

          The key point I'm trying to make is that either HBase isn't very involved with HDFS balancing/recovery or it becomes is heavily involved. I'll go an flesh out the two extremes more.

          The one approach would have a relatively thin information sharing between HBase and HDFS. HBase would specify that a set of files or dirs should be placed on the same set of datanodes without actually specifying the specific set. This assumes HDFS handles placement and HBase queries HDFS for the best node to go to when it is time to do an hbase region assignment. So if datanodes die, new datanodes appear, or balance becomes highly skewed, HDFS is responsible for maintaining the affinity property dealing with things like rack policies etc without having to notify HBase. Here's a straw man of this approach:

          • A dir (or set of files)'s equivalent of a dirent would have some metadata specifying an block affinity group.
          • The HDFS pipelined-block-writes remains essentially the same with something like another policy module to manage an affinity group's members.
          • The HDFS policy would (HDFS NN?) would be responsible for selecting the nodes the block replicas are written to and enforcing that subsequent blocks go to the same set. HDFS has this information so that its hdfs balancer to balance all related blocks intelligently (managing rack placement policies, or disk placement policies in the event of failures, new datanodes, etc).
          • HBase does not know about these decisions (or need to know) until a RS failure causes the region planner/balancer algo to ask HDFS for a suggestion of where to assign the region.

          I'm not clear what group-member-count part of the group-member-count vs replication count concern is.

          The other approach has HBase (or some other application) in control of HDFS blocks placement. HBase would live with potentially uninformed non-optimal choices from HDFS (we are doing this today) or for optimal choices HBase would be involved in balancing and data node selection. So if device affinity gets added, HBase would potentially have to become aware of that. This is good because we get an incremental improvement for relatively little work, but for optimal perf we'd potentially need to introduce a circular dependency or introduce add much tighter coupling between HDFS and HBase. A straw man:

          • An HBase region's metadata would specify preferred datanodes.
          • The HDFS pipelined-block-writes remains essentially the same but all hbase writes specify the preferred datanodes.
          • The HBase policy would (HBase Master) would be responsible for selecting the nodes the block replicas are written to. It would rely on an HDFS mechanism for enforcing that subsequent blocks go to the same set. To do a good job it would need to be aware of managing rack placement policies, skew in balance, and added or removed data nodes to balancing properly. If new factors like device affinity came out it would have to be aware of this too. Ideally, HDFS would be able to update HBase if the hints are bad.
          • For non-optimal performance, the hdfs balancer (responsible for managing rack placement policies, or disk placement policies in the event of failures, new datanodes, etc) acts as it does today and randomly balances the data with no preference information or ability to update preferences) in hbase.
          • Alternately, we might be able to play games where we write 3 files with hdfs file replication 1 and force one local and the other two remote (somehow using rack policy, etc).

          Personally, I don't really think HBase should be heavily involved with normal HDFS recovery/balancing and prefer the first approach as an ideal goal. It would be nice if these placement policies could be plugged into HDFS.

          Show
          Jonathan Hsieh added a comment - Stack How would this work? FS would have to expose these markings and client would have to be able to ask the FS who the group members were so could make use of this information; e.g. in hbase we would want to open a region on a server that was sitting beside a dn that had a local replica. Would group member count == replication count? If members > replication, then could get a member that didn't have a local replica? Would NN figure out group members? If DNs go away, it would rebalance group members? The key point I'm trying to make is that either HBase isn't very involved with HDFS balancing/recovery or it becomes is heavily involved. I'll go an flesh out the two extremes more. The one approach would have a relatively thin information sharing between HBase and HDFS. HBase would specify that a set of files or dirs should be placed on the same set of datanodes without actually specifying the specific set. This assumes HDFS handles placement and HBase queries HDFS for the best node to go to when it is time to do an hbase region assignment. So if datanodes die, new datanodes appear, or balance becomes highly skewed, HDFS is responsible for maintaining the affinity property dealing with things like rack policies etc without having to notify HBase. Here's a straw man of this approach: A dir (or set of files)'s equivalent of a dirent would have some metadata specifying an block affinity group. The HDFS pipelined-block-writes remains essentially the same with something like another policy module to manage an affinity group's members. The HDFS policy would (HDFS NN?) would be responsible for selecting the nodes the block replicas are written to and enforcing that subsequent blocks go to the same set. HDFS has this information so that its hdfs balancer to balance all related blocks intelligently (managing rack placement policies, or disk placement policies in the event of failures, new datanodes, etc). HBase does not know about these decisions (or need to know) until a RS failure causes the region planner/balancer algo to ask HDFS for a suggestion of where to assign the region. I'm not clear what group-member-count part of the group-member-count vs replication count concern is. The other approach has HBase (or some other application) in control of HDFS blocks placement. HBase would live with potentially uninformed non-optimal choices from HDFS (we are doing this today) or for optimal choices HBase would be involved in balancing and data node selection. So if device affinity gets added, HBase would potentially have to become aware of that. This is good because we get an incremental improvement for relatively little work, but for optimal perf we'd potentially need to introduce a circular dependency or introduce add much tighter coupling between HDFS and HBase. A straw man: An HBase region's metadata would specify preferred datanodes. The HDFS pipelined-block-writes remains essentially the same but all hbase writes specify the preferred datanodes. The HBase policy would (HBase Master) would be responsible for selecting the nodes the block replicas are written to. It would rely on an HDFS mechanism for enforcing that subsequent blocks go to the same set. To do a good job it would need to be aware of managing rack placement policies, skew in balance, and added or removed data nodes to balancing properly. If new factors like device affinity came out it would have to be aware of this too. Ideally, HDFS would be able to update HBase if the hints are bad. For non-optimal performance, the hdfs balancer (responsible for managing rack placement policies, or disk placement policies in the event of failures, new datanodes, etc) acts as it does today and randomly balances the data with no preference information or ability to update preferences) in hbase. Alternately, we might be able to play games where we write 3 files with hdfs file replication 1 and force one local and the other two remote (somehow using rack policy, etc). Personally, I don't really think HBase should be heavily involved with normal HDFS recovery/balancing and prefer the first approach as an ideal goal. It would be nice if these placement policies could be plugged into HDFS.
          Hide
          stack added a comment -

          Nice writeup Jon.

          I'm not clear what group-member-count part of the group-member-count vs replication count concern is.

          A "block affinity group" is made up of members. If the count of members is > than the replication setting, then we could assign a 'region' to a 'block affinity group' member that actually didn't have blocks local (because this member was beyond the replication count; i.e. if replication is 3 and group has 10 members, 7/10 times we will be on a node where the block is not local).

          Outline #1 is how it should work. Outline #2 would arrive much faster methinks and could do as stopgap until Option #1 shows up (Can we ask the hdfs block balancer to by-pass directories?) Rack awareness wouldn't be too bad. Skew we could live with (probably) and ditto for datanodes coming and going (NN would not let us select them as favored nodes and if the application is paying attention, it'll stop suggesting dead DNs).

          Show
          stack added a comment - Nice writeup Jon. I'm not clear what group-member-count part of the group-member-count vs replication count concern is. A "block affinity group" is made up of members. If the count of members is > than the replication setting, then we could assign a 'region' to a 'block affinity group' member that actually didn't have blocks local (because this member was beyond the replication count; i.e. if replication is 3 and group has 10 members, 7/10 times we will be on a node where the block is not local). Outline #1 is how it should work. Outline #2 would arrive much faster methinks and could do as stopgap until Option #1 shows up (Can we ask the hdfs block balancer to by-pass directories?) Rack awareness wouldn't be too bad. Skew we could live with (probably) and ditto for datanodes coming and going (NN would not let us select them as favored nodes and if the application is paying attention, it'll stop suggesting dead DNs).
          Hide
          Uma Maheswara Rao G added a comment -

          From a design point of view would it be possible to just add an attribute or flag on hdfs files or directories that specify an block affinity group? This would seem cheaper than an alternative that specifies specific favored dn's lists for block replicas. This would seem more robust than something specified only at file creation time, and more managable in the long term if data nodes membership changes over time.

          +1
          Also looks like this idea is closure to http://www.vldb.org/pvldb/vol4/p575-eltabakh.pdf (cohadoop)

          Anyway HDFS take care of keeping first block local to the node.(is that the case like one RS create the files, another RS will work on them? not sure is there a case ). Once HDFS choosen the targets for first block, subsequent block can use the same location as previous block? I am not sure what is the Strict requirement of passing node addresses from client. Even if further files also wanted to choose the same targets, we can pass same group id then the blocks for that file also will be placed in same nodes. This looks to be generic idea. Persisting thism will help HDFS balancers to replicate if DN alone goes down for the replication. I might miss lot of history in this discussion, please correct me if I am wrong.
          Also, most of the required new target choosing mechanism should go as new pluggable policy.[may be required api can be added to policy interface to fit this requirement]

          Show
          Uma Maheswara Rao G added a comment - From a design point of view would it be possible to just add an attribute or flag on hdfs files or directories that specify an block affinity group? This would seem cheaper than an alternative that specifies specific favored dn's lists for block replicas. This would seem more robust than something specified only at file creation time, and more managable in the long term if data nodes membership changes over time. +1 Also looks like this idea is closure to http://www.vldb.org/pvldb/vol4/p575-eltabakh.pdf (cohadoop) Anyway HDFS take care of keeping first block local to the node.(is that the case like one RS create the files, another RS will work on them? not sure is there a case ). Once HDFS choosen the targets for first block, subsequent block can use the same location as previous block? I am not sure what is the Strict requirement of passing node addresses from client. Even if further files also wanted to choose the same targets, we can pass same group id then the blocks for that file also will be placed in same nodes. This looks to be generic idea. Persisting thism will help HDFS balancers to replicate if DN alone goes down for the replication. I might miss lot of history in this discussion, please correct me if I am wrong. Also, most of the required new target choosing mechanism should go as new pluggable policy. [may be required api can be added to policy interface to fit this requirement]
          Hide
          Devaraj Das added a comment -

          Good discussion points. However, do note that this mechanism is best effort and if possible I'd like to avoid major surgeries in HDFS for this to work. What is currently there in the patch seems to be a simple approach and not too intrusive in the HDFS layer (and should make the average failure cases better, and the worst cases may be unaffected). The case in point here is HBase and maybe the only major user of the API introduced in the patch (and maybe we can mark the API private/evolving with HBase as the audience..)

          Even after implementing an ideal solution, it'd be still best effort in terms of locality (imagine cases where the hdfs balancer ends up doing a not so good job since it has to deal with practical physical/disk constraints). The hdfs balancer would have to be significantly changed if we want to do this in the HDFS (offline discussions with Suresh Srinivas indicated) since the balancer works with blocks and doesn't know which directory owns which blocks. For now if the balancer (which is run manually for HDFS) is too problematic, we can change the balancer implementation so that it doesn't move blocks belonging to certain directories (the information of blocks to paths seems to be there).

          BTW another point is that applications like HBase may sometimes want to control the placement of blocks for multi-tenancy reasons, load-balancing reasons, etc.

          Maybe, at some point both mechanisms (client driven and namenode policy) of having favored nodes in the HDFS might be required (policy, if configured, always wins in case of conflicts).

          Show
          Devaraj Das added a comment - Good discussion points. However, do note that this mechanism is best effort and if possible I'd like to avoid major surgeries in HDFS for this to work. What is currently there in the patch seems to be a simple approach and not too intrusive in the HDFS layer (and should make the average failure cases better, and the worst cases may be unaffected). The case in point here is HBase and maybe the only major user of the API introduced in the patch (and maybe we can mark the API private/evolving with HBase as the audience..) Even after implementing an ideal solution, it'd be still best effort in terms of locality (imagine cases where the hdfs balancer ends up doing a not so good job since it has to deal with practical physical/disk constraints). The hdfs balancer would have to be significantly changed if we want to do this in the HDFS (offline discussions with Suresh Srinivas indicated) since the balancer works with blocks and doesn't know which directory owns which blocks. For now if the balancer (which is run manually for HDFS) is too problematic, we can change the balancer implementation so that it doesn't move blocks belonging to certain directories (the information of blocks to paths seems to be there). BTW another point is that applications like HBase may sometimes want to control the placement of blocks for multi-tenancy reasons, load-balancing reasons, etc. Maybe, at some point both mechanisms (client driven and namenode policy) of having favored nodes in the HDFS might be required (policy, if configured, always wins in case of conflicts).
          Hide
          Jonathan Hsieh added a comment -

          Stack got it. I had assumed that block-affinity-group.size == replication-count. It seems like the affinity group attribute would be more ideal because it would keep the block-affinity-group property orthogonal from the replication count.

          Show
          Jonathan Hsieh added a comment - Stack got it. I had assumed that block-affinity-group.size == replication-count. It seems like the affinity group attribute would be more ideal because it would keep the block-affinity-group property orthogonal from the replication count.
          Hide
          Jonathan Hsieh added a comment -

          Devaraj Das, Stack I basically agree with short-term assessment of incremental work for incremental benefit, I just didn't see any discussion about alternatives and what potential ideals are.

          If we eventually went with the "ideal" approach, HDFS would still need this hint API internally to HDFS so it is likely an incremental step. I don't think that hbase would be the only major user of this feature – Aaron T. Myers mentions "file formats which will be used in joins" – and other applications would want low-latency access in the face of failures will want this kind of control as well.

          I don't know all the internals of the hfds balancer, but it would seem that if it a block contained the dirent, the affinity group info should be available. We'd probably need to define an interface and semantics where files created under a subdir inherit the affinity of its parent and/or a mechanism to modify affinity groups.

          Show
          Jonathan Hsieh added a comment - Devaraj Das , Stack I basically agree with short-term assessment of incremental work for incremental benefit, I just didn't see any discussion about alternatives and what potential ideals are. If we eventually went with the "ideal" approach, HDFS would still need this hint API internally to HDFS so it is likely an incremental step. I don't think that hbase would be the only major user of this feature – Aaron T. Myers mentions "file formats which will be used in joins" – and other applications would want low-latency access in the face of failures will want this kind of control as well. I don't know all the internals of the hfds balancer, but it would seem that if it a block contained the dirent, the affinity group info should be available. We'd probably need to define an interface and semantics where files created under a subdir inherit the affinity of its parent and/or a mechanism to modify affinity groups.
          Hide
          Aaron T. Myers added a comment -

          For now if the balancer (which is run manually for HDFS) is too problematic, we can change the balancer implementation so that it doesn't move blocks belonging to certain directories (the information of blocks to paths seems to be there).

          This is a good idea independent of this work, and is tracked by HDFS-4420.

          I think I agree with all the points that Jon has made. A persistent block affinity group seems like the best solution to me, but the patch as it's been so far described seems to provide a good incremental improvement and won't preclude future improvements to the feature.

          Show
          Aaron T. Myers added a comment - For now if the balancer (which is run manually for HDFS) is too problematic, we can change the balancer implementation so that it doesn't move blocks belonging to certain directories (the information of blocks to paths seems to be there). This is a good idea independent of this work, and is tracked by HDFS-4420 . I think I agree with all the points that Jon has made. A persistent block affinity group seems like the best solution to me, but the patch as it's been so far described seems to provide a good incremental improvement and won't preclude future improvements to the feature.
          Hide
          Devaraj Das added a comment -

          Thanks to everyone who chimed in on this issue. I take it that there is an agreement that the proposed approach is fine (a good incremental step). I'll work on a trunk patch for this.

          Show
          Devaraj Das added a comment - Thanks to everyone who chimed in on this issue. I take it that there is an agreement that the proposed approach is fine (a good incremental step). I'll work on a trunk patch for this.
          Hide
          Jonathan Hsieh added a comment -

          yup, I agree.

          Show
          Jonathan Hsieh added a comment - yup, I agree.
          Hide
          Devaraj Das added a comment -

          Ok this patch is the first stab at a trunk patch. I am still working through it and might have missed some things (the code is quite different in trunk..). But I think the patch can be reviewed.

          Show
          Devaraj Das added a comment - Ok this patch is the first stab at a trunk patch. I am still working through it and might have missed some things (the code is quite different in trunk..). But I think the patch can be reviewed.
          Hide
          Suresh Srinivas added a comment - - edited

          A lot of discussion to catchup with. I will post a comment later when I get some time. Devaraj, should DistributedFileSystem include a new version of the create method, for HBase to use, in trunk version of the patch?

          Show
          Suresh Srinivas added a comment - - edited A lot of discussion to catchup with. I will post a comment later when I get some time. Devaraj, should DistributedFileSystem include a new version of the create method, for HBase to use, in trunk version of the patch?
          Hide
          Hari Mankude added a comment -

          Is data skew going to be an issue where some DNs are overloaded vs other DNs? Would this an issue when there is other data stored in hdfs along with hbase?

          Show
          Hari Mankude added a comment - Is data skew going to be an issue where some DNs are overloaded vs other DNs? Would this an issue when there is other data stored in hdfs along with hbase?
          Hide
          Devaraj Das added a comment -

          Good catch, Suresh. Here is an updated patch.

          Hari, the location information is a hint to the namenode, and the namenode does best-effort honoring. The namenode might ignore it in case it sees those issues.

          Show
          Devaraj Das added a comment - Good catch, Suresh. Here is an updated patch. Hari, the location information is a hint to the namenode, and the namenode does best-effort honoring. The namenode might ignore it in case it sees those issues.
          Hide
          Devaraj Das added a comment -

          Updated patch w.r.t the current trunk.

          Show
          Devaraj Das added a comment - Updated patch w.r.t the current trunk.
          Hide
          Hadoop QA added a comment -

          -1 overall. Here are the results of testing the latest attachment
          http://issues.apache.org/jira/secure/attachment/12577936/hdfs-2576-trunk-7.patch
          against trunk revision .

          +1 @author. The patch does not contain any @author tags.

          +1 tests included. The patch appears to include 4 new or modified test files.

          +1 javac. The applied patch does not increase the total number of javac compiler warnings.

          +1 javadoc. The javadoc tool did not generate any warning messages.

          +1 eclipse:eclipse. The patch built with eclipse:eclipse.

          -1 findbugs. The patch appears to introduce 1 new Findbugs (version 1.3.9) warnings.

          +1 release audit. The applied patch does not increase the total number of release audit warnings.

          +1 core tests. The patch passed unit tests in hadoop-common-project/hadoop-common hadoop-hdfs-project/hadoop-hdfs.

          +1 contrib tests. The patch passed contrib unit tests.

          Test results: https://builds.apache.org/job/PreCommit-HDFS-Build/4214//testReport/
          Findbugs warnings: https://builds.apache.org/job/PreCommit-HDFS-Build/4214//artifact/trunk/patchprocess/newPatchFindbugsWarningshadoop-hdfs.html
          Console output: https://builds.apache.org/job/PreCommit-HDFS-Build/4214//console

          This message is automatically generated.

          Show
          Hadoop QA added a comment - -1 overall . Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12577936/hdfs-2576-trunk-7.patch against trunk revision . +1 @author . The patch does not contain any @author tags. +1 tests included . The patch appears to include 4 new or modified test files. +1 javac . The applied patch does not increase the total number of javac compiler warnings. +1 javadoc . The javadoc tool did not generate any warning messages. +1 eclipse:eclipse . The patch built with eclipse:eclipse. -1 findbugs . The patch appears to introduce 1 new Findbugs (version 1.3.9) warnings. +1 release audit . The applied patch does not increase the total number of release audit warnings. +1 core tests . The patch passed unit tests in hadoop-common-project/hadoop-common hadoop-hdfs-project/hadoop-hdfs. +1 contrib tests . The patch passed contrib unit tests. Test results: https://builds.apache.org/job/PreCommit-HDFS-Build/4214//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-HDFS-Build/4214//artifact/trunk/patchprocess/newPatchFindbugsWarningshadoop-hdfs.html Console output: https://builds.apache.org/job/PreCommit-HDFS-Build/4214//console This message is automatically generated.
          Hide
          Devaraj Das added a comment -

          Fixes the findbug warning.

          Show
          Devaraj Das added a comment - Fixes the findbug warning.
          Hide
          Hadoop QA added a comment -

          +1 overall. Here are the results of testing the latest attachment
          http://issues.apache.org/jira/secure/attachment/12577959/hdfs-2576-trunk-7.1.patch
          against trunk revision .

          +1 @author. The patch does not contain any @author tags.

          +1 tests included. The patch appears to include 4 new or modified test files.

          +1 javac. The applied patch does not increase the total number of javac compiler warnings.

          +1 javadoc. The javadoc tool did not generate any warning messages.

          +1 eclipse:eclipse. The patch built with eclipse:eclipse.

          +1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings.

          +1 release audit. The applied patch does not increase the total number of release audit warnings.

          +1 core tests. The patch passed unit tests in hadoop-common-project/hadoop-common hadoop-hdfs-project/hadoop-hdfs.

          +1 contrib tests. The patch passed contrib unit tests.

          Test results: https://builds.apache.org/job/PreCommit-HDFS-Build/4215//testReport/
          Console output: https://builds.apache.org/job/PreCommit-HDFS-Build/4215//console

          This message is automatically generated.

          Show
          Hadoop QA added a comment - +1 overall . Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12577959/hdfs-2576-trunk-7.1.patch against trunk revision . +1 @author . The patch does not contain any @author tags. +1 tests included . The patch appears to include 4 new or modified test files. +1 javac . The applied patch does not increase the total number of javac compiler warnings. +1 javadoc . The javadoc tool did not generate any warning messages. +1 eclipse:eclipse . The patch built with eclipse:eclipse. +1 findbugs . The patch does not introduce any new Findbugs (version 1.3.9) warnings. +1 release audit . The applied patch does not increase the total number of release audit warnings. +1 core tests . The patch passed unit tests in hadoop-common-project/hadoop-common hadoop-hdfs-project/hadoop-hdfs. +1 contrib tests . The patch passed contrib unit tests. Test results: https://builds.apache.org/job/PreCommit-HDFS-Build/4215//testReport/ Console output: https://builds.apache.org/job/PreCommit-HDFS-Build/4215//console This message is automatically generated.
          Hide
          Devaraj Das added a comment -

          Updated patch with unit tests.

          Show
          Devaraj Das added a comment - Updated patch with unit tests.
          Hide
          Hadoop QA added a comment -

          -1 overall. Here are the results of testing the latest attachment
          http://issues.apache.org/jira/secure/attachment/12580179/hdfs-2576-trunk-8.patch
          against trunk revision .

          +1 @author. The patch does not contain any @author tags.

          +1 tests included. The patch appears to include 5 new or modified test files.

          +1 javac. The applied patch does not increase the total number of javac compiler warnings.

          +1 javadoc. The javadoc tool did not generate any warning messages.

          +1 eclipse:eclipse. The patch built with eclipse:eclipse.

          -1 findbugs. The patch appears to introduce 1 new Findbugs (version 1.3.9) warnings.

          +1 release audit. The applied patch does not increase the total number of release audit warnings.

          +1 core tests. The patch passed unit tests in hadoop-common-project/hadoop-common hadoop-hdfs-project/hadoop-hdfs.

          +1 contrib tests. The patch passed contrib unit tests.

          Test results: https://builds.apache.org/job/PreCommit-HDFS-Build/4298//testReport/
          Findbugs warnings: https://builds.apache.org/job/PreCommit-HDFS-Build/4298//artifact/trunk/patchprocess/newPatchFindbugsWarningshadoop-hdfs.html
          Console output: https://builds.apache.org/job/PreCommit-HDFS-Build/4298//console

          This message is automatically generated.

          Show
          Hadoop QA added a comment - -1 overall . Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12580179/hdfs-2576-trunk-8.patch against trunk revision . +1 @author . The patch does not contain any @author tags. +1 tests included . The patch appears to include 5 new or modified test files. +1 javac . The applied patch does not increase the total number of javac compiler warnings. +1 javadoc . The javadoc tool did not generate any warning messages. +1 eclipse:eclipse . The patch built with eclipse:eclipse. -1 findbugs . The patch appears to introduce 1 new Findbugs (version 1.3.9) warnings. +1 release audit . The applied patch does not increase the total number of release audit warnings. +1 core tests . The patch passed unit tests in hadoop-common-project/hadoop-common hadoop-hdfs-project/hadoop-hdfs. +1 contrib tests . The patch passed contrib unit tests. Test results: https://builds.apache.org/job/PreCommit-HDFS-Build/4298//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-HDFS-Build/4298//artifact/trunk/patchprocess/newPatchFindbugsWarningshadoop-hdfs.html Console output: https://builds.apache.org/job/PreCommit-HDFS-Build/4298//console This message is automatically generated.
          Hide
          Devaraj Das added a comment -

          Findbugs found an actual bug. Fixed it.

          Show
          Devaraj Das added a comment - Findbugs found an actual bug. Fixed it.
          Hide
          Hadoop QA added a comment -

          -1 overall. Here are the results of testing the latest attachment
          http://issues.apache.org/jira/secure/attachment/12580212/hdfs-2576-trunk-8.1.patch
          against trunk revision .

          +1 @author. The patch does not contain any @author tags.

          +1 tests included. The patch appears to include 5 new or modified test files.

          +1 javac. The applied patch does not increase the total number of javac compiler warnings.

          +1 javadoc. The javadoc tool did not generate any warning messages.

          +1 eclipse:eclipse. The patch built with eclipse:eclipse.

          +1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings.

          +1 release audit. The applied patch does not increase the total number of release audit warnings.

          -1 core tests. The patch failed these unit tests in hadoop-common-project/hadoop-common hadoop-hdfs-project/hadoop-hdfs:

          org.apache.hadoop.hdfs.server.blockmanagement.TestBlocksWithNotEnoughRacks

          +1 contrib tests. The patch passed contrib unit tests.

          Test results: https://builds.apache.org/job/PreCommit-HDFS-Build/4302//testReport/
          Console output: https://builds.apache.org/job/PreCommit-HDFS-Build/4302//console

          This message is automatically generated.

          Show
          Hadoop QA added a comment - -1 overall . Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12580212/hdfs-2576-trunk-8.1.patch against trunk revision . +1 @author . The patch does not contain any @author tags. +1 tests included . The patch appears to include 5 new or modified test files. +1 javac . The applied patch does not increase the total number of javac compiler warnings. +1 javadoc . The javadoc tool did not generate any warning messages. +1 eclipse:eclipse . The patch built with eclipse:eclipse. +1 findbugs . The patch does not introduce any new Findbugs (version 1.3.9) warnings. +1 release audit . The applied patch does not increase the total number of release audit warnings. -1 core tests . The patch failed these unit tests in hadoop-common-project/hadoop-common hadoop-hdfs-project/hadoop-hdfs: org.apache.hadoop.hdfs.server.blockmanagement.TestBlocksWithNotEnoughRacks +1 contrib tests . The patch passed contrib unit tests. Test results: https://builds.apache.org/job/PreCommit-HDFS-Build/4302//testReport/ Console output: https://builds.apache.org/job/PreCommit-HDFS-Build/4302//console This message is automatically generated.
          Hide
          Devaraj Das added a comment -

          Have seen TestBlocksWithNotEnoughRacks failing before. Example - https://builds.apache.org/job/PreCommit-HDFS-Build/4302/.

          Show
          Devaraj Das added a comment - Have seen TestBlocksWithNotEnoughRacks failing before. Example - https://builds.apache.org/job/PreCommit-HDFS-Build/4302/ .
          Hide
          Tsz Wo Nicholas Sze added a comment -
          • In BlockPlacementPolicyDefault, it should use the oldExcludedNodes when choosing the remaining nodes. Also, what should happen if a node is in both favoredNodes and excludedNodes?
          • In BlockPlacementPolicy and BlockPlacementPolicyDefault, use Collections.<DatanodeDescriptor>emptyList() instead of new ArrayList<DatanodeDescriptor>().
          • Change void resolveNetworkLocation(DatanodeDescriptor) to String resolveNetworkLocation(DatanodeID). Then, we only need to create DatanodeID but not DatanodeDescriptor in the new resolveNetworkLocation(String) method.
          • Move getDatanodeDescriptor(String address) from BlockManager to DatanodeManager.
          Show
          Tsz Wo Nicholas Sze added a comment - In BlockPlacementPolicyDefault, it should use the oldExcludedNodes when choosing the remaining nodes. Also, what should happen if a node is in both favoredNodes and excludedNodes? In BlockPlacementPolicy and BlockPlacementPolicyDefault, use Collections.<DatanodeDescriptor>emptyList() instead of new ArrayList<DatanodeDescriptor>(). Change void resolveNetworkLocation(DatanodeDescriptor) to String resolveNetworkLocation(DatanodeID). Then, we only need to create DatanodeID but not DatanodeDescriptor in the new resolveNetworkLocation(String) method. Move getDatanodeDescriptor(String address) from BlockManager to DatanodeManager.
          Hide
          Devaraj Das added a comment -

          This patch addresses the comments except comment#2. I could not use Collections.emptyList since the list would then be immutable and this won't work. The patch also fixes some other issues.
          1. Handles the excludedNodes better in BlockPlacementPolicyDefault
          2. Makes resolveNetworkLocation(String) work with hostnames and IP addresses.

          Show
          Devaraj Das added a comment - This patch addresses the comments except comment#2. I could not use Collections.emptyList since the list would then be immutable and this won't work. The patch also fixes some other issues. 1. Handles the excludedNodes better in BlockPlacementPolicyDefault 2. Makes resolveNetworkLocation(String) work with hostnames and IP addresses.
          Hide
          Tsz Wo Nicholas Sze added a comment -

          +1 patch looks good.

          Show
          Tsz Wo Nicholas Sze added a comment - +1 patch looks good.
          Hide
          Hadoop QA added a comment -

          -1 overall. Here are the results of testing the latest attachment
          http://issues.apache.org/jira/secure/attachment/12580648/hdfs-2576-trunk-8.2.patch
          against trunk revision .

          +1 @author. The patch does not contain any @author tags.

          +1 tests included. The patch appears to include 5 new or modified test files.

          +1 javac. The applied patch does not increase the total number of javac compiler warnings.

          +1 javadoc. The javadoc tool did not generate any warning messages.

          +1 eclipse:eclipse. The patch built with eclipse:eclipse.

          +1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings.

          +1 release audit. The applied patch does not increase the total number of release audit warnings.

          -1 core tests. The patch failed these unit tests in hadoop-common-project/hadoop-common hadoop-hdfs-project/hadoop-hdfs:

          org.apache.hadoop.hdfs.server.blockmanagement.TestReplicationPolicy
          org.apache.hadoop.hdfs.server.datanode.TestBlockReplacement
          org.apache.hadoop.net.TestNetworkTopology
          org.apache.hadoop.cli.TestHDFSCLI
          org.apache.hadoop.hdfs.server.balancer.TestBalancerWithNodeGroup
          org.apache.hadoop.hdfs.server.namenode.TestHostsFiles
          org.apache.hadoop.hdfs.server.blockmanagement.TestBlocksWithNotEnoughRacks
          org.apache.hadoop.hdfs.TestReplication

          +1 contrib tests. The patch passed contrib unit tests.

          Test results: https://builds.apache.org/job/PreCommit-HDFS-Build/4321//testReport/
          Console output: https://builds.apache.org/job/PreCommit-HDFS-Build/4321//console

          This message is automatically generated.

          Show
          Hadoop QA added a comment - -1 overall . Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12580648/hdfs-2576-trunk-8.2.patch against trunk revision . +1 @author . The patch does not contain any @author tags. +1 tests included . The patch appears to include 5 new or modified test files. +1 javac . The applied patch does not increase the total number of javac compiler warnings. +1 javadoc . The javadoc tool did not generate any warning messages. +1 eclipse:eclipse . The patch built with eclipse:eclipse. +1 findbugs . The patch does not introduce any new Findbugs (version 1.3.9) warnings. +1 release audit . The applied patch does not increase the total number of release audit warnings. -1 core tests . The patch failed these unit tests in hadoop-common-project/hadoop-common hadoop-hdfs-project/hadoop-hdfs: org.apache.hadoop.hdfs.server.blockmanagement.TestReplicationPolicy org.apache.hadoop.hdfs.server.datanode.TestBlockReplacement org.apache.hadoop.net.TestNetworkTopology org.apache.hadoop.cli.TestHDFSCLI org.apache.hadoop.hdfs.server.balancer.TestBalancerWithNodeGroup org.apache.hadoop.hdfs.server.namenode.TestHostsFiles org.apache.hadoop.hdfs.server.blockmanagement.TestBlocksWithNotEnoughRacks org.apache.hadoop.hdfs.TestReplication +1 contrib tests . The patch passed contrib unit tests. Test results: https://builds.apache.org/job/PreCommit-HDFS-Build/4321//testReport/ Console output: https://builds.apache.org/job/PreCommit-HDFS-Build/4321//console This message is automatically generated.
          Hide
          Devaraj Das added a comment -

          I had missed a one line change in my previous patch. Here is the change that should have been there:

          -        resolveNetworkLocation(nodeDescr);
          +        nodeDescr.setNetworkLocation(resolveNetworkLocation(nodeDescr));
          

          Absence of the above change led to the test failures. This patch is with the above change.

          Show
          Devaraj Das added a comment - I had missed a one line change in my previous patch. Here is the change that should have been there: - resolveNetworkLocation(nodeDescr); + nodeDescr.setNetworkLocation(resolveNetworkLocation(nodeDescr)); Absence of the above change led to the test failures. This patch is with the above change.
          Hide
          Hadoop QA added a comment -

          +1 overall. Here are the results of testing the latest attachment
          http://issues.apache.org/jira/secure/attachment/12580672/hdfs-2576-trunk-8.3.patch
          against trunk revision .

          +1 @author. The patch does not contain any @author tags.

          +1 tests included. The patch appears to include 5 new or modified test files.

          +1 javac. The applied patch does not increase the total number of javac compiler warnings.

          +1 javadoc. The javadoc tool did not generate any warning messages.

          +1 eclipse:eclipse. The patch built with eclipse:eclipse.

          +1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings.

          +1 release audit. The applied patch does not increase the total number of release audit warnings.

          +1 core tests. The patch passed unit tests in hadoop-common-project/hadoop-common hadoop-hdfs-project/hadoop-hdfs.

          +1 contrib tests. The patch passed contrib unit tests.

          Test results: https://builds.apache.org/job/PreCommit-HDFS-Build/4323//testReport/
          Console output: https://builds.apache.org/job/PreCommit-HDFS-Build/4323//console

          This message is automatically generated.

          Show
          Hadoop QA added a comment - +1 overall . Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12580672/hdfs-2576-trunk-8.3.patch against trunk revision . +1 @author . The patch does not contain any @author tags. +1 tests included . The patch appears to include 5 new or modified test files. +1 javac . The applied patch does not increase the total number of javac compiler warnings. +1 javadoc . The javadoc tool did not generate any warning messages. +1 eclipse:eclipse . The patch built with eclipse:eclipse. +1 findbugs . The patch does not introduce any new Findbugs (version 1.3.9) warnings. +1 release audit . The applied patch does not increase the total number of release audit warnings. +1 core tests . The patch passed unit tests in hadoop-common-project/hadoop-common hadoop-hdfs-project/hadoop-hdfs. +1 contrib tests . The patch passed contrib unit tests. Test results: https://builds.apache.org/job/PreCommit-HDFS-Build/4323//testReport/ Console output: https://builds.apache.org/job/PreCommit-HDFS-Build/4323//console This message is automatically generated.
          Hide
          Tsz Wo Nicholas Sze added a comment -

          +1 the new patch looks good.

          Show
          Tsz Wo Nicholas Sze added a comment - +1 the new patch looks good.
          Hide
          Hudson added a comment -

          Integrated in Hadoop-trunk-Commit #3672 (See https://builds.apache.org/job/Hadoop-trunk-Commit/3672/)
          HDFS-2576. Enhances the DistributedFileSystem's create API so that clients can specify favored datanodes for a file's blocks. Contributed by Devaraj Das and Pritam Damania. (Revision 1476395)

          Result = SUCCESS
          ddas : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1476395
          Files :

          • /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/net/NetworkTopology.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/DFSClient.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/DFSOutputStream.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/DistributedFileSystem.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/protocol/ClientProtocol.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/protocolPB/ClientNamenodeProtocolServerSideTranslatorPB.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/protocolPB/ClientNamenodeProtocolTranslatorPB.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/blockmanagement/BlockManager.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/blockmanagement/BlockPlacementPolicy.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/blockmanagement/BlockPlacementPolicyDefault.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/blockmanagement/DatanodeManager.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/FSNamesystem.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/NameNodeRpcServer.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/proto/ClientNamenodeProtocol.proto
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/TestDFSClientRetries.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/TestFileCreation.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/server/namenode/NNThroughputBenchmark.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/server/namenode/TestAddBlockRetry.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/server/namenode/TestFavoredNodesEndToEnd.java
          Show
          Hudson added a comment - Integrated in Hadoop-trunk-Commit #3672 (See https://builds.apache.org/job/Hadoop-trunk-Commit/3672/ ) HDFS-2576 . Enhances the DistributedFileSystem's create API so that clients can specify favored datanodes for a file's blocks. Contributed by Devaraj Das and Pritam Damania. (Revision 1476395) Result = SUCCESS ddas : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1476395 Files : /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/net/NetworkTopology.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/DFSClient.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/DFSOutputStream.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/DistributedFileSystem.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/protocol/ClientProtocol.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/protocolPB/ClientNamenodeProtocolServerSideTranslatorPB.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/protocolPB/ClientNamenodeProtocolTranslatorPB.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/blockmanagement/BlockManager.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/blockmanagement/BlockPlacementPolicy.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/blockmanagement/BlockPlacementPolicyDefault.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/blockmanagement/DatanodeManager.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/FSNamesystem.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/NameNodeRpcServer.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/proto/ClientNamenodeProtocol.proto /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/TestDFSClientRetries.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/TestFileCreation.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/server/namenode/NNThroughputBenchmark.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/server/namenode/TestAddBlockRetry.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/server/namenode/TestFavoredNodesEndToEnd.java
          Hide
          Devaraj Das added a comment -

          Thanks Pritam for the work on the fb branch from which the trunk patch was derived. Thanks, everyone for the review of the patches.

          I'll submit a patch for branch-1 shortly.

          Show
          Devaraj Das added a comment - Thanks Pritam for the work on the fb branch from which the trunk patch was derived. Thanks, everyone for the review of the patches. I'll submit a patch for branch-1 shortly.
          Hide
          Devaraj Das added a comment -

          Forgot to mention that I committed the patch in trunk.

          Show
          Devaraj Das added a comment - Forgot to mention that I committed the patch in trunk.
          Hide
          Hudson added a comment -

          Integrated in Hadoop-Yarn-trunk #196 (See https://builds.apache.org/job/Hadoop-Yarn-trunk/196/)
          HDFS-2576. Enhances the DistributedFileSystem's create API so that clients can specify favored datanodes for a file's blocks. Contributed by Devaraj Das and Pritam Damania. (Revision 1476395)

          Result = SUCCESS
          ddas : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1476395
          Files :

          • /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/net/NetworkTopology.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/DFSClient.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/DFSOutputStream.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/DistributedFileSystem.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/protocol/ClientProtocol.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/protocolPB/ClientNamenodeProtocolServerSideTranslatorPB.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/protocolPB/ClientNamenodeProtocolTranslatorPB.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/blockmanagement/BlockManager.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/blockmanagement/BlockPlacementPolicy.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/blockmanagement/BlockPlacementPolicyDefault.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/blockmanagement/DatanodeManager.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/FSNamesystem.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/NameNodeRpcServer.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/proto/ClientNamenodeProtocol.proto
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/TestDFSClientRetries.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/TestFileCreation.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/server/namenode/NNThroughputBenchmark.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/server/namenode/TestAddBlockRetry.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/server/namenode/TestFavoredNodesEndToEnd.java
          Show
          Hudson added a comment - Integrated in Hadoop-Yarn-trunk #196 (See https://builds.apache.org/job/Hadoop-Yarn-trunk/196/ ) HDFS-2576 . Enhances the DistributedFileSystem's create API so that clients can specify favored datanodes for a file's blocks. Contributed by Devaraj Das and Pritam Damania. (Revision 1476395) Result = SUCCESS ddas : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1476395 Files : /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/net/NetworkTopology.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/DFSClient.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/DFSOutputStream.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/DistributedFileSystem.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/protocol/ClientProtocol.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/protocolPB/ClientNamenodeProtocolServerSideTranslatorPB.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/protocolPB/ClientNamenodeProtocolTranslatorPB.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/blockmanagement/BlockManager.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/blockmanagement/BlockPlacementPolicy.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/blockmanagement/BlockPlacementPolicyDefault.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/blockmanagement/DatanodeManager.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/FSNamesystem.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/NameNodeRpcServer.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/proto/ClientNamenodeProtocol.proto /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/TestDFSClientRetries.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/TestFileCreation.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/server/namenode/NNThroughputBenchmark.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/server/namenode/TestAddBlockRetry.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/server/namenode/TestFavoredNodesEndToEnd.java
          Hide
          Hudson added a comment -

          Integrated in Hadoop-Hdfs-trunk #1385 (See https://builds.apache.org/job/Hadoop-Hdfs-trunk/1385/)
          HDFS-2576. Enhances the DistributedFileSystem's create API so that clients can specify favored datanodes for a file's blocks. Contributed by Devaraj Das and Pritam Damania. (Revision 1476395)

          Result = FAILURE
          ddas : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1476395
          Files :

          • /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/net/NetworkTopology.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/DFSClient.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/DFSOutputStream.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/DistributedFileSystem.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/protocol/ClientProtocol.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/protocolPB/ClientNamenodeProtocolServerSideTranslatorPB.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/protocolPB/ClientNamenodeProtocolTranslatorPB.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/blockmanagement/BlockManager.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/blockmanagement/BlockPlacementPolicy.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/blockmanagement/BlockPlacementPolicyDefault.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/blockmanagement/DatanodeManager.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/FSNamesystem.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/NameNodeRpcServer.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/proto/ClientNamenodeProtocol.proto
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/TestDFSClientRetries.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/TestFileCreation.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/server/namenode/NNThroughputBenchmark.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/server/namenode/TestAddBlockRetry.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/server/namenode/TestFavoredNodesEndToEnd.java
          Show
          Hudson added a comment - Integrated in Hadoop-Hdfs-trunk #1385 (See https://builds.apache.org/job/Hadoop-Hdfs-trunk/1385/ ) HDFS-2576 . Enhances the DistributedFileSystem's create API so that clients can specify favored datanodes for a file's blocks. Contributed by Devaraj Das and Pritam Damania. (Revision 1476395) Result = FAILURE ddas : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1476395 Files : /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/net/NetworkTopology.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/DFSClient.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/DFSOutputStream.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/DistributedFileSystem.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/protocol/ClientProtocol.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/protocolPB/ClientNamenodeProtocolServerSideTranslatorPB.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/protocolPB/ClientNamenodeProtocolTranslatorPB.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/blockmanagement/BlockManager.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/blockmanagement/BlockPlacementPolicy.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/blockmanagement/BlockPlacementPolicyDefault.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/blockmanagement/DatanodeManager.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/FSNamesystem.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/NameNodeRpcServer.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/proto/ClientNamenodeProtocol.proto /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/TestDFSClientRetries.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/TestFileCreation.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/server/namenode/NNThroughputBenchmark.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/server/namenode/TestAddBlockRetry.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/server/namenode/TestFavoredNodesEndToEnd.java
          Hide
          Hudson added a comment -

          Integrated in Hadoop-Mapreduce-trunk #1412 (See https://builds.apache.org/job/Hadoop-Mapreduce-trunk/1412/)
          HDFS-2576. Enhances the DistributedFileSystem's create API so that clients can specify favored datanodes for a file's blocks. Contributed by Devaraj Das and Pritam Damania. (Revision 1476395)

          Result = SUCCESS
          ddas : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1476395
          Files :

          • /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/net/NetworkTopology.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/DFSClient.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/DFSOutputStream.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/DistributedFileSystem.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/protocol/ClientProtocol.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/protocolPB/ClientNamenodeProtocolServerSideTranslatorPB.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/protocolPB/ClientNamenodeProtocolTranslatorPB.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/blockmanagement/BlockManager.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/blockmanagement/BlockPlacementPolicy.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/blockmanagement/BlockPlacementPolicyDefault.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/blockmanagement/DatanodeManager.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/FSNamesystem.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/NameNodeRpcServer.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/proto/ClientNamenodeProtocol.proto
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/TestDFSClientRetries.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/TestFileCreation.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/server/namenode/NNThroughputBenchmark.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/server/namenode/TestAddBlockRetry.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/server/namenode/TestFavoredNodesEndToEnd.java
          Show
          Hudson added a comment - Integrated in Hadoop-Mapreduce-trunk #1412 (See https://builds.apache.org/job/Hadoop-Mapreduce-trunk/1412/ ) HDFS-2576 . Enhances the DistributedFileSystem's create API so that clients can specify favored datanodes for a file's blocks. Contributed by Devaraj Das and Pritam Damania. (Revision 1476395) Result = SUCCESS ddas : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1476395 Files : /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/net/NetworkTopology.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/DFSClient.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/DFSOutputStream.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/DistributedFileSystem.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/protocol/ClientProtocol.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/protocolPB/ClientNamenodeProtocolServerSideTranslatorPB.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/protocolPB/ClientNamenodeProtocolTranslatorPB.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/blockmanagement/BlockManager.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/blockmanagement/BlockPlacementPolicy.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/blockmanagement/BlockPlacementPolicyDefault.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/blockmanagement/DatanodeManager.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/FSNamesystem.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/NameNodeRpcServer.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/proto/ClientNamenodeProtocol.proto /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/TestDFSClientRetries.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/TestFileCreation.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/server/namenode/NNThroughputBenchmark.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/server/namenode/TestAddBlockRetry.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/server/namenode/TestFavoredNodesEndToEnd.java
          Hide
          Devaraj Das added a comment -

          Resolving this patch. Will open another jira for branch-1

          Show
          Devaraj Das added a comment - Resolving this patch. Will open another jira for branch-1
          Hide
          Hudson added a comment -

          Integrated in Hadoop-trunk-Commit #3701 (See https://builds.apache.org/job/Hadoop-trunk-Commit/3701/)
          HDFS-4778. Fixes some issues that the first patch on HDFS-2576 missed. Contributed by Devaraj Das. (Revision 1477849)

          Result = SUCCESS
          ddas : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1477849
          Files :

          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/blockmanagement/BlockPlacementPolicyDefault.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/blockmanagement/DatanodeManager.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/server/namenode/TestFavoredNodesEndToEnd.java
          Show
          Hudson added a comment - Integrated in Hadoop-trunk-Commit #3701 (See https://builds.apache.org/job/Hadoop-trunk-Commit/3701/ ) HDFS-4778 . Fixes some issues that the first patch on HDFS-2576 missed. Contributed by Devaraj Das. (Revision 1477849) Result = SUCCESS ddas : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1477849 Files : /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/blockmanagement/BlockPlacementPolicyDefault.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/blockmanagement/DatanodeManager.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/server/namenode/TestFavoredNodesEndToEnd.java
          Hide
          Hudson added a comment -

          Integrated in Hadoop-trunk-Commit #3702 (See https://builds.apache.org/job/Hadoop-trunk-Commit/3702/)
          HDFS-2576. Moved the commit message lines for HDFS-4778 and HDFS-2576 in CHANGES.txt to the right places. (Revision 1477855)

          Result = SUCCESS
          ddas : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1477855
          Files :

          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt
          Show
          Hudson added a comment - Integrated in Hadoop-trunk-Commit #3702 (See https://builds.apache.org/job/Hadoop-trunk-Commit/3702/ ) HDFS-2576 . Moved the commit message lines for HDFS-4778 and HDFS-2576 in CHANGES.txt to the right places. (Revision 1477855) Result = SUCCESS ddas : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1477855 Files : /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt
          Hide
          Hudson added a comment -

          Integrated in Hadoop-Yarn-trunk #200 (See https://builds.apache.org/job/Hadoop-Yarn-trunk/200/)
          HDFS-2576. Moved the commit message lines for HDFS-4778 and HDFS-2576 in CHANGES.txt to the right places. (Revision 1477855)
          HDFS-4778. Fixes some issues that the first patch on HDFS-2576 missed. Contributed by Devaraj Das. (Revision 1477849)

          Result = SUCCESS
          ddas : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1477855
          Files :

          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt

          ddas : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1477849
          Files :

          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/blockmanagement/BlockPlacementPolicyDefault.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/blockmanagement/DatanodeManager.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/server/namenode/TestFavoredNodesEndToEnd.java
          Show
          Hudson added a comment - Integrated in Hadoop-Yarn-trunk #200 (See https://builds.apache.org/job/Hadoop-Yarn-trunk/200/ ) HDFS-2576 . Moved the commit message lines for HDFS-4778 and HDFS-2576 in CHANGES.txt to the right places. (Revision 1477855) HDFS-4778 . Fixes some issues that the first patch on HDFS-2576 missed. Contributed by Devaraj Das. (Revision 1477849) Result = SUCCESS ddas : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1477855 Files : /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt ddas : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1477849 Files : /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/blockmanagement/BlockPlacementPolicyDefault.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/blockmanagement/DatanodeManager.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/server/namenode/TestFavoredNodesEndToEnd.java
          Hide
          Hudson added a comment -

          Integrated in Hadoop-Hdfs-trunk #1389 (See https://builds.apache.org/job/Hadoop-Hdfs-trunk/1389/)
          HDFS-2576. Moved the commit message lines for HDFS-4778 and HDFS-2576 in CHANGES.txt to the right places. (Revision 1477855)
          HDFS-4778. Fixes some issues that the first patch on HDFS-2576 missed. Contributed by Devaraj Das. (Revision 1477849)

          Result = FAILURE
          ddas : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1477855
          Files :

          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt

          ddas : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1477849
          Files :

          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/blockmanagement/BlockPlacementPolicyDefault.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/blockmanagement/DatanodeManager.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/server/namenode/TestFavoredNodesEndToEnd.java
          Show
          Hudson added a comment - Integrated in Hadoop-Hdfs-trunk #1389 (See https://builds.apache.org/job/Hadoop-Hdfs-trunk/1389/ ) HDFS-2576 . Moved the commit message lines for HDFS-4778 and HDFS-2576 in CHANGES.txt to the right places. (Revision 1477855) HDFS-4778 . Fixes some issues that the first patch on HDFS-2576 missed. Contributed by Devaraj Das. (Revision 1477849) Result = FAILURE ddas : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1477855 Files : /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt ddas : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1477849 Files : /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/blockmanagement/BlockPlacementPolicyDefault.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/blockmanagement/DatanodeManager.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/server/namenode/TestFavoredNodesEndToEnd.java
          Hide
          Hudson added a comment -

          Integrated in Hadoop-Mapreduce-trunk #1416 (See https://builds.apache.org/job/Hadoop-Mapreduce-trunk/1416/)
          HDFS-2576. Moved the commit message lines for HDFS-4778 and HDFS-2576 in CHANGES.txt to the right places. (Revision 1477855)
          HDFS-4778. Fixes some issues that the first patch on HDFS-2576 missed. Contributed by Devaraj Das. (Revision 1477849)

          Result = FAILURE
          ddas : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1477855
          Files :

          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt

          ddas : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1477849
          Files :

          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/blockmanagement/BlockPlacementPolicyDefault.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/blockmanagement/DatanodeManager.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/server/namenode/TestFavoredNodesEndToEnd.java
          Show
          Hudson added a comment - Integrated in Hadoop-Mapreduce-trunk #1416 (See https://builds.apache.org/job/Hadoop-Mapreduce-trunk/1416/ ) HDFS-2576 . Moved the commit message lines for HDFS-4778 and HDFS-2576 in CHANGES.txt to the right places. (Revision 1477855) HDFS-4778 . Fixes some issues that the first patch on HDFS-2576 missed. Contributed by Devaraj Das. (Revision 1477849) Result = FAILURE ddas : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1477855 Files : /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt ddas : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1477849 Files : /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/blockmanagement/BlockPlacementPolicyDefault.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/blockmanagement/DatanodeManager.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/server/namenode/TestFavoredNodesEndToEnd.java
          Hide
          Jian He added a comment -

          I think this patch breaks branch-2, can you please take a look ?

          Show
          Jian He added a comment - I think this patch breaks branch-2, can you please take a look ?
          Hide
          Devaraj Das added a comment -

          I am looking. Sorry for the inconvenience.

          Show
          Devaraj Das added a comment - I am looking. Sorry for the inconvenience.
          Hide
          Devaraj Das added a comment -

          Committed a patch that fixes the compilation issues on branch-2.

          Show
          Devaraj Das added a comment - Committed a patch that fixes the compilation issues on branch-2.
          Hide
          samira elhami added a comment -

          This patch is really helpful. I know it is added to hadoop-2.1.0-Beta. I've install this version of hadoop but I don't know how to set the block placement.
          I've searched everywhere. please help me.
          Thanks

          Show
          samira elhami added a comment - This patch is really helpful. I know it is added to hadoop-2.1.0-Beta. I've install this version of hadoop but I don't know how to set the block placement. I've searched everywhere. please help me. Thanks

            People

            • Assignee:
              Devaraj Das
              Reporter:
              Pritam Damania
            • Votes:
              1 Vote for this issue
              Watchers:
              39 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development