You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@accumulo.apache.org by Christopher <ct...@apache.org> on 2014/11/25 21:08:25 UTC
ACCUMULO-3177 and ACCUMULO-3178
My intention is to, sometime this week, take a thorough look at the patches
and reviews available for ACCUMULO-3177 (create a per-table VolumeChooser)
and ACCUMULO-3178 (example implementation of an alternate
VolumeChooser/test case for ACCUMULO-3177). Given the discussions
surrounding ACCUMULO-3176, and because they originated as the overall
ACCUMULO-3089 (which had some objections that may not have been resolved) I
wanted to give this notice, to ensure that there is opportunity for
objections to occur and be discussed here first.
Presumably, the objections for ACCUMULO-3176 are different from any that
might be held for 3177 and 3178, but there was limited follow-up
clarification of the objections raised after the issues were re-scoped as
separate, more specific, JIRA sub-tasks. So, I'm not sure there are any
still outstanding for those. Since the reviews are still open for those, I
just wanted to invite discussion either here, or (perhaps even better) in
the specific review in ReviewBoard.
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
Re: ACCUMULO-3177 and ACCUMULO-3178
Posted by Christopher <ct...@apache.org>.
Sean,
The normal process is CtR, and lazy consensus. I understand that you've had
time constraints, and that this has been the cause of your inability to
provide a timely review. However, I feel I've been more than fair drawing
this out so that you can have every opportunity to provide a review on your
own timeline. It has been two months since the original review was posted,
and a week and a half since I stated my intentions here, and two days since
I posted a reminder that it had been a week of inactivity.
I can assume good faith all day, but I cannot await for activity on your
part indefinitely. I do not consider a brief comment in JIRA indicating
that you had forgotten to comment the week prior that you were in process
of reviewing, "activity" in any tangible sense which would indicate a
forthcoming response, either, especially since you failed to acknowledge my
direct questions in this thread or provide any review within several hours
after that comment. You also haven't provided any response here in the last
10 days, where I have been explicitly trying to keep you up-to-date and
provide you opportunities to be involved before I pushed the changes. If
you had wished for me to continue to assume good faith, you could have
provided a partial review, or raise one issue at a time, or anything other
than simply hint that something might be eventually forthcoming.
I do not believe it to be in the best interest of the community to expect
such little interactions to bind the hands of other committers to inaction
indefinitely, and it's certainly not fair to our contributors who put
effort into the patch or to users who would like to see these features in a
future release.
For what it's worth, I was very reluctant to push without your explicit
review, but after privately getting advice from 4 other committers as to
how to deal with the unresponsiveness you've shown, I felt that I had no
other choice but to place the ball firmly in your court. By taking the
action I did to push those contributions, I have placed the responsibility
with you to either revert the commits with an explicit veto and explanation
(initiating a consensus vote), or by providing additional feedback/JIRAs
for alterations if you feel changes need to be made. This is the normal
process of development in our community, and as such, I feel it was
entirely appropriate.
You suggest that I should have alternatively contacted you privately or by
updating the JIRA issues... but I don't see how either of those options are
superior to the method I did take, which was to comment in this thread in
which you were participating, publicly and transparently. You also suggest
that I should have requested a hard deadline and expressed my pressing
desire. I believe I've effectively already taken similar actions, in this
thread, both by stating my explicit intentions and by politely requesting a
timely response. You also are fully aware that I did, in fact, privately
contact you by email to request a Google Hangout or phone conversation, so
we could clarify any possible misunderstandings or miscommunications, or as
an opportunity to work out any differences of opinion we might have. You
declined that, in favor of the mailing lists. I also know that you were
explicitly informed that I had made multiple failed attempts to contact you
via IRC. So, you do know that I've made attempts to privately contact you.
And, as a result of all of that, I've been using the mailing lists. Please
don't try to suggest that I could have done more to include you.
This was also not a unilateral action. Not only have the contributions I
pushed received numerous +1s from other committers who did provide timely
reviews, but I also sought advice from other committers before ultimately
pushing.
I feel I've bent over backwards to give you every opportunity to provide
your feedback. I do not see what else I could have done. I think your
expectations for me to have done more are entirely unreasonable. I'm not
aware of any other incident in our community where such great lengths have
been taken to accommodate another developers time. Typically when somebody
is unable to provide a timely review, they don't prevent the other
committer from pushing... they simply review after the fact. This was true
today, even, with the metrics2 changes. I had wished to review those
changes, but since I was unable to get to it in time, I simply expressed my
lament at that fact, and made a note to review it later, when I had time,
because it would have been unreasonable to expect that those changes be
subject to my personal schedule.
If you have an issue with the content of the patches I pushed, please
address them at a technical level, by referring to the actual code. There
is no timeline on that. You're free to address the code at your leisure.
Thank you.
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
On Fri, Dec 5, 2014 at 11:11 PM, Sean Busbey <bu...@cloudera.com> wrote:
> Christopher I said I was still reviewing literally hours before you pushed
> these changes. I also explained that my review was delayed by the
> excessively drawn out discussions that have been happening lately.
>
> This is unbecoming behavior, especially in the light of our recent
> interactions. I appreciate that people have their own timelines they are
> trying to meet, but we are still a community and need to presume others are
> acting in good faith when they say they are still actively working on
> something.
>
> Instead, it would have been more helpful had you either contacted me
> privately or updated tickets to explain your pressing desire to get the
> patches in and asked me for a hard deadline that I could finish by. That
> would have given me the opportunity to decide if I can dedicate the time to
> finish documenting the problems I see in the current patches. Bringing up
> changes now will require asking yet again for the attention of the
> community rather than just a less visible exchange between myself and a new
> contributor.
>
> On Fri, Dec 5, 2014 at 7:12 PM, Christopher <ct...@apache.org> wrote:
>
> > I went ahead and pushed due to lack of activity on this thread, or any
> > noticeable activity in any of the reviews or JIRAs. We're CtR and lazy
> > consensus, and I believe 2 months open since the original patches were
> > published in ReviewBoard, and 10 days since this thread was opened has
> been
> > more than sufficient time for any imminent concerns to have been raised.
> > Any further issues can be addressed in follow-up JIRAs or by initiating a
> > revert with a consensus vote expressing the veto.
> >
> >
> > --
> > Christopher L Tubbs II
> > http://gravatar.com/ctubbsii
> >
> > On Fri, Dec 5, 2014 at 11:13 AM, Christopher <ct...@apache.org>
> wrote:
> >
> > > Sean, I understand if you don't have time to review these now... would
> > you
> > > mind doing so in a follow-up issue, or by exercising a revert if you
> see
> > an
> > > issue with them? I think it's reasonable to go ahead and push these
> > changes
> > > now.
> > >
> > >
> > > --
> > > Christopher L Tubbs II
> > > http://gravatar.com/ctubbsii
> > >
> > > On Thu, Dec 4, 2014 at 5:47 PM, Christopher <ct...@apache.org>
> wrote:
> > >
> > >> Last update on this thread was over a week ago. Jenna was kind enough
> to
> > >> squash in my reviews (which were essentially provided to her as a
> patch
> > on
> > >> top of her patch via GitHub). She has updated the ReviewBoard entries,
> > and
> > >> I have commented with my +1.
> > >>
> > >>
> > >> --
> > >> Christopher L Tubbs II
> > >> http://gravatar.com/ctubbsii
> > >>
> > >> On Wed, Nov 26, 2014 at 4:12 PM, Christopher <ct...@apache.org>
> > wrote:
> > >>
> > >>> On Wed, Nov 26, 2014 at 3:07 PM, Sean Busbey <bu...@cloudera.com>
> > >>> wrote:
> > >>>
> > >>>> I will be as timely as I can.
> > >>>>
> > >>>> Thanks. However, please understand that if you are unable to respond
> > >>> timely, progress can/should/will proceed without you. I just want to
> > make
> > >>> sure you have opportunity.
> > >>>
> > >>>
> > >>>> Please keep in mind that our community is volunteer based, people
> > have a
> > >>>> multitude of commitments, and it is a holiday week.
> > >>>>
> > >>>>
> > >>> Sure, I just want to make sure you have ample time to review and we
> can
> > >>> address any objections you may have (if you still have any), but I
> want
> > >>> some time constraint, so these contributions don't sit idle
> > indefinitely
> > >>> (that's not fair to the contributor, or to those who'd like to
> leverage
> > >>> these features). As long as the discussion is active
> (holidays/weekends
> > >>> considered, of course), I will not attempt to push.
> > >>>
> > >>>
> > >>>> I had presumed more feedback wasn't pressing since no one had
> > mentioned
> > >>>> on
> > >>>> the tickets how my original concerns were addressed by the revamps.
> If
> > >>>> someone could give me a summary on each it would make things go much
> > >>>> faster.
> > >>>>
> > >>>>
> > >>> Your feedback is pressing because you're the only one who expressed
> > >>> concerns, and I want to make sure you have ample opportunity to be
> > >>> involved. But, I don't want it to wait forever. I did believe I had
> > >>> responded sufficiently to your questions/concerns... but if there's
> > still
> > >>> something outstanding that I have not answered or addressed, please
> > raise
> > >>> it again, explicitly, and in the context of the proposed changes, so
> I
> > can
> > >>> respond to it.
> > >>>
> > >>> Sure, I can give you a summary as I understand it:
> > >>>
> > >>> Overview of the issues:
> > >>>
> > >>> ACCUMULO-3177: Adds a per-table VolumeChooser to replace the
> > >>> RandomVolumeChooser as the default VolumeChooser, with the default
> > >>> per-table implementation (a new per-table property is added for this)
> > is
> > >>> now the RandomVolumeChooser. This is modeled after the per-table
> > balancer.
> > >>> The intent is to enable balancing decisions for a tablet's persistent
> > >>> storage across volumes in the same way we allow balancing tablet's
> > >>> "compute" operations across Tablet Servers. To do this, a
> > >>> "VolumeChooserEnvironment" object is created and added to the chooser
> > API,
> > >>> which exposes the environment to the chooser (such as the tableId,
> from
> > >>> which the namespace can be retrieved, etc.)
> > >>>
> > >>> ACCUMULO-3178: Adds an additional example/reference implementation
> for
> > a
> > >>> per-table VolumeChooser, called a "PreferredVolumeChooser", which
> > allows
> > >>> users to specify a specific volume (or set of volumes) in a custom
> > >>> per-table property. This is used as a test case (integration test)
> for
> > >>> ACCUMULO-3177. (Note: your original concerns about deduplication of
> > HDFS's
> > >>> HSM effort expressed in ACCUMULO-3089 seem to apply only to this
> > issue, not
> > >>> to ACCUMULO-3177; however, my hope is that you'll see that this is
> > >>> sufficiently unrelated to that, that your original objections do not
> > apply.)
> > >>>
> > >>> Also, some background (from my perspective):
> > >>>
> > >>> Recall: As explained on ACCUMULO-3089, your original concerns were
> > >>> addressed by splitting the original issue into separate tasks, to
> help
> > >>> clarify the scope and intentions of that issue with more narrowly
> > defined
> > >>> changesets. You were requested to explain your objections
> specifically
> > in
> > >>> the context of the changesets on those tasks, because I believed you
> to
> > >>> have misunderstood the scope of the issue (as I stated on
> > ACCUMULO-3089),
> > >>> and I hoped that doing so would help clarify where your objections
> > were, in
> > >>> relation to the proposed code changes. As far as I can tell, you did
> do
> > >>> that, with your comments on the subsequent issues.
> > >>>
> > >>> You commented on ACCUMULO-3177, suggesting that it might be better to
> > >>> apply the configuration property on a namespace instead of a table. I
> > >>> responded to that comment with an explanation of how table and
> > namespace
> > >>> configurations work in this context. As such, I hold that your
> comment
> > >>> represents a recommended "best practice" for table management
> > >>> (specifically, limiting the granting of ALTER_TABLE), but not an
> > objection
> > >>> to the table/namespace configuration-based implementation/addition
> > itself.
> > >>>
> > >>> You have also commented on ACCUMULO-3178, with an indication that you
> > >>> did not feel that the VolumeChooser interface itself was strictly
> > "public
> > >>> API", which I took to mean that you'd be more flexible in tolerating
> > >>> changes to that API with a higher degree of risk. I did not see an
> > >>> objection to ACCUMULO-3178, but it does depend on ACCUMULO-3177. You
> > also
> > >>> suggested not making these dependent on ACCUMULO-3176 (because of the
> > >>> presence of a limited workaround by adding configuration to a
> namespace
> > >>> first), a request which was accommodated (but ultimately unnecessary
> if
> > >>> ACCUMULO-3176 is permitted) in a separate review which you did not
> > comment
> > >>> on after requesting it to be made.
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>> --
> > >>>> Sean
> > >>>> On Nov 26, 2014 12:27 PM, "Christopher" <ct...@apache.org>
> wrote:
> > >>>>
> > >>>> > Thank you for your response. I request that you please be timely,
> as
> > >>>> these
> > >>>> > issues have sat idle for a long time, and the maintenance burden
> of
> > >>>> keeping
> > >>>> > them current with the HEAD of master is becoming excessive. I
> await
> > >>>> your
> > >>>> > reviews/objections. Thanks.
> > >>>> >
> > >>>> >
> > >>>> > --
> > >>>> > Christopher L Tubbs II
> > >>>> > http://gravatar.com/ctubbsii
> > >>>> >
> > >>>> > On Wed, Nov 26, 2014 at 11:30 AM, Sean Busbey <
> busbey@cloudera.com>
> > >>>> wrote:
> > >>>> >
> > >>>> > > I will follow up on both of those tickets with my objections,
> > >>>> please do
> > >>>> > not
> > >>>> > > apply them.
> > >>>> > >
> > >>>> > > On Tue, Nov 25, 2014 at 2:08 PM, Christopher <
> ctubbsii@apache.org
> > >
> > >>>> > wrote:
> > >>>> > >
> > >>>> > > > My intention is to, sometime this week, take a thorough look
> at
> > >>>> the
> > >>>> > > patches
> > >>>> > > > and reviews available for ACCUMULO-3177 (create a per-table
> > >>>> > > VolumeChooser)
> > >>>> > > > and ACCUMULO-3178 (example implementation of an alternate
> > >>>> > > > VolumeChooser/test case for ACCUMULO-3177). Given the
> > discussions
> > >>>> > > > surrounding ACCUMULO-3176, and because they originated as the
> > >>>> overall
> > >>>> > > > ACCUMULO-3089 (which had some objections that may not have
> been
> > >>>> > > resolved) I
> > >>>> > > > wanted to give this notice, to ensure that there is
> opportunity
> > >>>> for
> > >>>> > > > objections to occur and be discussed here first.
> > >>>> > > >
> > >>>> > > > Presumably, the objections for ACCUMULO-3176 are different
> from
> > >>>> any
> > >>>> > that
> > >>>> > > > might be held for 3177 and 3178, but there was limited
> follow-up
> > >>>> > > > clarification of the objections raised after the issues were
> > >>>> re-scoped
> > >>>> > as
> > >>>> > > > separate, more specific, JIRA sub-tasks. So, I'm not sure
> there
> > >>>> are any
> > >>>> > > > still outstanding for those. Since the reviews are still open
> > for
> > >>>> > those,
> > >>>> > > I
> > >>>> > > > just wanted to invite discussion either here, or (perhaps even
> > >>>> better)
> > >>>> > in
> > >>>> > > > the specific review in ReviewBoard.
> > >>>> > > >
> > >>>> > > > --
> > >>>> > > > Christopher L Tubbs II
> > >>>> > > > http://gravatar.com/ctubbsii
> > >>>> > > >
> > >>>> > >
> > >>>> > >
> > >>>> > >
> > >>>> > > --
> > >>>> > > Sean
> > >>>> > >
> > >>>> >
> > >>>>
> > >>>
> > >>>
> > >>
> > >
> >
>
>
>
> --
> Sean
>
Re: ACCUMULO-3177 and ACCUMULO-3178
Posted by Sean Busbey <bu...@cloudera.com>.
Christopher I said I was still reviewing literally hours before you pushed
these changes. I also explained that my review was delayed by the
excessively drawn out discussions that have been happening lately.
This is unbecoming behavior, especially in the light of our recent
interactions. I appreciate that people have their own timelines they are
trying to meet, but we are still a community and need to presume others are
acting in good faith when they say they are still actively working on
something.
Instead, it would have been more helpful had you either contacted me
privately or updated tickets to explain your pressing desire to get the
patches in and asked me for a hard deadline that I could finish by. That
would have given me the opportunity to decide if I can dedicate the time to
finish documenting the problems I see in the current patches. Bringing up
changes now will require asking yet again for the attention of the
community rather than just a less visible exchange between myself and a new
contributor.
On Fri, Dec 5, 2014 at 7:12 PM, Christopher <ct...@apache.org> wrote:
> I went ahead and pushed due to lack of activity on this thread, or any
> noticeable activity in any of the reviews or JIRAs. We're CtR and lazy
> consensus, and I believe 2 months open since the original patches were
> published in ReviewBoard, and 10 days since this thread was opened has been
> more than sufficient time for any imminent concerns to have been raised.
> Any further issues can be addressed in follow-up JIRAs or by initiating a
> revert with a consensus vote expressing the veto.
>
>
> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii
>
> On Fri, Dec 5, 2014 at 11:13 AM, Christopher <ct...@apache.org> wrote:
>
> > Sean, I understand if you don't have time to review these now... would
> you
> > mind doing so in a follow-up issue, or by exercising a revert if you see
> an
> > issue with them? I think it's reasonable to go ahead and push these
> changes
> > now.
> >
> >
> > --
> > Christopher L Tubbs II
> > http://gravatar.com/ctubbsii
> >
> > On Thu, Dec 4, 2014 at 5:47 PM, Christopher <ct...@apache.org> wrote:
> >
> >> Last update on this thread was over a week ago. Jenna was kind enough to
> >> squash in my reviews (which were essentially provided to her as a patch
> on
> >> top of her patch via GitHub). She has updated the ReviewBoard entries,
> and
> >> I have commented with my +1.
> >>
> >>
> >> --
> >> Christopher L Tubbs II
> >> http://gravatar.com/ctubbsii
> >>
> >> On Wed, Nov 26, 2014 at 4:12 PM, Christopher <ct...@apache.org>
> wrote:
> >>
> >>> On Wed, Nov 26, 2014 at 3:07 PM, Sean Busbey <bu...@cloudera.com>
> >>> wrote:
> >>>
> >>>> I will be as timely as I can.
> >>>>
> >>>> Thanks. However, please understand that if you are unable to respond
> >>> timely, progress can/should/will proceed without you. I just want to
> make
> >>> sure you have opportunity.
> >>>
> >>>
> >>>> Please keep in mind that our community is volunteer based, people
> have a
> >>>> multitude of commitments, and it is a holiday week.
> >>>>
> >>>>
> >>> Sure, I just want to make sure you have ample time to review and we can
> >>> address any objections you may have (if you still have any), but I want
> >>> some time constraint, so these contributions don't sit idle
> indefinitely
> >>> (that's not fair to the contributor, or to those who'd like to leverage
> >>> these features). As long as the discussion is active (holidays/weekends
> >>> considered, of course), I will not attempt to push.
> >>>
> >>>
> >>>> I had presumed more feedback wasn't pressing since no one had
> mentioned
> >>>> on
> >>>> the tickets how my original concerns were addressed by the revamps. If
> >>>> someone could give me a summary on each it would make things go much
> >>>> faster.
> >>>>
> >>>>
> >>> Your feedback is pressing because you're the only one who expressed
> >>> concerns, and I want to make sure you have ample opportunity to be
> >>> involved. But, I don't want it to wait forever. I did believe I had
> >>> responded sufficiently to your questions/concerns... but if there's
> still
> >>> something outstanding that I have not answered or addressed, please
> raise
> >>> it again, explicitly, and in the context of the proposed changes, so I
> can
> >>> respond to it.
> >>>
> >>> Sure, I can give you a summary as I understand it:
> >>>
> >>> Overview of the issues:
> >>>
> >>> ACCUMULO-3177: Adds a per-table VolumeChooser to replace the
> >>> RandomVolumeChooser as the default VolumeChooser, with the default
> >>> per-table implementation (a new per-table property is added for this)
> is
> >>> now the RandomVolumeChooser. This is modeled after the per-table
> balancer.
> >>> The intent is to enable balancing decisions for a tablet's persistent
> >>> storage across volumes in the same way we allow balancing tablet's
> >>> "compute" operations across Tablet Servers. To do this, a
> >>> "VolumeChooserEnvironment" object is created and added to the chooser
> API,
> >>> which exposes the environment to the chooser (such as the tableId, from
> >>> which the namespace can be retrieved, etc.)
> >>>
> >>> ACCUMULO-3178: Adds an additional example/reference implementation for
> a
> >>> per-table VolumeChooser, called a "PreferredVolumeChooser", which
> allows
> >>> users to specify a specific volume (or set of volumes) in a custom
> >>> per-table property. This is used as a test case (integration test) for
> >>> ACCUMULO-3177. (Note: your original concerns about deduplication of
> HDFS's
> >>> HSM effort expressed in ACCUMULO-3089 seem to apply only to this
> issue, not
> >>> to ACCUMULO-3177; however, my hope is that you'll see that this is
> >>> sufficiently unrelated to that, that your original objections do not
> apply.)
> >>>
> >>> Also, some background (from my perspective):
> >>>
> >>> Recall: As explained on ACCUMULO-3089, your original concerns were
> >>> addressed by splitting the original issue into separate tasks, to help
> >>> clarify the scope and intentions of that issue with more narrowly
> defined
> >>> changesets. You were requested to explain your objections specifically
> in
> >>> the context of the changesets on those tasks, because I believed you to
> >>> have misunderstood the scope of the issue (as I stated on
> ACCUMULO-3089),
> >>> and I hoped that doing so would help clarify where your objections
> were, in
> >>> relation to the proposed code changes. As far as I can tell, you did do
> >>> that, with your comments on the subsequent issues.
> >>>
> >>> You commented on ACCUMULO-3177, suggesting that it might be better to
> >>> apply the configuration property on a namespace instead of a table. I
> >>> responded to that comment with an explanation of how table and
> namespace
> >>> configurations work in this context. As such, I hold that your comment
> >>> represents a recommended "best practice" for table management
> >>> (specifically, limiting the granting of ALTER_TABLE), but not an
> objection
> >>> to the table/namespace configuration-based implementation/addition
> itself.
> >>>
> >>> You have also commented on ACCUMULO-3178, with an indication that you
> >>> did not feel that the VolumeChooser interface itself was strictly
> "public
> >>> API", which I took to mean that you'd be more flexible in tolerating
> >>> changes to that API with a higher degree of risk. I did not see an
> >>> objection to ACCUMULO-3178, but it does depend on ACCUMULO-3177. You
> also
> >>> suggested not making these dependent on ACCUMULO-3176 (because of the
> >>> presence of a limited workaround by adding configuration to a namespace
> >>> first), a request which was accommodated (but ultimately unnecessary if
> >>> ACCUMULO-3176 is permitted) in a separate review which you did not
> comment
> >>> on after requesting it to be made.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>> --
> >>>> Sean
> >>>> On Nov 26, 2014 12:27 PM, "Christopher" <ct...@apache.org> wrote:
> >>>>
> >>>> > Thank you for your response. I request that you please be timely, as
> >>>> these
> >>>> > issues have sat idle for a long time, and the maintenance burden of
> >>>> keeping
> >>>> > them current with the HEAD of master is becoming excessive. I await
> >>>> your
> >>>> > reviews/objections. Thanks.
> >>>> >
> >>>> >
> >>>> > --
> >>>> > Christopher L Tubbs II
> >>>> > http://gravatar.com/ctubbsii
> >>>> >
> >>>> > On Wed, Nov 26, 2014 at 11:30 AM, Sean Busbey <bu...@cloudera.com>
> >>>> wrote:
> >>>> >
> >>>> > > I will follow up on both of those tickets with my objections,
> >>>> please do
> >>>> > not
> >>>> > > apply them.
> >>>> > >
> >>>> > > On Tue, Nov 25, 2014 at 2:08 PM, Christopher <ctubbsii@apache.org
> >
> >>>> > wrote:
> >>>> > >
> >>>> > > > My intention is to, sometime this week, take a thorough look at
> >>>> the
> >>>> > > patches
> >>>> > > > and reviews available for ACCUMULO-3177 (create a per-table
> >>>> > > VolumeChooser)
> >>>> > > > and ACCUMULO-3178 (example implementation of an alternate
> >>>> > > > VolumeChooser/test case for ACCUMULO-3177). Given the
> discussions
> >>>> > > > surrounding ACCUMULO-3176, and because they originated as the
> >>>> overall
> >>>> > > > ACCUMULO-3089 (which had some objections that may not have been
> >>>> > > resolved) I
> >>>> > > > wanted to give this notice, to ensure that there is opportunity
> >>>> for
> >>>> > > > objections to occur and be discussed here first.
> >>>> > > >
> >>>> > > > Presumably, the objections for ACCUMULO-3176 are different from
> >>>> any
> >>>> > that
> >>>> > > > might be held for 3177 and 3178, but there was limited follow-up
> >>>> > > > clarification of the objections raised after the issues were
> >>>> re-scoped
> >>>> > as
> >>>> > > > separate, more specific, JIRA sub-tasks. So, I'm not sure there
> >>>> are any
> >>>> > > > still outstanding for those. Since the reviews are still open
> for
> >>>> > those,
> >>>> > > I
> >>>> > > > just wanted to invite discussion either here, or (perhaps even
> >>>> better)
> >>>> > in
> >>>> > > > the specific review in ReviewBoard.
> >>>> > > >
> >>>> > > > --
> >>>> > > > Christopher L Tubbs II
> >>>> > > > http://gravatar.com/ctubbsii
> >>>> > > >
> >>>> > >
> >>>> > >
> >>>> > >
> >>>> > > --
> >>>> > > Sean
> >>>> > >
> >>>> >
> >>>>
> >>>
> >>>
> >>
> >
>
--
Sean
Re: ACCUMULO-3177 and ACCUMULO-3178
Posted by Christopher <ct...@apache.org>.
I went ahead and pushed due to lack of activity on this thread, or any
noticeable activity in any of the reviews or JIRAs. We're CtR and lazy
consensus, and I believe 2 months open since the original patches were
published in ReviewBoard, and 10 days since this thread was opened has been
more than sufficient time for any imminent concerns to have been raised.
Any further issues can be addressed in follow-up JIRAs or by initiating a
revert with a consensus vote expressing the veto.
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
On Fri, Dec 5, 2014 at 11:13 AM, Christopher <ct...@apache.org> wrote:
> Sean, I understand if you don't have time to review these now... would you
> mind doing so in a follow-up issue, or by exercising a revert if you see an
> issue with them? I think it's reasonable to go ahead and push these changes
> now.
>
>
> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii
>
> On Thu, Dec 4, 2014 at 5:47 PM, Christopher <ct...@apache.org> wrote:
>
>> Last update on this thread was over a week ago. Jenna was kind enough to
>> squash in my reviews (which were essentially provided to her as a patch on
>> top of her patch via GitHub). She has updated the ReviewBoard entries, and
>> I have commented with my +1.
>>
>>
>> --
>> Christopher L Tubbs II
>> http://gravatar.com/ctubbsii
>>
>> On Wed, Nov 26, 2014 at 4:12 PM, Christopher <ct...@apache.org> wrote:
>>
>>> On Wed, Nov 26, 2014 at 3:07 PM, Sean Busbey <bu...@cloudera.com>
>>> wrote:
>>>
>>>> I will be as timely as I can.
>>>>
>>>> Thanks. However, please understand that if you are unable to respond
>>> timely, progress can/should/will proceed without you. I just want to make
>>> sure you have opportunity.
>>>
>>>
>>>> Please keep in mind that our community is volunteer based, people have a
>>>> multitude of commitments, and it is a holiday week.
>>>>
>>>>
>>> Sure, I just want to make sure you have ample time to review and we can
>>> address any objections you may have (if you still have any), but I want
>>> some time constraint, so these contributions don't sit idle indefinitely
>>> (that's not fair to the contributor, or to those who'd like to leverage
>>> these features). As long as the discussion is active (holidays/weekends
>>> considered, of course), I will not attempt to push.
>>>
>>>
>>>> I had presumed more feedback wasn't pressing since no one had mentioned
>>>> on
>>>> the tickets how my original concerns were addressed by the revamps. If
>>>> someone could give me a summary on each it would make things go much
>>>> faster.
>>>>
>>>>
>>> Your feedback is pressing because you're the only one who expressed
>>> concerns, and I want to make sure you have ample opportunity to be
>>> involved. But, I don't want it to wait forever. I did believe I had
>>> responded sufficiently to your questions/concerns... but if there's still
>>> something outstanding that I have not answered or addressed, please raise
>>> it again, explicitly, and in the context of the proposed changes, so I can
>>> respond to it.
>>>
>>> Sure, I can give you a summary as I understand it:
>>>
>>> Overview of the issues:
>>>
>>> ACCUMULO-3177: Adds a per-table VolumeChooser to replace the
>>> RandomVolumeChooser as the default VolumeChooser, with the default
>>> per-table implementation (a new per-table property is added for this) is
>>> now the RandomVolumeChooser. This is modeled after the per-table balancer.
>>> The intent is to enable balancing decisions for a tablet's persistent
>>> storage across volumes in the same way we allow balancing tablet's
>>> "compute" operations across Tablet Servers. To do this, a
>>> "VolumeChooserEnvironment" object is created and added to the chooser API,
>>> which exposes the environment to the chooser (such as the tableId, from
>>> which the namespace can be retrieved, etc.)
>>>
>>> ACCUMULO-3178: Adds an additional example/reference implementation for a
>>> per-table VolumeChooser, called a "PreferredVolumeChooser", which allows
>>> users to specify a specific volume (or set of volumes) in a custom
>>> per-table property. This is used as a test case (integration test) for
>>> ACCUMULO-3177. (Note: your original concerns about deduplication of HDFS's
>>> HSM effort expressed in ACCUMULO-3089 seem to apply only to this issue, not
>>> to ACCUMULO-3177; however, my hope is that you'll see that this is
>>> sufficiently unrelated to that, that your original objections do not apply.)
>>>
>>> Also, some background (from my perspective):
>>>
>>> Recall: As explained on ACCUMULO-3089, your original concerns were
>>> addressed by splitting the original issue into separate tasks, to help
>>> clarify the scope and intentions of that issue with more narrowly defined
>>> changesets. You were requested to explain your objections specifically in
>>> the context of the changesets on those tasks, because I believed you to
>>> have misunderstood the scope of the issue (as I stated on ACCUMULO-3089),
>>> and I hoped that doing so would help clarify where your objections were, in
>>> relation to the proposed code changes. As far as I can tell, you did do
>>> that, with your comments on the subsequent issues.
>>>
>>> You commented on ACCUMULO-3177, suggesting that it might be better to
>>> apply the configuration property on a namespace instead of a table. I
>>> responded to that comment with an explanation of how table and namespace
>>> configurations work in this context. As such, I hold that your comment
>>> represents a recommended "best practice" for table management
>>> (specifically, limiting the granting of ALTER_TABLE), but not an objection
>>> to the table/namespace configuration-based implementation/addition itself.
>>>
>>> You have also commented on ACCUMULO-3178, with an indication that you
>>> did not feel that the VolumeChooser interface itself was strictly "public
>>> API", which I took to mean that you'd be more flexible in tolerating
>>> changes to that API with a higher degree of risk. I did not see an
>>> objection to ACCUMULO-3178, but it does depend on ACCUMULO-3177. You also
>>> suggested not making these dependent on ACCUMULO-3176 (because of the
>>> presence of a limited workaround by adding configuration to a namespace
>>> first), a request which was accommodated (but ultimately unnecessary if
>>> ACCUMULO-3176 is permitted) in a separate review which you did not comment
>>> on after requesting it to be made.
>>>
>>>
>>>
>>>
>>>
>>>> --
>>>> Sean
>>>> On Nov 26, 2014 12:27 PM, "Christopher" <ct...@apache.org> wrote:
>>>>
>>>> > Thank you for your response. I request that you please be timely, as
>>>> these
>>>> > issues have sat idle for a long time, and the maintenance burden of
>>>> keeping
>>>> > them current with the HEAD of master is becoming excessive. I await
>>>> your
>>>> > reviews/objections. Thanks.
>>>> >
>>>> >
>>>> > --
>>>> > Christopher L Tubbs II
>>>> > http://gravatar.com/ctubbsii
>>>> >
>>>> > On Wed, Nov 26, 2014 at 11:30 AM, Sean Busbey <bu...@cloudera.com>
>>>> wrote:
>>>> >
>>>> > > I will follow up on both of those tickets with my objections,
>>>> please do
>>>> > not
>>>> > > apply them.
>>>> > >
>>>> > > On Tue, Nov 25, 2014 at 2:08 PM, Christopher <ct...@apache.org>
>>>> > wrote:
>>>> > >
>>>> > > > My intention is to, sometime this week, take a thorough look at
>>>> the
>>>> > > patches
>>>> > > > and reviews available for ACCUMULO-3177 (create a per-table
>>>> > > VolumeChooser)
>>>> > > > and ACCUMULO-3178 (example implementation of an alternate
>>>> > > > VolumeChooser/test case for ACCUMULO-3177). Given the discussions
>>>> > > > surrounding ACCUMULO-3176, and because they originated as the
>>>> overall
>>>> > > > ACCUMULO-3089 (which had some objections that may not have been
>>>> > > resolved) I
>>>> > > > wanted to give this notice, to ensure that there is opportunity
>>>> for
>>>> > > > objections to occur and be discussed here first.
>>>> > > >
>>>> > > > Presumably, the objections for ACCUMULO-3176 are different from
>>>> any
>>>> > that
>>>> > > > might be held for 3177 and 3178, but there was limited follow-up
>>>> > > > clarification of the objections raised after the issues were
>>>> re-scoped
>>>> > as
>>>> > > > separate, more specific, JIRA sub-tasks. So, I'm not sure there
>>>> are any
>>>> > > > still outstanding for those. Since the reviews are still open for
>>>> > those,
>>>> > > I
>>>> > > > just wanted to invite discussion either here, or (perhaps even
>>>> better)
>>>> > in
>>>> > > > the specific review in ReviewBoard.
>>>> > > >
>>>> > > > --
>>>> > > > Christopher L Tubbs II
>>>> > > > http://gravatar.com/ctubbsii
>>>> > > >
>>>> > >
>>>> > >
>>>> > >
>>>> > > --
>>>> > > Sean
>>>> > >
>>>> >
>>>>
>>>
>>>
>>
>
Re: ACCUMULO-3177 and ACCUMULO-3178
Posted by Christopher <ct...@apache.org>.
Sean, I understand if you don't have time to review these now... would you
mind doing so in a follow-up issue, or by exercising a revert if you see an
issue with them? I think it's reasonable to go ahead and push these changes
now.
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
On Thu, Dec 4, 2014 at 5:47 PM, Christopher <ct...@apache.org> wrote:
> Last update on this thread was over a week ago. Jenna was kind enough to
> squash in my reviews (which were essentially provided to her as a patch on
> top of her patch via GitHub). She has updated the ReviewBoard entries, and
> I have commented with my +1.
>
>
> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii
>
> On Wed, Nov 26, 2014 at 4:12 PM, Christopher <ct...@apache.org> wrote:
>
>> On Wed, Nov 26, 2014 at 3:07 PM, Sean Busbey <bu...@cloudera.com> wrote:
>>
>>> I will be as timely as I can.
>>>
>>> Thanks. However, please understand that if you are unable to respond
>> timely, progress can/should/will proceed without you. I just want to make
>> sure you have opportunity.
>>
>>
>>> Please keep in mind that our community is volunteer based, people have a
>>> multitude of commitments, and it is a holiday week.
>>>
>>>
>> Sure, I just want to make sure you have ample time to review and we can
>> address any objections you may have (if you still have any), but I want
>> some time constraint, so these contributions don't sit idle indefinitely
>> (that's not fair to the contributor, or to those who'd like to leverage
>> these features). As long as the discussion is active (holidays/weekends
>> considered, of course), I will not attempt to push.
>>
>>
>>> I had presumed more feedback wasn't pressing since no one had mentioned
>>> on
>>> the tickets how my original concerns were addressed by the revamps. If
>>> someone could give me a summary on each it would make things go much
>>> faster.
>>>
>>>
>> Your feedback is pressing because you're the only one who expressed
>> concerns, and I want to make sure you have ample opportunity to be
>> involved. But, I don't want it to wait forever. I did believe I had
>> responded sufficiently to your questions/concerns... but if there's still
>> something outstanding that I have not answered or addressed, please raise
>> it again, explicitly, and in the context of the proposed changes, so I can
>> respond to it.
>>
>> Sure, I can give you a summary as I understand it:
>>
>> Overview of the issues:
>>
>> ACCUMULO-3177: Adds a per-table VolumeChooser to replace the
>> RandomVolumeChooser as the default VolumeChooser, with the default
>> per-table implementation (a new per-table property is added for this) is
>> now the RandomVolumeChooser. This is modeled after the per-table balancer.
>> The intent is to enable balancing decisions for a tablet's persistent
>> storage across volumes in the same way we allow balancing tablet's
>> "compute" operations across Tablet Servers. To do this, a
>> "VolumeChooserEnvironment" object is created and added to the chooser API,
>> which exposes the environment to the chooser (such as the tableId, from
>> which the namespace can be retrieved, etc.)
>>
>> ACCUMULO-3178: Adds an additional example/reference implementation for a
>> per-table VolumeChooser, called a "PreferredVolumeChooser", which allows
>> users to specify a specific volume (or set of volumes) in a custom
>> per-table property. This is used as a test case (integration test) for
>> ACCUMULO-3177. (Note: your original concerns about deduplication of HDFS's
>> HSM effort expressed in ACCUMULO-3089 seem to apply only to this issue, not
>> to ACCUMULO-3177; however, my hope is that you'll see that this is
>> sufficiently unrelated to that, that your original objections do not apply.)
>>
>> Also, some background (from my perspective):
>>
>> Recall: As explained on ACCUMULO-3089, your original concerns were
>> addressed by splitting the original issue into separate tasks, to help
>> clarify the scope and intentions of that issue with more narrowly defined
>> changesets. You were requested to explain your objections specifically in
>> the context of the changesets on those tasks, because I believed you to
>> have misunderstood the scope of the issue (as I stated on ACCUMULO-3089),
>> and I hoped that doing so would help clarify where your objections were, in
>> relation to the proposed code changes. As far as I can tell, you did do
>> that, with your comments on the subsequent issues.
>>
>> You commented on ACCUMULO-3177, suggesting that it might be better to
>> apply the configuration property on a namespace instead of a table. I
>> responded to that comment with an explanation of how table and namespace
>> configurations work in this context. As such, I hold that your comment
>> represents a recommended "best practice" for table management
>> (specifically, limiting the granting of ALTER_TABLE), but not an objection
>> to the table/namespace configuration-based implementation/addition itself.
>>
>> You have also commented on ACCUMULO-3178, with an indication that you did
>> not feel that the VolumeChooser interface itself was strictly "public API",
>> which I took to mean that you'd be more flexible in tolerating changes to
>> that API with a higher degree of risk. I did not see an objection to
>> ACCUMULO-3178, but it does depend on ACCUMULO-3177. You also suggested not
>> making these dependent on ACCUMULO-3176 (because of the presence of a
>> limited workaround by adding configuration to a namespace first), a request
>> which was accommodated (but ultimately unnecessary if ACCUMULO-3176 is
>> permitted) in a separate review which you did not comment on after
>> requesting it to be made.
>>
>>
>>
>>
>>
>>> --
>>> Sean
>>> On Nov 26, 2014 12:27 PM, "Christopher" <ct...@apache.org> wrote:
>>>
>>> > Thank you for your response. I request that you please be timely, as
>>> these
>>> > issues have sat idle for a long time, and the maintenance burden of
>>> keeping
>>> > them current with the HEAD of master is becoming excessive. I await
>>> your
>>> > reviews/objections. Thanks.
>>> >
>>> >
>>> > --
>>> > Christopher L Tubbs II
>>> > http://gravatar.com/ctubbsii
>>> >
>>> > On Wed, Nov 26, 2014 at 11:30 AM, Sean Busbey <bu...@cloudera.com>
>>> wrote:
>>> >
>>> > > I will follow up on both of those tickets with my objections, please
>>> do
>>> > not
>>> > > apply them.
>>> > >
>>> > > On Tue, Nov 25, 2014 at 2:08 PM, Christopher <ct...@apache.org>
>>> > wrote:
>>> > >
>>> > > > My intention is to, sometime this week, take a thorough look at the
>>> > > patches
>>> > > > and reviews available for ACCUMULO-3177 (create a per-table
>>> > > VolumeChooser)
>>> > > > and ACCUMULO-3178 (example implementation of an alternate
>>> > > > VolumeChooser/test case for ACCUMULO-3177). Given the discussions
>>> > > > surrounding ACCUMULO-3176, and because they originated as the
>>> overall
>>> > > > ACCUMULO-3089 (which had some objections that may not have been
>>> > > resolved) I
>>> > > > wanted to give this notice, to ensure that there is opportunity for
>>> > > > objections to occur and be discussed here first.
>>> > > >
>>> > > > Presumably, the objections for ACCUMULO-3176 are different from any
>>> > that
>>> > > > might be held for 3177 and 3178, but there was limited follow-up
>>> > > > clarification of the objections raised after the issues were
>>> re-scoped
>>> > as
>>> > > > separate, more specific, JIRA sub-tasks. So, I'm not sure there
>>> are any
>>> > > > still outstanding for those. Since the reviews are still open for
>>> > those,
>>> > > I
>>> > > > just wanted to invite discussion either here, or (perhaps even
>>> better)
>>> > in
>>> > > > the specific review in ReviewBoard.
>>> > > >
>>> > > > --
>>> > > > Christopher L Tubbs II
>>> > > > http://gravatar.com/ctubbsii
>>> > > >
>>> > >
>>> > >
>>> > >
>>> > > --
>>> > > Sean
>>> > >
>>> >
>>>
>>
>>
>
Re: ACCUMULO-3177 and ACCUMULO-3178
Posted by Christopher <ct...@apache.org>.
Last update on this thread was over a week ago. Jenna was kind enough to
squash in my reviews (which were essentially provided to her as a patch on
top of her patch via GitHub). She has updated the ReviewBoard entries, and
I have commented with my +1.
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
On Wed, Nov 26, 2014 at 4:12 PM, Christopher <ct...@apache.org> wrote:
> On Wed, Nov 26, 2014 at 3:07 PM, Sean Busbey <bu...@cloudera.com> wrote:
>
>> I will be as timely as I can.
>>
>> Thanks. However, please understand that if you are unable to respond
> timely, progress can/should/will proceed without you. I just want to make
> sure you have opportunity.
>
>
>> Please keep in mind that our community is volunteer based, people have a
>> multitude of commitments, and it is a holiday week.
>>
>>
> Sure, I just want to make sure you have ample time to review and we can
> address any objections you may have (if you still have any), but I want
> some time constraint, so these contributions don't sit idle indefinitely
> (that's not fair to the contributor, or to those who'd like to leverage
> these features). As long as the discussion is active (holidays/weekends
> considered, of course), I will not attempt to push.
>
>
>> I had presumed more feedback wasn't pressing since no one had mentioned on
>> the tickets how my original concerns were addressed by the revamps. If
>> someone could give me a summary on each it would make things go much
>> faster.
>>
>>
> Your feedback is pressing because you're the only one who expressed
> concerns, and I want to make sure you have ample opportunity to be
> involved. But, I don't want it to wait forever. I did believe I had
> responded sufficiently to your questions/concerns... but if there's still
> something outstanding that I have not answered or addressed, please raise
> it again, explicitly, and in the context of the proposed changes, so I can
> respond to it.
>
> Sure, I can give you a summary as I understand it:
>
> Overview of the issues:
>
> ACCUMULO-3177: Adds a per-table VolumeChooser to replace the
> RandomVolumeChooser as the default VolumeChooser, with the default
> per-table implementation (a new per-table property is added for this) is
> now the RandomVolumeChooser. This is modeled after the per-table balancer.
> The intent is to enable balancing decisions for a tablet's persistent
> storage across volumes in the same way we allow balancing tablet's
> "compute" operations across Tablet Servers. To do this, a
> "VolumeChooserEnvironment" object is created and added to the chooser API,
> which exposes the environment to the chooser (such as the tableId, from
> which the namespace can be retrieved, etc.)
>
> ACCUMULO-3178: Adds an additional example/reference implementation for a
> per-table VolumeChooser, called a "PreferredVolumeChooser", which allows
> users to specify a specific volume (or set of volumes) in a custom
> per-table property. This is used as a test case (integration test) for
> ACCUMULO-3177. (Note: your original concerns about deduplication of HDFS's
> HSM effort expressed in ACCUMULO-3089 seem to apply only to this issue, not
> to ACCUMULO-3177; however, my hope is that you'll see that this is
> sufficiently unrelated to that, that your original objections do not apply.)
>
> Also, some background (from my perspective):
>
> Recall: As explained on ACCUMULO-3089, your original concerns were
> addressed by splitting the original issue into separate tasks, to help
> clarify the scope and intentions of that issue with more narrowly defined
> changesets. You were requested to explain your objections specifically in
> the context of the changesets on those tasks, because I believed you to
> have misunderstood the scope of the issue (as I stated on ACCUMULO-3089),
> and I hoped that doing so would help clarify where your objections were, in
> relation to the proposed code changes. As far as I can tell, you did do
> that, with your comments on the subsequent issues.
>
> You commented on ACCUMULO-3177, suggesting that it might be better to
> apply the configuration property on a namespace instead of a table. I
> responded to that comment with an explanation of how table and namespace
> configurations work in this context. As such, I hold that your comment
> represents a recommended "best practice" for table management
> (specifically, limiting the granting of ALTER_TABLE), but not an objection
> to the table/namespace configuration-based implementation/addition itself.
>
> You have also commented on ACCUMULO-3178, with an indication that you did
> not feel that the VolumeChooser interface itself was strictly "public API",
> which I took to mean that you'd be more flexible in tolerating changes to
> that API with a higher degree of risk. I did not see an objection to
> ACCUMULO-3178, but it does depend on ACCUMULO-3177. You also suggested not
> making these dependent on ACCUMULO-3176 (because of the presence of a
> limited workaround by adding configuration to a namespace first), a request
> which was accommodated (but ultimately unnecessary if ACCUMULO-3176 is
> permitted) in a separate review which you did not comment on after
> requesting it to be made.
>
>
>
>
>
>> --
>> Sean
>> On Nov 26, 2014 12:27 PM, "Christopher" <ct...@apache.org> wrote:
>>
>> > Thank you for your response. I request that you please be timely, as
>> these
>> > issues have sat idle for a long time, and the maintenance burden of
>> keeping
>> > them current with the HEAD of master is becoming excessive. I await your
>> > reviews/objections. Thanks.
>> >
>> >
>> > --
>> > Christopher L Tubbs II
>> > http://gravatar.com/ctubbsii
>> >
>> > On Wed, Nov 26, 2014 at 11:30 AM, Sean Busbey <bu...@cloudera.com>
>> wrote:
>> >
>> > > I will follow up on both of those tickets with my objections, please
>> do
>> > not
>> > > apply them.
>> > >
>> > > On Tue, Nov 25, 2014 at 2:08 PM, Christopher <ct...@apache.org>
>> > wrote:
>> > >
>> > > > My intention is to, sometime this week, take a thorough look at the
>> > > patches
>> > > > and reviews available for ACCUMULO-3177 (create a per-table
>> > > VolumeChooser)
>> > > > and ACCUMULO-3178 (example implementation of an alternate
>> > > > VolumeChooser/test case for ACCUMULO-3177). Given the discussions
>> > > > surrounding ACCUMULO-3176, and because they originated as the
>> overall
>> > > > ACCUMULO-3089 (which had some objections that may not have been
>> > > resolved) I
>> > > > wanted to give this notice, to ensure that there is opportunity for
>> > > > objections to occur and be discussed here first.
>> > > >
>> > > > Presumably, the objections for ACCUMULO-3176 are different from any
>> > that
>> > > > might be held for 3177 and 3178, but there was limited follow-up
>> > > > clarification of the objections raised after the issues were
>> re-scoped
>> > as
>> > > > separate, more specific, JIRA sub-tasks. So, I'm not sure there are
>> any
>> > > > still outstanding for those. Since the reviews are still open for
>> > those,
>> > > I
>> > > > just wanted to invite discussion either here, or (perhaps even
>> better)
>> > in
>> > > > the specific review in ReviewBoard.
>> > > >
>> > > > --
>> > > > Christopher L Tubbs II
>> > > > http://gravatar.com/ctubbsii
>> > > >
>> > >
>> > >
>> > >
>> > > --
>> > > Sean
>> > >
>> >
>>
>
>
Re: ACCUMULO-3177 and ACCUMULO-3178
Posted by Christopher <ct...@apache.org>.
On Wed, Nov 26, 2014 at 3:07 PM, Sean Busbey <bu...@cloudera.com> wrote:
> I will be as timely as I can.
>
> Thanks. However, please understand that if you are unable to respond
timely, progress can/should/will proceed without you. I just want to make
sure you have opportunity.
> Please keep in mind that our community is volunteer based, people have a
> multitude of commitments, and it is a holiday week.
>
>
Sure, I just want to make sure you have ample time to review and we can
address any objections you may have (if you still have any), but I want
some time constraint, so these contributions don't sit idle indefinitely
(that's not fair to the contributor, or to those who'd like to leverage
these features). As long as the discussion is active (holidays/weekends
considered, of course), I will not attempt to push.
> I had presumed more feedback wasn't pressing since no one had mentioned on
> the tickets how my original concerns were addressed by the revamps. If
> someone could give me a summary on each it would make things go much
> faster.
>
>
Your feedback is pressing because you're the only one who expressed
concerns, and I want to make sure you have ample opportunity to be
involved. But, I don't want it to wait forever. I did believe I had
responded sufficiently to your questions/concerns... but if there's still
something outstanding that I have not answered or addressed, please raise
it again, explicitly, and in the context of the proposed changes, so I can
respond to it.
Sure, I can give you a summary as I understand it:
Overview of the issues:
ACCUMULO-3177: Adds a per-table VolumeChooser to replace the
RandomVolumeChooser as the default VolumeChooser, with the default
per-table implementation (a new per-table property is added for this) is
now the RandomVolumeChooser. This is modeled after the per-table balancer.
The intent is to enable balancing decisions for a tablet's persistent
storage across volumes in the same way we allow balancing tablet's
"compute" operations across Tablet Servers. To do this, a
"VolumeChooserEnvironment" object is created and added to the chooser API,
which exposes the environment to the chooser (such as the tableId, from
which the namespace can be retrieved, etc.)
ACCUMULO-3178: Adds an additional example/reference implementation for a
per-table VolumeChooser, called a "PreferredVolumeChooser", which allows
users to specify a specific volume (or set of volumes) in a custom
per-table property. This is used as a test case (integration test) for
ACCUMULO-3177. (Note: your original concerns about deduplication of HDFS's
HSM effort expressed in ACCUMULO-3089 seem to apply only to this issue, not
to ACCUMULO-3177; however, my hope is that you'll see that this is
sufficiently unrelated to that, that your original objections do not apply.)
Also, some background (from my perspective):
Recall: As explained on ACCUMULO-3089, your original concerns were
addressed by splitting the original issue into separate tasks, to help
clarify the scope and intentions of that issue with more narrowly defined
changesets. You were requested to explain your objections specifically in
the context of the changesets on those tasks, because I believed you to
have misunderstood the scope of the issue (as I stated on ACCUMULO-3089),
and I hoped that doing so would help clarify where your objections were, in
relation to the proposed code changes. As far as I can tell, you did do
that, with your comments on the subsequent issues.
You commented on ACCUMULO-3177, suggesting that it might be better to apply
the configuration property on a namespace instead of a table. I responded
to that comment with an explanation of how table and namespace
configurations work in this context. As such, I hold that your comment
represents a recommended "best practice" for table management
(specifically, limiting the granting of ALTER_TABLE), but not an objection
to the table/namespace configuration-based implementation/addition itself.
You have also commented on ACCUMULO-3178, with an indication that you did
not feel that the VolumeChooser interface itself was strictly "public API",
which I took to mean that you'd be more flexible in tolerating changes to
that API with a higher degree of risk. I did not see an objection to
ACCUMULO-3178, but it does depend on ACCUMULO-3177. You also suggested not
making these dependent on ACCUMULO-3176 (because of the presence of a
limited workaround by adding configuration to a namespace first), a request
which was accommodated (but ultimately unnecessary if ACCUMULO-3176 is
permitted) in a separate review which you did not comment on after
requesting it to be made.
> --
> Sean
> On Nov 26, 2014 12:27 PM, "Christopher" <ct...@apache.org> wrote:
>
> > Thank you for your response. I request that you please be timely, as
> these
> > issues have sat idle for a long time, and the maintenance burden of
> keeping
> > them current with the HEAD of master is becoming excessive. I await your
> > reviews/objections. Thanks.
> >
> >
> > --
> > Christopher L Tubbs II
> > http://gravatar.com/ctubbsii
> >
> > On Wed, Nov 26, 2014 at 11:30 AM, Sean Busbey <bu...@cloudera.com>
> wrote:
> >
> > > I will follow up on both of those tickets with my objections, please do
> > not
> > > apply them.
> > >
> > > On Tue, Nov 25, 2014 at 2:08 PM, Christopher <ct...@apache.org>
> > wrote:
> > >
> > > > My intention is to, sometime this week, take a thorough look at the
> > > patches
> > > > and reviews available for ACCUMULO-3177 (create a per-table
> > > VolumeChooser)
> > > > and ACCUMULO-3178 (example implementation of an alternate
> > > > VolumeChooser/test case for ACCUMULO-3177). Given the discussions
> > > > surrounding ACCUMULO-3176, and because they originated as the overall
> > > > ACCUMULO-3089 (which had some objections that may not have been
> > > resolved) I
> > > > wanted to give this notice, to ensure that there is opportunity for
> > > > objections to occur and be discussed here first.
> > > >
> > > > Presumably, the objections for ACCUMULO-3176 are different from any
> > that
> > > > might be held for 3177 and 3178, but there was limited follow-up
> > > > clarification of the objections raised after the issues were
> re-scoped
> > as
> > > > separate, more specific, JIRA sub-tasks. So, I'm not sure there are
> any
> > > > still outstanding for those. Since the reviews are still open for
> > those,
> > > I
> > > > just wanted to invite discussion either here, or (perhaps even
> better)
> > in
> > > > the specific review in ReviewBoard.
> > > >
> > > > --
> > > > Christopher L Tubbs II
> > > > http://gravatar.com/ctubbsii
> > > >
> > >
> > >
> > >
> > > --
> > > Sean
> > >
> >
>
Re: ACCUMULO-3177 and ACCUMULO-3178
Posted by Sean Busbey <bu...@cloudera.com>.
I will be as timely as I can.
Please keep in mind that our community is volunteer based, people have a
multitude of commitments, and it is a holiday week.
I had presumed more feedback wasn't pressing since no one had mentioned on
the tickets how my original concerns were addressed by the revamps. If
someone could give me a summary on each it would make things go much faster.
--
Sean
On Nov 26, 2014 12:27 PM, "Christopher" <ct...@apache.org> wrote:
> Thank you for your response. I request that you please be timely, as these
> issues have sat idle for a long time, and the maintenance burden of keeping
> them current with the HEAD of master is becoming excessive. I await your
> reviews/objections. Thanks.
>
>
> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii
>
> On Wed, Nov 26, 2014 at 11:30 AM, Sean Busbey <bu...@cloudera.com> wrote:
>
> > I will follow up on both of those tickets with my objections, please do
> not
> > apply them.
> >
> > On Tue, Nov 25, 2014 at 2:08 PM, Christopher <ct...@apache.org>
> wrote:
> >
> > > My intention is to, sometime this week, take a thorough look at the
> > patches
> > > and reviews available for ACCUMULO-3177 (create a per-table
> > VolumeChooser)
> > > and ACCUMULO-3178 (example implementation of an alternate
> > > VolumeChooser/test case for ACCUMULO-3177). Given the discussions
> > > surrounding ACCUMULO-3176, and because they originated as the overall
> > > ACCUMULO-3089 (which had some objections that may not have been
> > resolved) I
> > > wanted to give this notice, to ensure that there is opportunity for
> > > objections to occur and be discussed here first.
> > >
> > > Presumably, the objections for ACCUMULO-3176 are different from any
> that
> > > might be held for 3177 and 3178, but there was limited follow-up
> > > clarification of the objections raised after the issues were re-scoped
> as
> > > separate, more specific, JIRA sub-tasks. So, I'm not sure there are any
> > > still outstanding for those. Since the reviews are still open for
> those,
> > I
> > > just wanted to invite discussion either here, or (perhaps even better)
> in
> > > the specific review in ReviewBoard.
> > >
> > > --
> > > Christopher L Tubbs II
> > > http://gravatar.com/ctubbsii
> > >
> >
> >
> >
> > --
> > Sean
> >
>
Re: ACCUMULO-3177 and ACCUMULO-3178
Posted by Christopher <ct...@apache.org>.
Thank you for your response. I request that you please be timely, as these
issues have sat idle for a long time, and the maintenance burden of keeping
them current with the HEAD of master is becoming excessive. I await your
reviews/objections. Thanks.
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
On Wed, Nov 26, 2014 at 11:30 AM, Sean Busbey <bu...@cloudera.com> wrote:
> I will follow up on both of those tickets with my objections, please do not
> apply them.
>
> On Tue, Nov 25, 2014 at 2:08 PM, Christopher <ct...@apache.org> wrote:
>
> > My intention is to, sometime this week, take a thorough look at the
> patches
> > and reviews available for ACCUMULO-3177 (create a per-table
> VolumeChooser)
> > and ACCUMULO-3178 (example implementation of an alternate
> > VolumeChooser/test case for ACCUMULO-3177). Given the discussions
> > surrounding ACCUMULO-3176, and because they originated as the overall
> > ACCUMULO-3089 (which had some objections that may not have been
> resolved) I
> > wanted to give this notice, to ensure that there is opportunity for
> > objections to occur and be discussed here first.
> >
> > Presumably, the objections for ACCUMULO-3176 are different from any that
> > might be held for 3177 and 3178, but there was limited follow-up
> > clarification of the objections raised after the issues were re-scoped as
> > separate, more specific, JIRA sub-tasks. So, I'm not sure there are any
> > still outstanding for those. Since the reviews are still open for those,
> I
> > just wanted to invite discussion either here, or (perhaps even better) in
> > the specific review in ReviewBoard.
> >
> > --
> > Christopher L Tubbs II
> > http://gravatar.com/ctubbsii
> >
>
>
>
> --
> Sean
>
Re: ACCUMULO-3177 and ACCUMULO-3178
Posted by Sean Busbey <bu...@cloudera.com>.
I will follow up on both of those tickets with my objections, please do not
apply them.
On Tue, Nov 25, 2014 at 2:08 PM, Christopher <ct...@apache.org> wrote:
> My intention is to, sometime this week, take a thorough look at the patches
> and reviews available for ACCUMULO-3177 (create a per-table VolumeChooser)
> and ACCUMULO-3178 (example implementation of an alternate
> VolumeChooser/test case for ACCUMULO-3177). Given the discussions
> surrounding ACCUMULO-3176, and because they originated as the overall
> ACCUMULO-3089 (which had some objections that may not have been resolved) I
> wanted to give this notice, to ensure that there is opportunity for
> objections to occur and be discussed here first.
>
> Presumably, the objections for ACCUMULO-3176 are different from any that
> might be held for 3177 and 3178, but there was limited follow-up
> clarification of the objections raised after the issues were re-scoped as
> separate, more specific, JIRA sub-tasks. So, I'm not sure there are any
> still outstanding for those. Since the reviews are still open for those, I
> just wanted to invite discussion either here, or (perhaps even better) in
> the specific review in ReviewBoard.
>
> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii
>
--
Sean