Re: Clarifying interface evolution freedom in patch releases (was: Re: [VOTE] Third release candidate for HBase 1.0.1 (RC2))

Enis Söztutar wrote: +1 to the proposal. The problem is that we have a very big API surface especially with the coprocessors included in the report. Even simple bug fixes can introduce protected or public methods to base classes, which makes patch releases very hard to maintain. I would not

Re: Clarifying interface evolution freedom in patch releases (was: Re: [VOTE] Third release candidate for HBase 1.0.1 (RC2))

Stack wrote: On Thu, Apr 23, 2015 at 3:08 PM, Andrew Purtellapurt...@apache.org wrote: So we like semver, not we use semver? and Sean's No longer claiming semver would also have the added benefit of making it for me to easier to explain our compatibility promises to people. Yeah,

Re: [VOTE] Third release candidate for HBase 1.0.1 (RC2) is available. Please vote by April 24 2015

+1 (non-binding) * Checked sigs/xsums * Looked for binary files in source tarball (found none unexpected) * Built/ran-tests from source * Started instance from binary tarball, ran shell commands * Perused japi report One note... in the japi report, I was a little surprised when I noticed

Re: Clarifying interface evolution freedom in patch releases (was: Re: [VOTE] Third release candidate for HBase 1.0.1 (RC2))

While I can understand the desire to want to add things, I do think it makes things harder for users to reliably write code against versions of HBase which (by their view) should be completely compatible with one another. Take this extremely hypothetical situation: I'm new to HBase and start

Re: Clarifying interface evolution freedom in patch releases (was: Re: [VOTE] Third release candidate for HBase 1.0.1 (RC2))

Andy -- I understood your intent, but thanks for clarifying. (as well as taking the time to break this discussion out in the first place). I agree with your assessment. re: Sean's comments, if it wasn't clear by me asking in the first place, I also think sticking as close as possible to

Re: Clarifying interface evolution freedom in patch releases (was: Re: [VOTE] Third release candidate for HBase 1.0.1 (RC2))

, Apr 22, 2015 at 10:35 AM, Josh Elser josh.el...@gmail.com wrote: Andy -- I understood your intent, but thanks for clarifying. (as well as taking the time to break this discussion out in the first place). I agree with your assessment. re: Sean's comments, if it wasn't clear by me asking

Re: Ruby shell versions for HBase 2.0

Andrew Purtell wrote: This is because the Accumulo shell is a custom built shell? If so, we had one of those once and replaced it with the IRB based one. We didn't settle on JRuby right away but, at the time, the consensus was we didn't want to be in the business of maintaining yet another REPL

Re: Ruby shell versions for HBase 2.0

Agreed on these points, Sean. Having used both, I think both approaches have their value and their drawbacks. The ruby shell is _wonderful_ from having a full programming language to interact with. Accumulo's shell would force you to use your standard unix-toolbelt if you want to do any extra

Re: [DISCUSS] project for pre-commit patch testing (was Re: upstream jenkins build broken?)

+1 (Have been talking to Sean in private on the subject -- seems appropriate to voice some public support) I'd be interested in this for Accumulo and Slider. For Accumulo, we've come a far way without a pre-commit build, primarily due to a CTR process. We have seen the repeated questions of

Re: HBase and Accumulo

IMO, they are very similar. Lots of smart people on both sides making really good changes. I think HBase has a lot more instrumentation and understanding on the resources a cluster will use. For example, I think it's much clearer the resources and threads that the RPC server will use. This is

Re: HBase and Accumulo

Andrew Purtell wrote: Last I tried to play with the cell-level security APIs in HBase, it seemed very obtuse to me. Perhaps I was just dense and didn't find the right sort of instructions. I don't think anyone would debate that cell level security in HBase is a work-in-progress. We'd really

Re: [VOTE] First release candidate for HBase 1.1.2 (RC0) is available

Forgot to send out last night (figured I would now despite the -1) Ignoring licensing issues, (non-binding) +1 * Checked sig/xsums * Inspected compatibility report (thanks for including!) * Built source * Ran small+med tests (TestRegionServerHostname failed, passed on rerun) Nick Dimiduk

Re: HBase and Accumulo

