[
https://issues.apache.org/jira/browse/HDFS-15982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17339518#comment-17339518
]
Ayush Saxena commented on HDFS-15982:
-------------------------------------
DefaultFs is like if you don't specify the fs in the path it will get used, if
the path has it, it won't get used. So, that isn't a mandatory conf itself. In
the present case also. The WebHdfs is using the HTTP URI to reach to Namenode,
then I think the DefaultFs points to the RPC. The URI is changing, it isn't the
same FileSystem URI on which the call was made. (Just Tweaking a test).
{code:java}
2021-05-05 13:04:26,933 [Listener at localhost/50984] ERROR web.TestWebHDFS
(TestWebHDFS.java:testWebHdfsNoRedirect(1613)) - URI of the FileSystem during
call webhdfs://localhost:50970
2021-05-05 13:04:34,513 [IPC Server handler 8 on default port 50971] ERROR
resources.NamenodeWebHdfsMethods (NamenodeWebHdfsMethods.java:delete(1574)) -
URI of the FileSystem created for Trash: hdfs://localhost:50971
{code}
In the Namenode it would be there, but there are cases like
We need to check how things behave if the underlying DefaultFs is
{{ViewDistributedFileSystem}} or is using {{ViewFsOverloadScheme}} I checked
for the latter the FS for trash was initiated with {{ViewFsOverloadScheme}} in
the delete method. So, if that resolves to some other place through its mount
table. So, that is also something needs to be checked. Will the Namenode call
the other NS or something like that.
The defaultFs concern was there in the previous jira itself, so that is worth a
thought.
Router would also have issues, if the trash path resolves to different NS, or
to some path which isn't in the Mount Table, when Default Namespace isn't
configured.
Regarding the UI. If the trash interval isn't set and If I select NO(move to
trash), It still deletes with success? Check if the behaviour is like that, The
client may be in wrong impression that things moved to trash, but it actually
didn't. We should have bugged him back, Trash isn't enabled.
The API behaviour has changed. Exception/Return value. That needs to be sorted.
Make sure ALL FileSystems behave similar to WebHdfs, unless there is a strong
reason. (WebHdfs!=FsShell)
And finally find out what was the danger that Daryn Talked about. I remember
seeing a Jira, where it was quoted "Namenode should never make an RPC to
itself", The Namenode can hang or something like that, not sure, what was the
context then. But I couldn't find the jira, so was Daryn's concern related to
that. Not sure. We can't risk out provided we are thinking to put this in a
stable release.
Compatibility is to be restored.
How to proceed.
Lets wait for [~weichiu], he is chasing the 3.3.1 release AFAIK. So, he might
have an answer how much we can wait for this and the answers to the questions
above. If we get everything sorted, or he already have answers. Things should
be good.
> Deleted data using HTTP API should be saved to the trash
> --------------------------------------------------------
>
> Key: HDFS-15982
> URL: https://issues.apache.org/jira/browse/HDFS-15982
> Project: Hadoop HDFS
> Issue Type: New Feature
> Components: hdfs, hdfs-client, httpfs, webhdfs
> Reporter: Bhavik Patel
> Assignee: Viraj Jasani
> Priority: Major
> Labels: pull-request-available
> Attachments: Screenshot 2021-04-23 at 4.19.42 PM.png, Screenshot
> 2021-04-23 at 4.36.57 PM.png
>
> Time Spent: 12h 10m
> Remaining Estimate: 0h
>
> If we delete the data from the Web UI then it should be first moved to
> configured/default Trash directory and after the trash interval time, it
> should be removed. currently, data directly removed from the system[This
> behavior should be the same as CLI cmd]
> This can be helpful when the user accidentally deletes data from the Web UI.
> Similarly we should provide "Skip Trash" option in HTTP API as well which
> should be accessible through Web UI.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
