I think it would depend how much other "stuff" has to come in to support
the *Clusters. I assumed it would be a bit, but, if it's not, I have no
objections to a single jar.
On 1/5/18 4:38 PM, Michael Wall wrote:
Yeah, I was thinking more like your second paragraph. Thinking I would use
the pr
Yeah, I was thinking more like your second paragraph. Thinking I would use
the proposed client jar to develop against the MiniAccumuloCluster
(typically the StandaloneMiniAccumuloCluster for me) and then deploy that
code to run against a real cluster. Would like to flesh that usecase out a
little
MAC, in its common state, is probably not something we'd want to include
in this proposed tarball. The reasoning being that MAC (and related
classes) aren't something that people would need on your "Hadoop
Cluster" to talk to Accumulo. It's something that can just be obtained
via Maven.
Howev
I like the idea of a client jar that has less dependencies. Josh, where
are thinking the MiniAccumuloCluster fits in here?
On Fri, Jan 5, 2018 at 3:57 PM Christopher wrote:
> On Fri, Jan 5, 2018 at 10:30 AM Keith Turner wrote:
>
> > On Thu, Jan 4, 2018 at 7:43 PM, Christopher wrote:
> > > tl;
Updated Draft
--
## Description:
- The Apache Accumulo sorted, distributed key/value
store is a robust, scalable, high performance data storage system that
features cell-based access control and customizable server-side
processing. It is based on Google's BigTable design and is bui
All good ideas.
Mike, the Summit was held 16 Oct. I submitted the last report on 11 Oct
and the board meet on 18 Oct. The summit was mentioned, but I can mention
it again with a link. I'll add it.
Mike, I'll mention the tour add a link to the blog article.
Billie, I'll mention the docker repo
On Fri, Jan 5, 2018 at 10:30 AM Keith Turner wrote:
> On Thu, Jan 4, 2018 at 7:43 PM, Christopher wrote:
> > tl;dr : I would prefer not to add another tarball as part of our
> "official"
>
> I am not opposed to replacing the current single tarball with client
> and server tarballs. What I find
On Fri, Jan 5, 2018 at 10:01 AM Josh Elser wrote:
> I'd be worried about advertising something that we're not treating as
> official as it would languish (unless we create tests that can validate
> the result for us).
>
>
My concern is "packagability". That's what I'm concerned about languishing.
One thing worth mentioning is that I will be doing this against
$dayjob's 1.7 based branch to start.
If the consensus is to only do this for a 2.0 Accumulo release, perhaps
I can use my work to seed that effort? I'm thinking something like a
document that lists what would be in such a client-t
How about the Accumulo docker image?
On Fri, Jan 5, 2018 at 10:23 AM, Mike Walch wrote:
> Could mention an Accumulo tour was created for the website
> https://accumulo.apache.org/tour/
>
> On Thu, Jan 4, 2018 at 8:38 PM, Michael Wall wrote:
>
> > The Apache Accumulo PMC decided to draft its qua
Could mention an Accumulo tour was created for the website
https://accumulo.apache.org/tour/
On Thu, Jan 4, 2018 at 8:38 PM, Michael Wall wrote:
> The Apache Accumulo PMC decided to draft its quarterly board
> reports on the dev list. Here is a draft of our report which is due
> by Wednesday, Ja
If that wasn't in the last report, you could mention the Accumulo Summit.
I think the fact a company sponsored the summit, people presented and
attended shows a healthy project. Other than that looks good.
On Thu, Jan 4, 2018 at 8:38 PM, Michael Wall wrote:
> The Apache Accumulo PMC decided to d
On Fri, Jan 5, 2018 at 11:24 AM, Mike Walch wrote:
> I like the idea of client tarball. I think it will make things easier for
> users. However, I agree with Keith that we are going to need to split the
> accumulo command into accumulo-client & accumulo-server. I am interested
> in helping out w
I like the idea of client tarball. I think it will make things easier for
users. However, I agree with Keith that we are going to need to split the
accumulo command into accumulo-client & accumulo-server. I am interested
in helping out with this as I have done a lot of work on the scripts in 2.0.
On Thu, Jan 4, 2018 at 7:43 PM, Christopher wrote:
> tl;dr : I would prefer not to add another tarball as part of our "official"
I am not opposed to replacing the current single tarball with client
and server tarballs. What I find appealing about this is if the
client tarball has less deps.
Ho
I'd be worried about advertising something that we're not treating as
official as it would languish (unless we create tests that can validate
the result for us).
Thanks for the input.
On 1/4/18 7:43 PM, Christopher wrote:
tl;dr : I would prefer not to add another tarball as part of our "offic
On 1/5/18 9:55 AM, Keith Turner wrote:
Obviously, there are many ways to go about this. If there is buy-in from
other folks, adding some new assembly descriptors and making it a part of
the Maven build (perhaps, optionally generated) would be the easiest in
terms of maintenance. However, I don't
On Thu, Jan 4, 2018 at 7:16 PM, Josh Elser wrote:
> Hi,
>
> $dayjob presented me with a request to break up the current tarball into
> two: one suitable for "users" and another for the Accumulo services. The
> ultimate goal is to make upgrade scenarios a bit easier by having client and
> server ce
18 matches
Mail list logo