Like I've said many times now, it's relative to your actual problem. If you don't have that much data (or intend to grow into that much data), it's not an issue. Obviously, this is the case for you. However, it is an architectural difference between the two projects with known limitations for

Re: HBase and Accumulo

Oh, one other thing that I should mention (was prompted off-list). (definition time since cross-list now: HBase regions == Accumulo tablets) Accumulo will handle many more regions than HBase does now due to a splittable metadata table. While I was told this was a very long and arduous journey

Re: HBase and Accumulo

He didn't ask just about security, FWIW I am looking for real gap comparing HBase to Accumulo if there is any so that I can be prepared to address them. This is not limited to the security area. Sean Busbey wrote: Let's please stick to the topic Jerry asked about: security features. We can

Re: HBase and Accumulo

. The HBase community hasn't been doing that so much. It would be great if they did because the HBase points on the graphs are old and it would be good to get new ones. On Wed, Aug 19, 2015 at 02:30:58PM -0400, Josh Elser wrote: Like I've said many times now, it's relative to your actual

Re: HBase and Accumulo

results in their paper, it just took longer for their experiments to run. So, in this case, we had two different teams doing things different ways and getting the same result, which is what we like to see. On Wed, Aug 19, 2015 at 03:27:07PM -0400, Josh Elser wrote: Alright, I have to ask... are you

Re: [VOTE] First release candidate for HBase 1.1.3 (RC0) is available

+1 (non-binding) * Built from source * Ran tests (-PrunDevTests). o.a.h.h.r.TestRegionServerHostname was problematic, might have just been me. * Checked sigs/xsums * Checked the compat report (thanks for posting it, Nick) * Skimmed release notes looking for anything that might introduce new

Re: Thrift versions and generated code

Ahh, thanks, gentlemen. Andrew Purtell wrote: Yeah, let's finish that. On Thu, Nov 12, 2015 at 11:49 AM, Ted Yu<yuzhih...@gmail.com> wrote: See https://issues.apache.org/jira/browse/HBASE-14172 On Thu, Nov 12, 2015 at 11:46 AM, Josh Elser<josh.el...@gmail.com> wrote: Hi,

Thrift versions and generated code

Hi, In looking at https://issues.apache.org/jira/browse/HBASE-14800, I saw that the current libthrift dependency on master was at 0.9.2, but the generated code still has the 0.9.0 comments. Is there a reason for that? Should the libthrift version defined in the poms be the de-facto version

Re: On our unit tests...

Huge kudos to you, Stack, for making the time to run these down. As a contributor, I'm very moved by the thought of treating what Jenkins reports as truth. Stack wrote: Since I wrote the below, we've figured who the surefire-killer was [HBASE-14589]. 9 of the last 10 1.2 builds passed (even

Re: [VOTE] HBase 1.2.0 RC0

I feel like I've seen this before myself on OSX, but didn't trace it down either. Mikhail Antonov wrote: Checked signatures, package content, RAT, ran tests, notice repeated failure: tests in error: TestRegionServerHostname.testRegionServerHostname:86 » TestTimedOut test timed... It

Re: Backporting to active branches

Stack wrote: ... > Let's change our relationship slightly, dev community. If you're working on > a fix, please also post a patch for branch-1.1. It is a bit tough. That'd be a patch for four branches (at least), three of which have diverged in key areas (master, branch-1 and branch-1.2, and

Source incompatibility between 1.2.[0,1] and 1.2.2 breaks Phoenix

Hi folks, I just noticed a ticket over in Phoenix [1] in which some method additions to the Table interface [2] breaks the source compatibility of Phoenix with HBase 1.2.2. My understanding of the current guidelines is that these are allowed as they do not invalidate binary compatibility of

Re: copy_table_desc.rb script

If you have the cycles to add the validation, absolutely :) Lars George wrote: Duh, my bad, JM you are right, I missed to type the leading slashes... then a little better error handling may be nice. Not sure, you guys think this warrants a JIRA? On Fri, Feb 3, 2017 at 3:52 PM, Ted

Soliciting reviews for space quota work

Hiya, Shamelessly soliciting some of your already full day to take a look at the space quota work. Locally, I actually have the feature working pretty well, but the feature branch is lagging quite a bit behind due to the review process. In case you forgot the pertinent details.. Parent

