accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Busbey <bus...@cloudera.com>
Subject Re: ACCUMULO-3177 and ACCUMULO-3178
Date Sat, 06 Dec 2014 04:11:28 GMT
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 <ctubbsii@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 <ctubbsii@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 <ctubbsii@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 <ctubbsii@apache.org>
> wrote:
> >>
> >>> On Wed, Nov 26, 2014 at 3:07 PM, Sean Busbey <busbey@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" <ctubbsii@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message