[jira] [Comment Edited] (HBASE-25183) Move more balancer related classes to hbase-balancer
[ https://issues.apache.org/jira/browse/HBASE-25183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17215586#comment-17215586 ] Andrew Kyle Purtell edited comment on HBASE-25183 at 10/16/20, 6:19 PM: bq. If I just want to keep politeness I could just leave the issue there, and reply a single sentence every week with very positive words but no actual action. Everyone will think I’m a good person but what is the value to the project? Ok, but I will say this: I think one can be polite and still stick to one's opinions. For example, let's say I want to separate out the balancer to a separate module. Someone else on the project has concerns, but I don't agree, so I say "Yes I hear your concerns and here is why I disagree: ..." . No more no less. And then I would put up my patch to split the balancer out to its own module. :-) During patch review the community will either accept it or not, there may be a technical veto, the technical veto may be judged to be valid. So I would then choose to abide by the rationale for the technical veto and update my patch, or abandon the work and move on to another issue. Or maybe I would succeed in getting the technical veto lifted through continuing polite communication and technical rationale, and all would be good that way. I think this is the Apache model of handling disagreement over code. was (Author: apurtell): bq. If I just want to keep politeness I could just leave the issue there, and reply a single sentence every week with very positive words but no actual action. Everyone will think I’m a good person but what is the value to the project? Ok, but I will say this: I think one can be polite and still stick to one's opinions. For example, let's say I want to separate out the balancer to a separate module. Someone else on the project has concerns, but I don't agree, so I say "Yes I hear your concerns and here is why I disagree: ..." . No more no less. And then I would put up my patch to split the balancer out to its own module. :-) > Move more balancer related classes to hbase-balancer > > > Key: HBASE-25183 > URL: https://issues.apache.org/jira/browse/HBASE-25183 > Project: HBase > Issue Type: Umbrella > Components: Balancer >Reporter: Duo Zhang >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (HBASE-25183) Move more balancer related classes to hbase-balancer
[ https://issues.apache.org/jira/browse/HBASE-25183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17215570#comment-17215570 ] Andrew Kyle Purtell edited comment on HBASE-25183 at 10/16/20, 6:02 PM: I see the conflict has been moved to a thread on private@. I concur that's the best way to proceed, we can keep the discussion here to the technical issues. To me it looks like a misunderstanding (Stack's style is to ask questions, he is not being provocative, he is being genuine with the questioning; but Duo is also entitled to his opinions) and I hope a private mediation will be able to help. was (Author: apurtell): I see the conflict has been moved to a thread on private@. I concur that's the best way to proceed, we can keep the discussion here to the technical issues. > Move more balancer related classes to hbase-balancer > > > Key: HBASE-25183 > URL: https://issues.apache.org/jira/browse/HBASE-25183 > Project: HBase > Issue Type: Umbrella > Components: Balancer >Reporter: Duo Zhang >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (HBASE-25183) Move more balancer related classes to hbase-balancer
[
https://issues.apache.org/jira/browse/HBASE-25183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17214955#comment-17214955
]
Michael Stack edited comment on HBASE-25183 at 10/15/20, 8:56 PM:
--
(Ignoring comments on lack of 'respect' and accusations of 'aggression' or that
I didn't do background reading...)
{quote}Is the motiviation here just shrinking hbase-server module or is there
some other driver?
{quote}
Answering my own question after reading above (correct me if I'm wrong
[~zhangduo]), it seems the refactor of balancer is mainly because we want to
shrink the hbase-server module size. This seems to be the motivation (My
current opinion on the balancer refactor I offer above. I won't repeat).
So, while my work in HBASE-25185, 'is not my[Duos'] plan' regards this issue,
it does help w/ the larger objective of shrinking hbase-server module size by
introducing a new module into which we can start moving classes from
hbase-server, and it addresses another Duo plan for dissolving
MetaTableAccessor (We take a slight step backward on HBASE-23933 because of the
limbo state of favored nodes feature but I'd think it fine given the benefits
introduced).
Presuming the above (shout if I have it wrong [~zhangduo]), I can move off this
issue now that I have gotten what I needed coming here.
-May I have a +1- [~zhangduo] -on HBASE-25185 please?- <= Oh, ignore. I just
saw you had questions on this PR. Let me address. Thanks.
Thanks
was (Author: stack):
(Ignoring comments on lack of 'respect' and accusations of 'aggression' or that
I didn't do background reading...)
bq. Is the motiviation here just shrinking hbase-server module or is there some
other driver?
Answering my own question after reading above (correct me if I'm wrong
[~zhangduo]), it seems the refactor of balancer is mainly because we want to
shrink the hbase-server module size. This seems to be the motivation (My
current opinion on the balancer refactor I offer above. I won't repeat).
So, while my work in HBASE-25185, 'is not my[Duos'] plan' regards this issue,
it does help w/ the larger objective of shrinking hbase-server module size by
introducing a new module into which we can start moving classes from
hbase-server, and it addresses another Duo plan for dissolving
MetaTableAccessor (We take a slight step backward on HBASE-23933 because of the
limbo state of favored nodes feature but I'd think it fine given the benefits
introduced).
Presuming the above (shout if I have it wrong [~zhangduo]), I can move off this
issue now that I have gotten what I needed coming here.
May I have a +1 [~zhangduo] on HBASE-25185 please?
Thanks
> Move more balancer related classes to hbase-balancer
>
>
> Key: HBASE-25183
> URL: https://issues.apache.org/jira/browse/HBASE-25183
> Project: HBase
> Issue Type: Umbrella
> Components: Balancer
>Reporter: Duo Zhang
>Priority: Major
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (HBASE-25183) Move more balancer related classes to hbase-balancer
[ https://issues.apache.org/jira/browse/HBASE-25183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17214880#comment-17214880 ] Andrew Kyle Purtell edited comment on HBASE-25183 at 10/15/20, 6:08 PM: I am supportive of the high level idea of factoring the balancer to be more maintainable. Maybe that would be facilitated by moving it into its own Maven module, maybe not, remains to be seen in the details. My concerns are mostly about how much of server/master internals have to be carried along with the balancer implementation into the other module. Related, say we want to add a new cost function that needs some master internal state to make a decision, must we hack both the balancer and server modules to add it or not. bq. I do not think this is 'a JIRA with no description'. This is an issue with no description as of the time of this comment. JIRA says _Click to add description_ As with anything there is no hard rule here. Simple work doesn't need a description. On the other hand this is a significant refactor of a major piece of functionality and I would expect a reasonable description outlining the motivation, goals, and success criteria for the work. It is the minimum one should expect for collaboration, some kind of description. Sometimes for major work like this a contributor would attach a full design document. When that happens it usually helps. Because we don't make hard rules here strictly speaking some words about the design and goals are not required, only a patch is required, but your risk of a technical veto due to misunderstanding or lack of alignment is much higher if you don't explain your work first. was (Author: apurtell): I am supportive of the high level idea of factoring the balancer to be more maintainable. Maybe that would be facilitated by moving it into its own Maven module, maybe not, remains to be seen in the details. My concerns are mostly about how much of server/master internals have to be carried along with the balancer implementation into the other module. Related, say we want to add a new cost function that needs some master internal state to make a decision, must we hack both the balancer and server modules to add it or not. bq. I do not think this is 'a JIRA with no description'. This is an issue with no description as of the time of this comment. JIRA says _Click to add description_ As with anything there is no hard rule here. Simple work doesn't need a description. On the other hand this is a significant refactor of a major piece of functionality and I would expect a reasonable description outlining the motivation, goals, and success criteria for the work, ideally a full design document. It is the minimum one should expect for collaboration. Because we don't make hard rules here strictly speaking some words about the design and goals are not required, only a patch is required, but your risk of a technical veto due to misunderstanding or lack of alignment is much higher if you don't explain your work first. > Move more balancer related classes to hbase-balancer > > > Key: HBASE-25183 > URL: https://issues.apache.org/jira/browse/HBASE-25183 > Project: HBase > Issue Type: Umbrella > Components: Balancer >Reporter: Duo Zhang >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (HBASE-25183) Move more balancer related classes to hbase-balancer
[
https://issues.apache.org/jira/browse/HBASE-25183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17214402#comment-17214402
]
Michael Stack edited comment on HBASE-25183 at 10/15/20, 3:52 AM:
--
Your favorite question... is there a write-up for this intent anywhere? ('my
plan') So far we have a JIRA with no description. What is the scope, when is
the deliverable for? Why we doing this?
W/o such things I cannot help.
Regards 'algorithm', that sounds grand but that was then. The implication is
that we shuttle to the balancer all that it might ever want from to know from
master and servers? What Regions are on what Servers, current hdfs locality?
Loading? Region sizes?
Why the detachment? To shrink the hbase-server module size? Generally I think
the pickings around balancer are lean. Just leave it w/ intimate access to
Master. Lets pick on something meatier that will make for more yield like
Region?
was (Author: stack):
Your favorite question... is there a write-up for this intent anywhere? So
far we have a JIRA with no description. What is the scope, when is the
deliverable for? Why we doing this?
W/o such things I cannot help.
Regards 'algorithm', that sounds grand but that was then. The implication is
that we shuttle to the balancer all that it might ever want from to know from
master and servers? What Regions are on what Servers, current hdfs locality?
Loading? Region sizes?
Why the detachment? To shrink the hbase-server module size? Generally I think
the pickings around balancer are lean. Just leave it w/ intimate access to
Master. Lets pick on something meatier that will make for more yield like
Region?
> Move more balancer related classes to hbase-balancer
>
>
> Key: HBASE-25183
> URL: https://issues.apache.org/jira/browse/HBASE-25183
> Project: HBase
> Issue Type: Umbrella
> Components: Balancer
>Reporter: Duo Zhang
>Priority: Major
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