Re: [DISCUSSION] Upgrading core dependencies

(late to the party, but..) +1 Nick sums this up better than I could have. Nick Dimiduk wrote: For the client: I'm a fan of shaded client modules by default and minimizing the exposure of that surface area of 3rd party libs (none, if possible). For example, Elastic Search has a similar set of

Re: [DISCUSS] Re: Replication resiliency

idea to revisit that and make sure that all the threads are injected with the UEH. The replication source threads are started on demand, that is why the UEH is not injected I think. But agreed that we should do the safe route here, and abort the regionserver. Enis On Thu, Jan 26, 2017 at 2:19 PM

Re: [DISCUSS] Re: Replication resiliency

+1 If any "worker" thread can't safely/reasonably retry some unexpected exception without a reasonable expectation of self-healing, tank the RS. Having those threads die but not the RS could go uncaught for indefinite period of time. Sean Busbey wrote: I've noticed a few other places where

Re: [DISCUSS] Tracking HBase Snapshots for Space Quotas

Oops! Thanks, Ted. Will flip that now. Ted Yu wrote: Josh: The design doc in [1] is View only. Can you give viewers permission to comment ? On Wed, Feb 22, 2017 at 2:04 PM, Josh Elser<els...@apache.org> wrote: Hiya folks, As we're wrapping up on the current set of features listed in

[DISCUSS] Tracking HBase Snapshots for Space Quotas

Hiya folks, As we're wrapping up on the current set of features listed in HBASE-16961 for tracking and limiting the HDFS space used by HBase tables and namespaces, I wanted to present a doc that outlines an approach to tracking snapshots in the context of space quotas. As most operators

HDFS space quota work getting close

Hiya, I wanted to put out a quick note that the space quota work (HBASE-16961) is getting pretty close to something I'd feel comfortable hitting "master". The last "big" changeset is under review now, leaving only much smaller bug-fixes (instead of the big feature work). There is some

Re: Resignation as RM for branch 0.98

Big +1 to your efforts, Andrew, and an EOL on 0.98 Ted Yu wrote: Kudos to Andrew. On Mon, Jan 9, 2017 at 11:26 AM, Enis Söztutar wrote: Thanks Andrew for carrying this. +1 on the EOL messaging. Enis On Mon, Jan 9, 2017 at 10:37 AM, Mikhail Antonov

Re: Source incompatibility between 1.2.[0,1] and 1.2.2 breaks Phoenix

Thanks for the great reply, Andrew! Andrew Purtell wrote: ​ I find the InterfaceAudience annotations on this really strange. How can we have a Public audience Interface (o.a.h.h.c.Table) with Private methods? I'm also not sure the Private annotations on the Table interface are that useful.

Re: Source incompatibility between 1.2.[0,1] and 1.2.2 breaks Phoenix

