I'm looking at version 2 of the patch, which always resolves to the home directory to get server defaults. This might appear to be working for the specific use case you need (YARN NodeManager log aggregation), but I don't think it would be generally correct in all cases.
For example, imagine a viewfs configured with mount points mapping /user to local file system and /data to an HDFS cluster. Then, creating a file in /data would still get the undesired replication value.
That example is a bit contrived, but we can also consider the more realistic example from the ViewFs javadocs:
* For example one could have a mount table that provides links such as
* <li> /user -> hdfs: * <li> /project/foo -> hdfs: * <li> /project/bar -> hdfs: * <li> /tmp -> hdfs: * </ul>
Now, assume the client is creating file /project/foo/myFile. The operation would pick up server defaults associated with /user (configured on nnContainingUserDir) instead of the desired /project/foo (configured on nnProject1). The server defaults may differ between nnContainingUserDir and nnProject1.
It seems like we need a patch that is sensitive to the actual Path accessed in the client operation, similar to what Daryn mentioned earlier.
Also, I don't think the new unit test exercises this code, because TestHDFSFileContextMainOperations doesn't configure a ViewFs.