[
https://issues.apache.org/jira/browse/HDFS-7411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14315571#comment-14315571
]
Andrew Wang commented on HDFS-7411:
-----------------------------------
bq. Then, why don't you setting it to some larger values, say 1m or 10m?
Could you clarify what you mean by this? Faster decommission times seems like a
good thing from an user's perspective. Performance improvements aren't an
incompatible change.
bq. For any patch, if it wants to remove an existing public feature, it should
first deprecate and then remove the feature in some later release.
We're not removing a feature, we're improving an existing one. As I've said
above, limiting by # of nodes is flawed in very many ways. It's difficult for
admins to use since the behavior is so variable, it's always surprising. As you
indicate, this is not pleasing to cluster admins. The new patch actually makes
decom much more predictable.
Again I would appreciate examples where user experience is negatively impacted
compared to before.
bq. I cannot think of a good way to do the translation. Later on, when we have
more experience the new approach, we may be able to make a better decision.
Can you comment on my proposals above specifically? I would appreciate examples
where user experience is negatively impacted. This will help improve the patch.
Else we're delaying for unspecified, unknown possible future concerns.
Also I said above, if you're okay with removing the old decom code in a later
2.x release, we still need to figure out compatibility with the old config
option now.
bq. The -1 is not for the refactoring. It is for keeping the existing behavior.
I actually don't understand why the patch can get +1'ed without bringing up the
incompatibility issue.
Compatibility was brought up quite a bit during review, even before your first
comment. The patch and comment history demonstrates that. I think what we have
right now satisfies compatibility concerns. The existing behavior is very hard
for admins to use, so there is very little value to keeping it exactly as is.
This patch improves upon that, even for users of the old configuration key, and
I've proposed some other ways we could avoid admin surprises.
I'll also ask again, do you have any specific tests you'd like to see run to
improve your confidence in the code quality?
> Refactor and improve decommissioning logic into DecommissionManager
> -------------------------------------------------------------------
>
> Key: HDFS-7411
> URL: https://issues.apache.org/jira/browse/HDFS-7411
> Project: Hadoop HDFS
> Issue Type: Improvement
> Affects Versions: 2.5.1
> Reporter: Andrew Wang
> Assignee: Andrew Wang
> Attachments: hdfs-7411.001.patch, hdfs-7411.002.patch,
> hdfs-7411.003.patch, hdfs-7411.004.patch, hdfs-7411.005.patch,
> hdfs-7411.006.patch, hdfs-7411.007.patch, hdfs-7411.008.patch,
> hdfs-7411.009.patch, hdfs-7411.010.patch
>
>
> Would be nice to split out decommission logic from DatanodeManager to
> DecommissionManager.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