(top-post since I can't find a better place to respond to everyone who chimed in here) Huge thanks, everyone! This was absolutely the best email thread (and JIRA issue) I could've come back to after not keeping up with email for the day. Stack wrote: On Tue, Aug 16, 2016 at 8:20 AM, Sean

Re: [VOTE] First release candidate for HBase 1.1.9 (RC0) is available

+1 (non-binding) * sigs/xsums are good * Can build from source * No unexpected binaries in source tarball * apache-rat:check passes on source tarball * Can run locally from bin tarball Nick Dimiduk wrote: I'm happy to announce the first release candidate of HBase 1.1.9 (HBase-1.1. 9RC0) is

Re: [DISCUSSION] Merge Backup / Restore - Branch HBASE-7912

So, the answer to Sean's original question is "as robust as snapshots presently are"? (independence of backup/restore failure tolerance from snapshot failure tolerance) Is this just a question WRT context of the change, or is it means for a veto from you, Sean? Just trying to make sure I'm

Re: [DISCUSSION] Merge Backup / Restore - Branch HBASE-7912

is not good enough yet to be integrated into 2.0 branch? -Vlad On Wed, Sep 7, 2016 at 8:23 AM, Sean Busbey<bus...@apache.org> wrote: On Tue, Sep 6, 2016 at 10:36 PM, Josh Elser<josh.el...@gmail.com> wrote: So, the answer to Sean's original question is "as robust as snapshot

Re: [DISCUSS] Drop the support of jdk7 at a future 1.x release

Sean Busbey wrote: This would be a very big breaking change in release numbering that goes against our compatibility guidelines. We only drop support for Java versions on major releases. If we want features that require newer jdks sooner, we should make major releases sooner. +1 On this

[DISCUSS] FileSystem Quotas in HBase

Hi folks, I'd like to propose the introduction of FileSystem quotas to HBase. Here's a design doc[1] available which (hopefully) covers all of the salient points of what I think an initial version of such a feature would include. tl;dr We can define quotas on tables and namespaces. Region

Re: [DISCUSS] FileSystem Quotas in HBase

that people can comment on it ? Is there a JIRA opened for this work ? Please open one if there is none. Thanks On Fri, Oct 28, 2016 at 9:00 AM, Josh Elser<els...@apache.org> wrote: Hi folks, I'd like to propose the introduction of FileSystem quotas to HBase. Here's a design doc[1] ava

Re: Coprocessor metrics

Yep -- see avatica-metrics[1], avatica-dropwizard-metrics3[2], and my dropwizard-hadoop-metrics2[3] project for what Nick is referring to. What I ended up doing in Calcite/Avatica was a step beyond your #3, Enis. Instead of choosing a subset of some standard metrics library to expose, I

Re: DISCUSS: Strip xref from our site generation

+1 I just pull it up via the javadoc jars with my IDE. Not worth the time/effort to build/maintain. It would be good to add a pointer to external websites instead of just making broken links (for those who have the current URLs bookmarked). Stack wrote: The xref pages were useful once

Re: [DISCUSS] FileSystem Quotas in HBase

and patches starting to land. I'm also happy to entertain more discussion if anyone hasn't found the time to read/comment yet. Thanks! - Josh Josh Elser wrote: Sure thing, Ted. https://docs.google.com/document/d/1VtLWDkB2tpwc_zgCNPE1ulZOeecF-YA2FYSK3TSs_bw/edit?usp=sharing Let me open

Re: [DISCUSS] FileSystem Quotas in HBase

ould be a good enough approximation and the error bounds on over-allocation would be minimal and negligible in production. Thus, the proposal is to implement the soft approach with good documentation about how much space can be over-allocated in a worst-case scenario. Enis On Wed, Nov 2, 2016 a

Re: [DISCUSS] FileSystem Quotas in HBase

error bounds on over-allocation would be minimal and negligible in production. Thus, the proposal is to implement the soft approach with good documentation about how much space can be over-allocated in a worst-case scenario. Enis On Wed, Nov 2, 2016 at 12:15 PM, Josh Elser<els...@apache.org>

Update on filesystem space quota work

Hiya folks, Just wanted to shoot out a quick note that the filesystem quota work is really coming along. With the last patch I put up (HBASE-17001), we actually have some end-to-end tests that show the feature (I'm pleasantly tickled at how nice it turned out from a user POV). If anyone was

Re: Coprocessor metrics

Enis Söztutar wrote: Bumping this up in case people are interested. Also this is not coprocessor-specific, because I think we can incrementally start using the new hbase-metrics module, and get rid of our complicated metrics2 based patterns for core metrics as well. We should of course start

Re: [DISCUSS] Moving towards merge on HBASE-16961 (space quota)

of application and verification of a simple space quota, say by namespace. If this already exists a pointer would be helpful. To start I'd want to run through something expected to work. On Mar 23, 2017, at 10:45 AM, Josh Elser<els...@apache.org> wrote: bump Josh Elser wrote: Rebase i

Re: [DISCUSS] Moving towards merge on HBASE-16961 (space quota)

bump Josh Elser wrote: Rebase is done for those who want to just look at some code. https://github.com/apache/hbase/compare/HBASE-16961 Josh Elser wrote: Hiya folks, As advertised (warned? *winks*), all of the sub-tasks on HBASE-16961 have been resolved after being committed to the HBASE

Re: [DISCUSS] updating docs on Apache Hadoop versions for recent upstream releases.

Sean Busbey wrote: Heya folks, Hadoop has just closed their RCs on a 2.8.0 release[1]. During voting, two Hadoop PMC members positioned the release as "not production ready"[2], similar to how the 2.7.0 release was flagged[3]. Oh good. The RC only just passed, so the actual release bits

Re: How threads interact with each other in HBase

1.1 -> 2: don't forget about the block cache which can invalidate the need for any HDFS read. I think you're over-simplifying the write-path quite a bit. I'm not sure what you mean by an 'asynchronous write', but that doesn't exist at the HBase RPC layer as that would invalidate the

Re: [DISCUSS] Moving towards merge on HBASE-16961 (space quota)

For those who miss it on the JIRA notification email, see: https://issues.apache.org/jira/browse/HBASE-16961?focusedCommentId=15941163=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15941163 Josh Elser wrote: Thanks Andrew! An integration is actually something

Re: [DISCUSS] What are we going to call the releases leading up to HBase 2.0?

I'm partial to 2.0.0-alpha[x]/beta[x] * Conveys that it's 2.x (not 1.x) * Conveys "instability" * Doesn't buck Maven's view of the world (Maven is happy with a version string of 2.0.0-alpha) * Still enables a "2.0.0" later Sean Busbey wrote: Hi folks! What are folks opinions on how we name

Re: Remove invalid '2.0' and '2.0..' verions from jira

Just checked and I don't see 'em there anymore. I assume someone else has already done this :) Enis Söztutar wrote: Thanks for the cleanup. Indeed we should remove these from jira admin so that they don't show up in auto-fill. Enis On Fri, Mar 31, 2017 at 8:34 AM, Stack

Re: About adding methods to an interface which is part of our public API in minor release

+1 to the JDK8 default implementation approach. I'd say this would be good to push forward for the future. For 1.x, I see no reason why we couldn't provide concrete implementations as a stop-gap. Identifying and creating those classes is probably the biggest barrier :). I don't think anything

