[
https://issues.apache.org/jira/browse/SPARK-18551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15691341#comment-15691341
]
Marcelo Vanzin edited comment on SPARK-18551 at 11/23/16 11:11 PM:
-------------------------------------------------------------------
I'll comment here instead of the PR since my comment is not really about the
code.
I'm not a big fan of this feature. This is exposing destructive functionality
to users of the SHS. Being able to disable it is "nice", but exposing that kind
of functionality raises all sorts of questions:
- Does the user asking for the deletion have permission to do it?
- How can an admin know who deleted what?
For the first, you're talking about expanding the UI's auth code to the history
server. Currently it works at the app level, now it would have to be hooked up
to work for this feature too.
The second one is more complicated. Now the SHS itself must have an audit log,
so that these kinds of things can be logged.
The easy way to implement this is to delete the contents as the user running
the SHS, which means the FS's audit logs will say that it was the SHS user who
deleted the files and not the user who made the request. That makes an SHS
audit log even more important. The more correct way would be to impersonate the
user, but that comes with extra code and extra configuration on all sides.
So I think it would be better to avoid adding this to the SHS. SteveL already
raised a couple of points about the code itself (GET should not do anything
destructive, not all history providers might support this functionality), but I
think the main issues are even more high level here.
was (Author: vanzin):
I'll comment here instead of the PR since my comment is not really about the
code.
I'm not a big fan of this feature. This is exposing destructive functionality
to users of the SHS. Being able to disable it is "nice", but exposing that kind
of functionality raises all sorts of questions:
- Does the user asking for the deletion have permission to do it?
- How can an admin know who deleted what?
For the first, you're talking about expanding the UI's auth code to the history
server. Currently it works at the app level, now it would have to be hooked up
to work for this feature two.
The second one is more complicated. Now the SHS itself must have an audit log,
so that these kinds of things can be logged.
The easy way to implement this is to delete the contents as the user running
the SHS, which means the FS's audit logs will say that it was the SHS user who
deleted the files and not the user who made the request. That makes an SHS
audit log even more important. The more correct way would be to impersonate the
user, but that comes with a extra code and extra configuration on all sides.
So I think it would be better to avoid adding this to the SHS. SteveL already
raised a couple of points about the code itself (GET should not do anything
destructive, not all history providers might support this functionality), but I
think the main issues are even more high level here.
> Add functionality to delete event logs from the History Server UI
> -----------------------------------------------------------------
>
> Key: SPARK-18551
> URL: https://issues.apache.org/jira/browse/SPARK-18551
> Project: Spark
> Issue Type: New Feature
> Components: Spark Core, Web UI
> Reporter: Alex Bozarth
>
> Sometimes a Spark user will only have access to a History Server to interact
> with their (past) applications. But without access to the server they can
> only delete applications through use of the FS Cleaner feature, which itself
> can only clean logs older than a set date.
> I propose adding the ability to delete specific applications via the History
> Server UI with the default setting to off.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@spark.apache.org
For additional commands, e-mail: issues-h...@spark.apache.org
