Continuing the consensus on this thread, I'm now working on moving the
spark connector out of core. HBASE-21430 clones our current modules (after
some pom cleanup and dependency messing). I'm now working on subtask to
purge them from our main repo. Will put more info on our old hbase-spark
https://issues.apache.org/jira/browse/INFRA-17217
Ongoing.
S
On Mon, Nov 5, 2018 at 12:17 PM Andrew Purtell wrote:
> +1, please do
>
> On Mon, Nov 5, 2018 at 9:55 AM Stack wrote:
>
> > I was going to file an issue w/ INFRA this evening asking that they
> disable
> > github comment/commits
+1, please do
On Mon, Nov 5, 2018 at 9:55 AM Stack wrote:
> I was going to file an issue w/ INFRA this evening asking that they disable
> github comment/commits being added as JIRA comments (See HBASE-21435 for an
> innocuous example of this feature in action and HBASE-21430 for an
>
I was going to file an issue w/ INFRA this evening asking that they disable
github comment/commits being added as JIRA comments (See HBASE-21435 for an
innocuous example of this feature in action and HBASE-21430 for an
illustration of how it can quickly turn silly). While I could see
Related, interesting thread on how various projects are doing the
github<->asf connection has just started[1].
A few have a notifications list that gets the github notification emails.
Email clients make parseable threads of the firehose apparently. We might
do same.
S
1.
On 11/2/18 11:20 AM, Stack wrote:
On Fri, Nov 2, 2018 at 7:30 AM Josh Elser wrote:
Nice stuff, Stack!
Not me. It Mike's work.
Sorry, didn't mean it that way. Was happy to see you pushing the
hbase-connectors repo forward :)
Obviously kudos to MikeW for the code itself!
Two quick
Thanks to everyone who helped (and didn't mind all the patches I had to
submit while I was leaning the process).
Mike
On Wed, Oct 31, 2018, 18:43 Stack To tie-off this thread, this nice feature was just pushed on
> hbase-connector. See
>
On Fri, Nov 2, 2018 at 8:20 AM Stack wrote:
> On Fri, Nov 2, 2018 at 7:30 AM Josh Elser wrote:
>
>>
>> ...
> Back and forth was dumped into HBASE-21002 (We changed this config on
> hbase-operator-tools config to not do this? I should look).
>
>
I took a look. We asked infra to send gitbox mail
On Fri, Nov 2, 2018 at 7:30 AM Josh Elser wrote:
> Nice stuff, Stack!
>
>
Not me. It Mike's work.
> Two quick questions:
>
> First, on provenance: this codebase primarily came from Mike Wingert on
> https://issues.apache.org/jira/browse/HBASE-15320? Just saw that the
> commit came from your
Nice stuff, Stack!
Two quick questions:
First, on provenance: this codebase primarily came from Mike Wingert on
https://issues.apache.org/jira/browse/HBASE-15320? Just saw that the
commit came from your email addr -- wasn't sure if that Mike was still
involved (or you took it to completion).
To tie-off this thread, this nice feature was just pushed on
hbase-connector. See
https://github.com/apache/hbase-connectors/tree/master/kafka for how-to.
Review and commentary welcome.
Thanks,
S
On Fri, Aug 3, 2018 at 6:32 AM Hbase Janitor wrote:
> I opened hbase-21002 to start the scripts
I opened hbase-21002 to start the scripts and assembly.
Mike
On Thu, Aug 2, 2018, 19:29 Stack wrote:
> Up in https://issues.apache.org/jira/browse/HBASE-20934 I created an
> hbase-connectors repo. I put some form on it using the v19 patch from
> HBASE-15320 "HBase connector for Kafka Connect".
Up in https://issues.apache.org/jira/browse/HBASE-20934 I created an
hbase-connectors repo. I put some form on it using the v19 patch from
HBASE-15320 "HBase connector for Kafka Connect". It builds and tests
pass. Here are some remaining TODOs:
* Figure how to do start scripts: e.g. we need to
On Tue, Jul 24, 2018 at 10:01 PM Misty Linville wrote:
> I like the idea of a separate connectors repo/release vehicle, but I'm a
> little concerned about the need to release all together to update just one
> of the connectors. How would that work? What kind of compatibility
> guarantees are we
Hi Misty,
As long as the connectors use a public API, we can be flexible. We get the
same guarantees app programmers get.
Mike
On Wed, Jul 25, 2018, 01:01 Misty Linville wrote:
> I like the idea of a separate connectors repo/release vehicle, but I'm a
> little concerned about the need to
I like the idea of a separate connectors repo/release vehicle, but I'm a
little concerned about the need to release all together to update just one
of the connectors. How would that work? What kind of compatibility
guarantees are we signing up for?
On Tue, Jul 24, 2018, 9:41 PM Stack wrote:
>
Grand. I filed https://issues.apache.org/jira/browse/HBASE-20934. Let me
have a go at making the easy one work first (the kafka proxy). Lets see how
it goes. I'll report back here.
S
On Tue, Jul 24, 2018 at 2:43 PM Sean Busbey wrote:
> Key functionality for the project's adoption should be in
Key functionality for the project's adoption should be in the project.
Please do not suggest we donate things to Bahir.
I apologize if this is brisk. I have had previous negative experiences
with folks that span our communities trying to move work I spent a lot
of time contributing to within
Why not just donating the connector to http://bahir.apache.org/ ?
On Tue, Jul 24, 2018, 12:51 PM Lars Francke wrote:
> I'd love to have the Kafka Connector included.
>
> @Mike thanks so much for the contribution (and your planned ones)
>
> I'm +1 on adding it to the core but I'm also +1 on
I'd love to have the Kafka Connector included.
@Mike thanks so much for the contribution (and your planned ones)
I'm +1 on adding it to the core but I'm also +1 on having a separate
repository under Apache governance
On Tue, Jul 24, 2018 at 6:01 PM, Josh Elser wrote:
> +1 to the great point
+1 to the great point by Duo about use of non-IA.Public classes
+1 for Apache for the governance (although, I wouldn't care if we use
Github PRs to try to encourage more folks to contribute), a repo with
the theme of "connectors" (to include Thrift, REST, and the like). Spark
too -- I think
Hi everyone,
I'm the author of the patch. A separate repo for all the connectors is a
great idea! I can make whatever changes necessary to the patch to help.
I have several other integration type projects like this planned.
Mike
On Tue, Jul 24, 2018, 00:03 Mike Drob wrote:
> I would be ok
I would be ok with all of the connectors in a single repo. Doing a repo per
connector seems like a large amount of overhead work.
On Mon, Jul 23, 2018, 9:12 PM Clay B. wrote:
> [Non-binding]
>
> I am all for the Kafka Connect(er) as indeed it makes HBase "more
> relevant" and generates buzz to
[Non-binding]
I am all for the Kafka Connect(er) as indeed it makes HBase "more
relevant" and generates buzz to help me sell HBase adoption in my
endeavors.
Also, I would like to see a connectors repo a lot as I would expect it can
make the HBase source and releases more obvious in what is
> Would we make a new repo called hbase-connectors and move REST, thrift,
and this new patch there?
I like this idea. We are already releasing hbase-thirdparty like this.
On Mon, Jul 23, 2018 at 5:47 PM Stack wrote:
> (Thanks for the good discussion)
>
> Where we think 'outside of HBase'
Anyway I'm +1 on moving thrift and rest out to a separated repo.
But I think the difficulty here is that, we need to cleanup the
dependencies first, and also make sure that these modules do not use the
classes other than IA.Public. Otherwise they will easily be broken...
2018-07-24 8:47
(Thanks for the good discussion)
Where we think 'outside of HBase' would be?
Github seems too 'remote' from project and from Apache? Would we make a new
repo called hbase-connectors and move REST, thrift, and this new patch
there?
Thanks,
S
On Mon, Jul 23, 2018 at 3:50 PM Josh Elser wrote:
I'm -0 for including this into the main hbase tree. I feel like we've
made a bit of progress in cleaning up our core, and this strikes me as a
step in the wrong direction.
At the same time, the integration seems nice enough (for the same
reasons Andrew points out). Is there a reason this
In the past we've had discussions even about kicking out the connector
modules (hbase-rest, hbase-thrift) so this begs the question why take on
the contribution as opposed to let it live as a separate GitHub project?
That said, in my opinion the answer depends on to what degree we want to
support
We have a very nice contrib sitting up in HBASE-15320 which via a proxy --
so minimal dependencies -- adds source and sink for Kafka Connect. It is
nicely contained inside two new hbase-kafka-* modules.
We good w/ taking on this new feature?
It looks good to me. Check it out up on HBASE-15320. I
30 matches
Mail list logo