Re: [DISCUSS] moving to Apache Yetus Audience Annotations

Sean Busbey wrote: On Mon, Mar 20, 2017 at 11:09 AM, Ted Yu wrote: Is Yetus 0.4.0 release stable ? yes. If we use Yetus annotations, is there only one jar pulled in as dependency ? IIRC, we'll get one jar as a dependency. There shouldn't be any transitive

Re: Multiple match's Filter is NOT WORKING

If you could encapsulate what you're trying to do into a unit-test/standalone class, it would likely be much more approachable for anyone to reproduce and help debug your issues. You've provided a lot of information, but very little of it is helpful in actually figuring out why what you've

Re: [DISCUSS] Moving towards merge on HBASE-16961 (space quota)

Rebase is done for those who want to just look at some code. https://github.com/apache/hbase/compare/HBASE-16961 Josh Elser wrote: Hiya folks, As advertised (warned? *winks*), all of the sub-tasks on HBASE-16961 have been resolved after being committed to the HBASE-16961 branch in SCM. While

[DISCUSS] Moving towards merge on HBASE-16961 (space quota)

Hiya folks, As advertised (warned? *winks*), all of the sub-tasks on HBASE-16961 have been resolved after being committed to the HBASE-16961 branch in SCM. While Ted has been a stalwart reviewer, it would be good to get another set of eyes (or a few sets) on the changes before considering I

Re: [VOTE] First release candidate for HBase 1.2.5 is available

Please do. Thanks for checking. +1 (binding) Sean Busbey wrote: Hi Josh! Are you comfortable with me considering your vote binding now that you're a PMC member? On Sat, Mar 11, 2017 at 5:24 PM, Josh Elser<els...@apache.org> wrote: +1 (non-binding) * xsums/sigs OK * Compat report lo

Re: Multiple match's Filter is NOT WORKING

ificate to where you want to go for two if you could look into my problem and provide some suggestion. Thanks, Yoom - Original Message ----- From: "Josh Elser" <els...@apache.org> To: dev@hbase.apache.org Sent: Monday, March 20, 2017 6:29:41 PM Subject: Re: Multiple match's Fil

Re: [VOTE] Backup/Restore feature for HBase 2.0, vote closing 3/11/2017

oing the community a favor by trying to walk that back. On Tue, Mar 14, 2017 at 1:57 PM, Josh Elser<els...@apache.org> wrote: I took a moment to read through the "blockers" as originally identified by Vlad, and (to echo Enis' take) I read the majority of them as being blockers

Re: [VOTE] Backup/Restore feature for HBase 2.0, vote closing 3/11/2017

I took a moment to read through the "blockers" as originally identified by Vlad, and (to echo Enis' take) I read the majority of them as being blockers not for the next release, but for a "full-fledged feature". I'm going to intentional avoid addressing the discussion of shipping partial

Re: [VOTE] Backup/Restore feature for HBase 2.0, vote closing 3/11/2017

table to reset broken system table). I am currently starting working on HBASE-15227. It will probably take a week or two to finish. On a doc side, as I already mention we will need to update command-line tool section in the doc I posted above. -Vlad On Tue, Mar 14, 2017 at 1:57 PM, Josh Elser

Re: [VOTE] Backup/Restore feature for HBase 2.0, vote closing 3/11/2017

or by trying to walk that back. On Tue, Mar 14, 2017 at 1:57 PM, Josh Elser<els...@apache.org> wrote: I took a moment to read through the "blockers" as originally identified by Vlad, and (to echo Enis' take) I read the majority of them as being blockers not for the next release, but for

Re: Successful: HBase Generate Website

+1 to that :D Stack wrote: Hot Dog! On Fri, Mar 31, 2017 at 3:03 PM, Misty Stanley-Jones wrote: FYI, the linked Jenkins job now automatically updates the site! No more need to manually push. Merry Christmas! :) - Original message - From: Apache Jenkins

Re: How threads interact with each other in HBase

ity. If you want the data to be durable, then you need to call hsync() instead of hflush(), and that would be the correct behavior if you use FSYNC_WAL flag (per HBase documentation). However, HBase does not do that. Suli On Sun, Apr 2, 2017 at 11:26 AM, Josh Elser<josh.el...@gmail.com>

Re: How threads interact with each other in HBase

o mater you use SYNC_WAL or FSYNC_WAL flag. > > On Tue, Mar 28, 2017 at 12:11 PM, Josh Elser <els...@apache.org> wrote: > >> 1.1 -> 2: don't forget about the block cache which can invalidate the need >> for any HDFS read. >> >> I think you're over-sim

Re: [DISCUSS] More Shading

Stack wrote: Let me revive this thread. Lets do Sean's idea of a pre-build step where we package and relocate ('shade') critical dependencies (Going by the thread above, Ram, Anoop, and Andy seems good w/ general idea). In implementation, we (The HBase PMC) would ask for a new repo [1].

Re: [DISCUSS] More Shading

Sean Busbey wrote: On Tue, Apr 11, 2017 at 11:43 PM Nick Dimiduk wrote: This effort is about our internals. We have a mess of other components all up inside us such as HDFS, etc., each with their own sets of dependencies many of which we have in common. This project t

Re: Is HBase RPC-Handling idempotent for reads?

Yeah, neat idea now that I understand the big picture :) Instead of trying to do this purely server-side, have you considered a first "wag" at a solution of hooking into the existing RPC quota work? Presently, in the context of a user's RPCs, quotas only limit the number of RPCs that user

Re: Is HBase RPC-Handling idempotent for reads?

+1 to that one, Jerry :). I think we're missing some context, Suli. Also, I don't know of any code path in which an RPC would be partially processed and then returned to the queue. Calls go from wire -> queue -> handler, they can't move backwards. They either move forward or throw an

Re: [VOTE] Second release candidate for HBase 1.3.1 (RC1) is available

+1 (binding) * xsums/sigs OK * Can build from src * License headers/src-release files look OK * bin tarball's LICENSE is lacking [1] * Can run tests (still going, but will comment if something bad arises) * Glanced at compat report (thanks for publishing!). Thanks Yu and Andrew for looking at

Re: [DISCUSS] More Shading

Stack wrote: On Wed, Apr 12, 2017 at 8:22 AM, Josh Elser<els...@apache.org> wrote: This makes me wonder if we could construct source jars just the same as we're creating shaded jars. Google has lead me to [2][3], but I've never tried either. The latter option seems to be acknowl

Re: [DISCUSS] More Shading

Nick Dimiduk wrote: > Well put, Nick. > > With Sean's point about the Hadoop shaded client, it seems to me that we > have things which could be pursued in parallel: > > 1) Roadmap to Hadoop3 (and shaded hdfs client). > 2) Identify components which we use from Hadoop, for each component: >

Re: [VOTE] First release candidate for HBase 1.1.10 (RC0) is available

+1 (binding) with a nit. * NOTICE file needs an update (copyright year). The notes about "Licensed under Apache License, version 2.0" also appear unnecessary to me (but are only "bad" in that it unnecessarily bloats our NOTICE). * xsums/sigs OK * Can build tarball from source * Ran YCSB

Re: [VOTE] First release candidate for HBase 1.2.5 is available

+1 (non-binding) * xsums/sigs OK * Compat report looks OK for a patch release * Spot-checked source release and ran apache-rat:check * Can build from source (and run a subset of tests) * KEYS has the signing key * Commit is in source repository Sean Busbey wrote: The first release candidate

Re: Moving 2.0 forward

Stack wrote: On Tue, Mar 7, 2017 at 1:51 PM, Josh Elser<els...@apache.org> wrote: Thanks for pulling in the FS Quotas work, Stack. I'm trying to cross the last T's and dot the last I's. The biggest thing I know I need to do still is to write a new chapter to the book. After that, I'd

Re: [DISCUSS] Tracking HBase Snapshots for Space Quotas

A minor "bump" here, folks. Thanks to Ted and Zach for your comments so far, but more are always welcome. Josh Elser wrote: Hiya folks, As we're wrapping up on the current set of features listed in HBASE-16961 for tracking and limiting the HDFS space used by HBase tables and nam

Re: Moving 2.0 forward

Thanks for pulling in the FS Quotas work, Stack. I'm trying to cross the last T's and dot the last I's. The biggest thing I know I need to do still is to write a new chapter to the book. After that, I'd start entertaining larger reviews/discussions to merge the feature into master. Anyone

Re: Moving 2.0 forward

On 7/31/17 9:00 AM, Stack wrote: On Mon, Jul 24, 2017 at 12:25 PM, Josh Elser<els...@apache.org> wrote: ... I like the idea of this also hitting 2.0 as it would make the feature a bit more "real", but am obviously a little nervous (I have no reason to be nervous though). I

Re: [VOTE] First release candidate for HBase 1.1.12 (RC0) is available

+1 (binding) * xsums/sigs OK * apache-rat:check OK * Poked at L in both src/bin (bin's NOTICE seems bloated with ASLv2 entries, but this isn't a blocker) * Compat report is great (thanks for publishing) * Tag is published Thanks for putting together, Nick! On 8/12/17 6:09 PM, Nick Dimiduk

Re: Consult about the issue HBASE-18323

Shibin, Please keep all communication on public forums (JIRA or mailing lists). This is very important to make sure that all parties interested can participate -- we do not want to be exclusionary. To answer your question, your change below is half-way there: Your change below would prevent

Re: Moving 2.0 forward

On 7/21/17 12:03 PM, Stack wrote: Status update girls and boys! hbase-2.0.0-alpha1 went out June 22nd. alpha2 has been a bit slow to follow (holidays) though there has been steady progress closing out blockers and criticals by a bunch of you all. The plan is for a release in the first week

Re: [JENKINS] [IMPORTANT] - Jenkins Migration and Upgrade (And JDK7 deprecation)

@%3Cdev.hbase.apache.org%3E On Tue, Jun 27, 2017 at 10:57 AM, Josh Elser <els...@apache.org> wrote: tl;dr Infra is upgrading Jenkins in 2 weeks and Java7 Maven jobs may/may-not work after this. See explanation below from [1]: Users with jobs configured with the "Maven project" type may not be

[ANNOUNCE] Devaraj Das joins the Apache HBase PMC

I'm pleased to announce yet another PMC addition in the form of Devaraj Das. One of the "old guard" in the broader Hadoop umbrella, he's also a long-standing member in our community. We all look forward to the continued contributions and project leadership. Please join me in welcoming

Re: Testing and CI -- Apache Jenkins Builds (WAS -> Re: Testing)

On 6/27/17 7:20 PM, Stack wrote: * test-patch's whitespace plugin can configured to ignore some files (but I can't think of any we'd care to so whitelist) Generated files. Oh my goodness, yes, please. This has been such a pain in the rear for me as I've been rebasing space quota patches.

Re: [DISCUSS] Merge HBASE-16961 (Space Quotas) into master

=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15941163 Stack wrote: Sounds like an excellent idea to me. If I were to take a tour over the quotas feature, how would you direct my perambulations Josh? Thanks, St.Ack On Tue, Apr 25, 2017 at 9:13 AM, Josh Elser<els...@apache.org> wrote: Hi

[DISCUSS] Merge HBASE-16961 (Space Quotas) into master

Hi folks, Here's a formal thread for discussion on merging the space quota feature (presently in the branch HBASE-16961[1]) into master. The tl;dr on the feature is that this extends the RPC quota feature to include configurable limits on the size of tables and namespaces. Please check the

[ANNOUNCE] New HBase committer Mike Drob

On behalf of the Apache HBase PMC, I'm pleased to announce that Mike Drob has accepted the PMC's invitation to become a committer. Mike has been doing some great things lately in the project and this is a simple way that we can express our thanks. As my boss likes to tell me: the reward for a

Re: Sporadically failing precommit tasks

Appears to have done the trick. https://builds.apache.org/job/PreCommit-HBASE-Build/6671/console Will open up a new issue just to fix this across the gamut. Thanks again, all. Josh Elser wrote: Thanks, Allen (and Sean). Let me poke and I'll report back. Allen Wittenauer wrote: Hmmm. It's

Re: Sporadically failing precommit tasks

Thanks, Allen (and Sean). Let me poke and I'll report back. Allen Wittenauer wrote: Hmmm. It's an interesting side-effect of how docker caches intermediate images: === Step 10/35 : RUN apt-get -q update ---> Using cache ---> 79fd4a487c35 Step 11/35 : RUN echo oracle-java7-installer

Re: [VOTE] Merge space quota branch (HBASE-16961) into master

May 9, 2017 at 3:29 PM, Josh Elser<els...@apache.org> wrote: I won't pretend to be involved enough in the 2.0 work to give an opinion :) -- I did say earlier that I'm happy to land this in 2.0 or 3.0 (whatever master decides to be at the time I merge). If the spirit of the voters i

Re: [VOTE] Merge space quota branch (HBASE-16961) into master

Reminder: I hope to close this in ~30hrs and there have been no votes so far. Josh Elser wrote: Folks, This is a vote to (rebase and) merge the branch HBASE-16961 into master. Per the book, this requires 3 binding +1's from other committers to merge. Relevant info for those who want

Re: How to find the rowkey of a table in HBASE

You issue a Get request for the rowkey you're looking for (checking for existence) or your use a Scanner to read all rowkeys (data) in the table. Developer Brasil wrote: How to find the rowkey of a table in HBASE -- View this message in context:

Re: [VOTE] Merge space quota branch (HBASE-16961) into master

to not immediately merge after this vote completes. Andrew Purtell wrote: Would it help to cut a branch for 2.0 before attempting to merge in a new major feature? On Tue, May 9, 2017 at 8:41 AM, Josh Elser<els...@apache.org> wrote: Reminder: I hope to close this in ~30hrs and ther

Re: [VOTE] Merge space quota branch (HBASE-16961) into master

As requested (later in this thread), I'll make sure this VOTE stays open at least until 2017-05-17 (an extra week). If time continues to be a barrier for review/input, please do speak up. Josh Elser wrote: Folks, This is a vote to (rebase and) merge the branch HBASE-16961 into master. Per

Re: [DISCUSS] More Shading

On 6/20/17 1:28 AM, Stack wrote: On Thu, Apr 13, 2017 at 4:46 PM, Josh Elser<els...@apache.org> wrote: ... I think pushing this part forward with some code is the next logical step. Seems to be consensus about taking our known internal dependencies and performing this shade magic

Re: [RESULT] [VOTE] First hbase-2.0.0-alpha-1 Release Candidate is available

Done ;) There were two issues still tagged as alpha-1 (JIRA didn't want to show me them before performing the action), but I bumped them to alpha-2. On 6/20/17 12:19 PM, Mike Drob wrote: Hi Stack, Can you mark jira version 2.0.0-alpha-1 as released? Thanks, Mike On Sat, Jun 10, 2017 at

  1   2   3   4   5   6   7   8   9   >