Re: Review Request 28873: ACCUMULO-3393 Follow-on work for per-table volume chooser.

[Christopher Tubbs]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/28873/#review64511
---


Overall, I saw some good modifications. However, some of the changes seemed to 
add unnecessary (premature) performance optimizations (object pool for a 
singleton map in an infrequently called method, set intersection with arrays 
instead of java collections). The volume chooser is an infrequently called 
method that represents a relatively trivial amount of the cost of creating a 
new tablet (adding a split point). I'm not sure that warrants the additional 
dependency or code complexity of those optimizations. And some of them, I'm 
just not confident by looking at them that they do the same thing as before 
(the String array set intersection part), when what was there occurred in two 
lines.

I do like the lazy initialization for the ServerConfigurationFactory, and the 
experimental annotation on the per-table property, and the javadoc updates.

Overall, though, it is very difficult to review this in the context of whether 
or not it satisfies the goals of ACCUMULO-3393, since those goals are not 
described in the JIRA issue. The changes here do not appear to be "clean-up" in 
any sense of the phrase I'm familiar with, since the changes do not appear to 
result in "cleaner" code. If anything, some of the changes are more complex and 
cumbersome to read than before, without changing their behavior or adding any 
measurable performance gain to tablet creation. I'm also concerned that the 
change in behavior which adds burdensome restrictions to the ability to 
dynamically change controlling per-table properties is not a "clean-up", either.

These changes are mixed in with a few documentation related changes and some 
changes I think are beneficial (above), so I don't want to dismiss the whole 
thing as negative, but I do think that this change tends to introduce more 
problems than it solves, especially since the problems it intends to solve are 
not defined.


core/src/main/java/org/apache/accumulo/core/conf/Property.java


+1



server/base/pom.xml


New dependency? Does it add significant value to warrant additional 
dependency conflict resolution and packaging complexity?



server/base/src/main/java/org/apache/accumulo/server/fs/PerTableVolumeChooser.java


The volatile for lazy-initialization is not needed. We don't suffer from 
having this assigned twice, which this code doesn't prevent. Also, it should be 
initialized to null here before it is assigned to localConf.

It should also be ServerConfigurationFactory. The ServerConfiguration type 
was only retained internally after Havanki's refactor to avoid changing the 
balancer API.

Ideally, we'd have an init method and be able to pass in the 
AccumuloServerContext, but this was problematic last I looked, because it 
created a dependency cycle between the VolumeManager and 
ServerConfigurationFactory, because this is called by the VolumeManager code 
and that is needed by the ServerConfigurationFactory (so it can't depend on the 
ServerConfigurationFactory).



server/base/src/main/java/org/apache/accumulo/server/fs/PerTableVolumeChooser.java


This change unnecessarily adds a restriction that the initial volume 
chooser for a table will be fixed for the lifetime of the TabletServer. This 
prevents dynamic changes to a per-table configuration property without 
justification. This is problematic by itself, but especially so given that a 
user is unable to set an initial VolumeChooser for the table because of your 
objection to ACCUMULO-3176.



server/base/src/main/java/org/apache/accumulo/server/fs/PreferredVolumeChooser.java


This is incorrect. This is not an experimental property. It is a custom 
per-table property, specific to the PreferredVolumeChooser.



server/base/src/main/java/org/apache/accumulo/server/fs/PreferredVolumeChooser.java


Do we really need an object pool for a map which holds 0 or 1 element for 
the duration of a single, infrequently called method? A better optimization for 
this case would be to add an optimized get(String key) method to 
AccumuloConfiguration / TableConfiguration, so we don't have to use a map at 
all.



server/base/src/main/java/org/apache/accumulo/server/fs/PreferredVolumeChooser.java


nit: formatting/whitespace



server/base/src/main/java/org/apache/accumulo/server/fs/PreferredVolumeChooser.java


This change unnecessarily pre

Re: Review Request 28873: ACCUMULO-3393 Follow-on work for per-table volume chooser.

[Josh Elser]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/28873/#review64510
---


Can you include a reason for these changes please? That will greatly help with 
context while reviewing them.

- Josh Elser


On Dec. 10, 2014, 6:01 a.m., Sean Busbey wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/28873/
> ---
> 
> (Updated Dec. 10, 2014, 6:01 a.m.)
> 
> 
> Review request for accumulo and Jenna Huston.
> 
> 
> Bugs: ACCUMULO-3393
> https://issues.apache.org/jira/browse/ACCUMULO-3393
> 
> 
> Repository: accumulo
> 
> 
> Description
> ---
> 
> ACCUMULO-3393 Follow-on work for per-table volume chooser.
> 
> Still has TODOs for additional tickets I need to file. I'll update the review 
> to remove once I have them all filed. I think everything marked TODO can wait 
> for a later ticket. Please comment on relevant section if you think something 
> needs to be done now.
> 
> * docs clean up
> * make sure that per-table choosers can keep state the way that global 
> choosers can
> * make sure that a chooser can only pick from the options it is presented.
> * avoid object creation in critical path for Tablet.split.
> 
> 
> Diffs
> -
> 
>   core/src/main/java/org/apache/accumulo/core/conf/Property.java 
> 4c2d0b41b3bce32449861da3ac42fa27deb2b182 
>   pom.xml 31601a1bf84e19b861e4f48b50824eeb77987b52 
>   server/base/pom.xml c21a168dec2092692f1ee6877c4703ee2d3e3977 
>   
> server/base/src/main/java/org/apache/accumulo/server/fs/PerTableVolumeChooser.java
>  7a825c796eb5a25de8c748e2aba642f483697b9a 
>   
> server/base/src/main/java/org/apache/accumulo/server/fs/PreferredVolumeChooser.java
>  7ed7bba809a4e5e4b2d472c3327b15adb37251a7 
>   
> server/base/src/main/java/org/apache/accumulo/server/fs/RandomVolumeChooser.java
>  f2eb2113cb848ed58ac5f41573c6ff2cde9b0a77 
>   server/base/src/main/java/org/apache/accumulo/server/fs/VolumeChooser.java 
> f523057b11a2dc42e82010675bb1ac8e3802f96d 
>   server/base/src/main/java/org/apache/accumulo/server/fs/VolumeManager.java 
> 890651e92f4c34514cb839b7b9ee9d23ad55070a 
>   
> server/base/src/main/java/org/apache/accumulo/server/fs/VolumeManagerImpl.java
>  dc1be739b634d91992894f8f27c2d9c184bd98cd 
>   server/base/src/main/java/org/apache/accumulo/server/fs/VolumeUtil.java 
> 877d01c2233cca086c1ac1539eb81cc282a7ceb4 
>   
> server/base/src/main/java/org/apache/accumulo/server/util/TabletOperations.java
>  c0e1a9b991d61a4dbb127c74ae297f171434e7d5 
>   
> server/base/src/test/java/org/apache/accumulo/server/fs/VolumeManagerImplTest.java
>  582822a8ccbc398925a2184eed0b9d7fa853f9b4 
> 
> Diff: https://reviews.apache.org/r/28873/diff/
> 
> 
> Testing
> ---
> 
> Ran through VolumeManagerImplTest and VolumeChooserIT 
> 
> 
> Thanks,
> 
> Sean Busbey
> 
>

Review Request 28873: ACCUMULO-3393 Follow-on work for per-table volume chooser.

[Sean Busbey]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/28873/
---

Review request for accumulo and Jenna Huston.


Bugs: ACCUMULO-3393
https://issues.apache.org/jira/browse/ACCUMULO-3393


Repository: accumulo


Description
---

ACCUMULO-3393 Follow-on work for per-table volume chooser.

Still has TODOs for additional tickets I need to file. I'll update the review 
to remove once I have them all filed. I think everything marked TODO can wait 
for a later ticket. Please comment on relevant section if you think something 
needs to be done now.

* docs clean up
* make sure that per-table choosers can keep state the way that global choosers 
can
* make sure that a chooser can only pick from the options it is presented.
* avoid object creation in critical path for Tablet.split.


Diffs
-

  core/src/main/java/org/apache/accumulo/core/conf/Property.java 
4c2d0b41b3bce32449861da3ac42fa27deb2b182 
  pom.xml 31601a1bf84e19b861e4f48b50824eeb77987b52 
  server/base/pom.xml c21a168dec2092692f1ee6877c4703ee2d3e3977 
  
server/base/src/main/java/org/apache/accumulo/server/fs/PerTableVolumeChooser.java
 7a825c796eb5a25de8c748e2aba642f483697b9a 
  
server/base/src/main/java/org/apache/accumulo/server/fs/PreferredVolumeChooser.java
 7ed7bba809a4e5e4b2d472c3327b15adb37251a7 
  
server/base/src/main/java/org/apache/accumulo/server/fs/RandomVolumeChooser.java
 f2eb2113cb848ed58ac5f41573c6ff2cde9b0a77 
  server/base/src/main/java/org/apache/accumulo/server/fs/VolumeChooser.java 
f523057b11a2dc42e82010675bb1ac8e3802f96d 
  server/base/src/main/java/org/apache/accumulo/server/fs/VolumeManager.java 
890651e92f4c34514cb839b7b9ee9d23ad55070a 
  
server/base/src/main/java/org/apache/accumulo/server/fs/VolumeManagerImpl.java 
dc1be739b634d91992894f8f27c2d9c184bd98cd 
  server/base/src/main/java/org/apache/accumulo/server/fs/VolumeUtil.java 
877d01c2233cca086c1ac1539eb81cc282a7ceb4 
  
server/base/src/main/java/org/apache/accumulo/server/util/TabletOperations.java 
c0e1a9b991d61a4dbb127c74ae297f171434e7d5 
  
server/base/src/test/java/org/apache/accumulo/server/fs/VolumeManagerImplTest.java
 582822a8ccbc398925a2184eed0b9d7fa853f9b4 

Diff: https://reviews.apache.org/r/28873/diff/


Testing
---

Ran through VolumeManagerImplTest and VolumeChooserIT 


Thanks,

Sean Busbey

Re: Accumulo Working Day

[Christopher]

Josh also showed me some neat stuff with SASL and Kerberos authentication
over thrift.
https://github.com/joshelser/krb-thrift


--
Christopher L Tubbs II
http://gravatar.com/ctubbsii

On Wed, Dec 10, 2014 at 12:06 AM, Corey Nolet  wrote:

> Also talked a little about Christopher's working on a new API design:
> https://github.com/ctubbsii/accumulo/blob/ACCUMULO-2589/
>
> On Tue, Dec 9, 2014 at 11:56 PM, Josh Elser  wrote:
>
> > Just so you don't think I forgot, there wasn't really much to report
> > today. Lots of friendly banter among everyone.
> >
> > The notable discussion was likely Don Miner stopping by and the
> collective
> > trying to brainstorm suggestions as to who would be a good candidate for
> a
> > "high-profile" keynote speaker for Accumulo Summit 2015 :)
> >
> > We also talked a little bit about metrics (with the recent support for
> > Hadoop metrics2 added) which helped bring some other devs up to speed who
> > hadn't looked at what such support really means.
> >
> > Let me know if I forgot anything other attendees.
> >
> >
> > Josh Elser wrote:
> >
> >> I'd be happy to. Not too much discussion yet, but if we talk about
> >> anything that doesn't end up on JIRA or elsewhere, I'll make sure it
> >> gets posted here.
> >>
> >> - Josh
> >>
> >> Mike Drob wrote:
> >>
> >>> For those of us who were unable to attend, can we get a summary of what
> >>> happened? I'd be curious to know if anything particularly novel came
> >>> out of
> >>> this collaboration!
> >>>
> >>> On Mon, Dec 8, 2014 at 4:06 PM, Jason Pyeron wrote:
> >>>
> >>>  If you are meeting near Ft. Meade I would like to drop off thank you
>  doughnuts.
> 
>  -Jason
> 
>   -Original Message-
> > From: Keith Turner
> > Sent: Wednesday, December 03, 2014 14:00
> >
> > Christopher, Eric, Josh, Billie, Mike, and I are meeting on
> > Dec 9 to work
> > on Accumulo together for the day in Central MD. If you are
> > interested in
> > joining us, email me directly. We are meeting in a small
> > conf room, so
> > space is limited.
> >
> > Keith
> >
> >  --
>  -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>  - -
>  - Jason Pyeron PD Inc. http://www.pdinc.us -
>  - Principal Consultant 10 West 24th Street #100 -
>  - +1 (443) 269-1555 x333 Baltimore, Maryland 21218 -
>  - -
>  -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>  This message is copyright PD Inc, subject to license 20080407P00.
> 
> 
> 
> >>>
>

Re: Accumulo Working Day

[Corey Nolet]

Also talked a little about Christopher's working on a new API design:
https://github.com/ctubbsii/accumulo/blob/ACCUMULO-2589/

On Tue, Dec 9, 2014 at 11:56 PM, Josh Elser  wrote:

> Just so you don't think I forgot, there wasn't really much to report
> today. Lots of friendly banter among everyone.
>
> The notable discussion was likely Don Miner stopping by and the collective
> trying to brainstorm suggestions as to who would be a good candidate for a
> "high-profile" keynote speaker for Accumulo Summit 2015 :)
>
> We also talked a little bit about metrics (with the recent support for
> Hadoop metrics2 added) which helped bring some other devs up to speed who
> hadn't looked at what such support really means.
>
> Let me know if I forgot anything other attendees.
>
>
> Josh Elser wrote:
>
>> I'd be happy to. Not too much discussion yet, but if we talk about
>> anything that doesn't end up on JIRA or elsewhere, I'll make sure it
>> gets posted here.
>>
>> - Josh
>>
>> Mike Drob wrote:
>>
>>> For those of us who were unable to attend, can we get a summary of what
>>> happened? I'd be curious to know if anything particularly novel came
>>> out of
>>> this collaboration!
>>>
>>> On Mon, Dec 8, 2014 at 4:06 PM, Jason Pyeron wrote:
>>>
>>>  If you are meeting near Ft. Meade I would like to drop off thank you
 doughnuts.

 -Jason

  -Original Message-
> From: Keith Turner
> Sent: Wednesday, December 03, 2014 14:00
>
> Christopher, Eric, Josh, Billie, Mike, and I are meeting on
> Dec 9 to work
> on Accumulo together for the day in Central MD. If you are
> interested in
> joining us, email me directly. We are meeting in a small
> conf room, so
> space is limited.
>
> Keith
>
>  --
 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
 - -
 - Jason Pyeron PD Inc. http://www.pdinc.us -
 - Principal Consultant 10 West 24th Street #100 -
 - +1 (443) 269-1555 x333 Baltimore, Maryland 21218 -
 - -
 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
 This message is copyright PD Inc, subject to license 20080407P00.



>>>

Re: Accumulo Working Day

[Josh Elser]

Just so you don't think I forgot, there wasn't really much to report 
today. Lots of friendly banter among everyone.


The notable discussion was likely Don Miner stopping by and the 
collective trying to brainstorm suggestions as to who would be a good 
candidate for a "high-profile" keynote speaker for Accumulo Summit 2015 :)


We also talked a little bit about metrics (with the recent support for 
Hadoop metrics2 added) which helped bring some other devs up to speed 
who hadn't looked at what such support really means.


Let me know if I forgot anything other attendees.

Josh Elser wrote:

I'd be happy to. Not too much discussion yet, but if we talk about
anything that doesn't end up on JIRA or elsewhere, I'll make sure it
gets posted here.

- Josh

Mike Drob wrote:

For those of us who were unable to attend, can we get a summary of what
happened? I'd be curious to know if anything particularly novel came
out of
this collaboration!

On Mon, Dec 8, 2014 at 4:06 PM, Jason Pyeron wrote:


If you are meeting near Ft. Meade I would like to drop off thank you
doughnuts.

-Jason


-Original Message-
From: Keith Turner
Sent: Wednesday, December 03, 2014 14:00

Christopher, Eric, Josh, Billie, Mike, and I are meeting on
Dec 9 to work
on Accumulo together for the day in Central MD. If you are
interested in
joining us, email me directly. We are meeting in a small
conf room, so
space is limited.

Keith


--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
- -
- Jason Pyeron PD Inc. http://www.pdinc.us -
- Principal Consultant 10 West 24th Street #100 -
- +1 (443) 269-1555 x333 Baltimore, Maryland 21218 -
- -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is copyright PD Inc, subject to license 20080407P00.

Re: accumulo schema design

[Josh Elser]

We don't provide any means to pool Connectors for you; however, you 
should attempt to reuse Connectors when you can. Many libraries contain 
pool implementations which you can reuse to implement this. It is fairly 
common to simply pass around a Connector inside an application.


It isn't very expensive to make a Connector, so you also don't have to 
worry about always pooling them.


The same is true for ZooKeeperInstance objects.

panqing...@163.com wrote:

For example

Connecting to the redis, the client provides the connection pool object,
through the connection pool object implementation and database
communication, operatio



--
View this message in context: 
http://apache-accumulo.1065345.n5.nabble.com/accumulo-schema-design-tp12458p12460.html
Sent from the Developers mailing list archive at Nabble.com.

Re: accumulo schema design

[panqing...@163.com]

For example

Connecting to the redis, the client provides the connection pool object,
through the connection pool object implementation and database
communication, operatio



--
View this message in context: 
http://apache-accumulo.1065345.n5.nabble.com/accumulo-schema-design-tp12458p12460.html
Sent from the Developers mailing list archive at Nabble.com.

Re: accumulo schema design

[David Medinets]

What standardized development process are you used to using?

On Tue, Dec 9, 2014 at 8:28 PM, panqing...@163.com  wrote:
> HI
>   Now ready to write the user permissions for java example, but little
> information.
> Java in the production of accumulo connection and Java connection pool is
> needed, whether client can achieve grant, setauth these commands?
>
> In the process of using accumulo, feel the lack of a standardized
> development process. Whether this information?
>
>
>
> --
> View this message in context: 
> http://apache-accumulo.1065345.n5.nabble.com/accumulo-schema-design-tp12458.html
> Sent from the Developers mailing list archive at Nabble.com.

accumulo schema design

[panqing...@163.com]

HI 
  Now ready to write the user permissions for java example, but little
information. 
Java in the production of accumulo connection and Java connection pool is
needed, whether client can achieve grant, setauth these commands? 

In the process of using accumulo, feel the lack of a standardized
development process. Whether this information?



--
View this message in context: 
http://apache-accumulo.1065345.n5.nabble.com/accumulo-schema-design-tp12458.html
Sent from the Developers mailing list archive at Nabble.com.

Re: [VOTE] adoption of semver

[Bill Havanki]

+1

On Tue, Dec 9, 2014 at 1:23 PM, Billie Rinaldi  wrote:

> I would like to call a vote on adopting semantic versioning (
> http://semver.org/) for future releases.
>
> This vote is subject to majority approval and will remain open for 72
> hours.
>
> +1: Adopt semantic versioning for all future releases
> +0: Don't care
> -1: Do not adopt semantic versioning because ...
>
> Here is my +1.
>
> Billie
>



-- 
// Bill Havanki
// Solutions Architect, Cloudera Govt Solutions
// 443.686.9283

Re: [VOTE] API release policy for 1.7/2.0

[David Medinets]

/me snickers and points to Josh...

On Tue, Dec 9, 2014 at 3:27 PM, Josh Elser  wrote:
> Josh Elser wrote:
>>
>> Sean Busbey wrote:
>>>
>>> On Fri, Dec 5, 2014 at 5:24 PM, Christopher wrote:
>>>
 This vote fails, with:

 -1: Mike, Sean, John
 +1: Christopher, Keith

 Even without my implicit +1, or Bill and Josh's late -1's, the vote
 still
 fails.

 I think it would help if each person voting -1 (for reasons other
 than the
 fact that there is disagreement or the thread was confusing or
 difficult to
 follow), would please reply with a very short and concise summary of
 what
 guidelines they think we *should* adopt.

>>>
>>> The compromise proposed by Josh that works for me is the original with
>>> the
>>> addition of
>>>
>>> * No client RPC removals or change in behavior of extant calls prior
>>> to 2.0
>>> (non-inclusive or inclusive doesn't matter to me)
>>> * Documenting the above in release notes for 1.x by way of tests that
>>> clients compiled with 1.6 work when talking to a cluster running the
>>> newer
>>> release
>>>
>>
>> Thanks *so* much for the clarity here. This greatly helps.
>>
>> The only thing that is a concern about testing of 1.6 clients against
>> the newer release. Are you signing up to do said testing? If you fall
>> off a bridge/get sick/etc, I don't want all newer releases to be blocked
>> until another community member volunteers or you are free to work on it.
>> Is that reasonable?
>
>
> Actually, I also (embarrassingly) don't know the compromise that I proposed
> which you're referring to. If you can re-copy that for clarity, that'd be
> wonderful.

Re: [VOTE] adoption of semver

[Adam Fuchs]

Yup, all future releases should use semver version 2.0.0.

Adam

On Tue, Dec 9, 2014 at 3:59 PM, John Vines  wrote:
> Adam, the vote isn't for 2.0.0, it's for all future releases. Can you
> please clarify your vote?
>
> On Tue, Dec 9, 2014 at 3:40 PM, Adam Fuchs  wrote:
>
>> +1 for semver version 2.0.0
>>
>> Assuming this passes, let's make sure we grab a copy for posterity and
>> post it on our site.
>>
>> Adam
>>
>> On Tue, Dec 9, 2014 at 1:23 PM, Billie Rinaldi  wrote:
>> > I would like to call a vote on adopting semantic versioning (
>> > http://semver.org/) for future releases.
>> >
>> > This vote is subject to majority approval and will remain open for 72
>> hours.
>> >
>> > +1: Adopt semantic versioning for all future releases
>> > +0: Don't care
>> > -1: Do not adopt semantic versioning because ...
>> >
>> > Here is my +1.
>> >
>> > Billie
>>

Re: [VOTE] adoption of semver

[Eric Newton]

+1

On Tue, Dec 9, 2014 at 1:23 PM, Billie Rinaldi  wrote:

> I would like to call a vote on adopting semantic versioning (
> http://semver.org/) for future releases.
>
> This vote is subject to majority approval and will remain open for 72
> hours.
>
> +1: Adopt semantic versioning for all future releases
> +0: Don't care
> -1: Do not adopt semantic versioning because ...
>
> Here is my +1.
>
> Billie
>

Re: [VOTE] adoption of semver

[Josh Elser]

I think he meant semver-2.0.0, not Accumulo-2.0.0.. :)

John Vines wrote:

Adam, the vote isn't for 2.0.0, it's for all future releases. Can you
please clarify your vote?

On Tue, Dec 9, 2014 at 3:40 PM, Adam Fuchs  wrote:


+1 for semver version 2.0.0

Assuming this passes, let's make sure we grab a copy for posterity and
post it on our site.

Adam

On Tue, Dec 9, 2014 at 1:23 PM, Billie Rinaldi  wrote:

I would like to call a vote on adopting semantic versioning (
http://semver.org/) for future releases.

This vote is subject to majority approval and will remain open for 72

hours.

+1: Adopt semantic versioning for all future releases
+0: Don't care
-1: Do not adopt semantic versioning because ...

Here is my +1.

Billie

Re: [VOTE] adoption of semver

[John Vines]

Adam, the vote isn't for 2.0.0, it's for all future releases. Can you
please clarify your vote?

On Tue, Dec 9, 2014 at 3:40 PM, Adam Fuchs  wrote:

> +1 for semver version 2.0.0
>
> Assuming this passes, let's make sure we grab a copy for posterity and
> post it on our site.
>
> Adam
>
> On Tue, Dec 9, 2014 at 1:23 PM, Billie Rinaldi  wrote:
> > I would like to call a vote on adopting semantic versioning (
> > http://semver.org/) for future releases.
> >
> > This vote is subject to majority approval and will remain open for 72
> hours.
> >
> > +1: Adopt semantic versioning for all future releases
> > +0: Don't care
> > -1: Do not adopt semantic versioning because ...
> >
> > Here is my +1.
> >
> > Billie
>

Re: [VOTE] adoption of semver

[Brian Loss]

+1


> On Dec 9, 2014, at 3:23 PM, Billie Rinaldi  wrote:
> 
> I would like to call a vote on adopting semantic versioning (
> http://semver.org/) for future releases.
> 
> This vote is subject to majority approval and will remain open for 72 hours.
> 
> +1: Adopt semantic versioning for all future releases
> +0: Don't care
> -1: Do not adopt semantic versioning because ...
> 
> Here is my +1.
> 
> Billie

Re: [VOTE] adoption of semver

[Adam Fuchs]

+1 for semver version 2.0.0

Assuming this passes, let's make sure we grab a copy for posterity and
post it on our site.

Adam

On Tue, Dec 9, 2014 at 1:23 PM, Billie Rinaldi  wrote:
> I would like to call a vote on adopting semantic versioning (
> http://semver.org/) for future releases.
>
> This vote is subject to majority approval and will remain open for 72 hours.
>
> +1: Adopt semantic versioning for all future releases
> +0: Don't care
> -1: Do not adopt semantic versioning because ...
>
> Here is my +1.
>
> Billie

Re: [VOTE] API release policy for 1.7/2.0

[Josh Elser]

Josh Elser wrote:

Sean Busbey wrote:

On Fri, Dec 5, 2014 at 5:24 PM, Christopher wrote:


This vote fails, with:

-1: Mike, Sean, John
+1: Christopher, Keith

Even without my implicit +1, or Bill and Josh's late -1's, the vote
still
fails.

I think it would help if each person voting -1 (for reasons other
than the
fact that there is disagreement or the thread was confusing or
difficult to
follow), would please reply with a very short and concise summary of
what
guidelines they think we *should* adopt.



The compromise proposed by Josh that works for me is the original with
the
addition of

* No client RPC removals or change in behavior of extant calls prior
to 2.0
(non-inclusive or inclusive doesn't matter to me)
* Documenting the above in release notes for 1.x by way of tests that
clients compiled with 1.6 work when talking to a cluster running the
newer
release



Thanks *so* much for the clarity here. This greatly helps.

The only thing that is a concern about testing of 1.6 clients against
the newer release. Are you signing up to do said testing? If you fall
off a bridge/get sick/etc, I don't want all newer releases to be blocked
until another community member volunteers or you are free to work on it.
Is that reasonable?


Actually, I also (embarrassingly) don't know the compromise that I 
proposed which you're referring to. If you can re-copy that for clarity, 
that'd be wonderful.

Re: [VOTE] adoption of semver

[Billie Rinaldi]

On Tue, Dec 9, 2014 at 11:22 AM, Sean Busbey  wrote:

> +0
>
> Just for clarification, this vote isn't defining what the semver applies
> to? I presume that means the same things already covered in "Section 9 API"
> from the README[1]?
>
> [1]:
>
> https://git-wip-us.apache.org/repos/asf?p=accumulo.git;a=blob;f=README;h=a9f4645186c6431a0b68d115c7a92d18753c36f1;hb=HEAD
>

The vote applies to whatever we determine to be the public API, which is
currently defined in Section 9 of the README.


>
> On Tue, Dec 9, 2014 at 1:07 PM, John Vines  wrote:
>
> > +1
> >
> > On Tue, Dec 9, 2014 at 1:30 PM, Keith Turner  wrote:
> >
> > > +1
> > >
> > > On Tue, Dec 9, 2014 at 1:23 PM, Billie Rinaldi 
> > wrote:
> > >
> > > > I would like to call a vote on adopting semantic versioning (
> > > > http://semver.org/) for future releases.
> > > >
> > > > This vote is subject to majority approval and will remain open for 72
> > > > hours.
> > > >
> > > > +1: Adopt semantic versioning for all future releases
> > > > +0: Don't care
> > > > -1: Do not adopt semantic versioning because ...
> > > >
> > > > Here is my +1.
> > > >
> > > > Billie
> > > >
> > >
> >
>
>
>
> --
> Sean
>

Re: [VOTE] adoption of semver

[Corey Nolet]

+1

On Tue, Dec 9, 2014 at 2:56 PM, David Medinets 
wrote:

> +1
>
> On Tue, Dec 9, 2014 at 2:22 PM, Sean Busbey  wrote:
> > +0
> >
> > Just for clarification, this vote isn't defining what the semver applies
> > to? I presume that means the same things already covered in "Section 9
> API"
> > from the README[1]?
> >
> > [1]:
> >
> https://git-wip-us.apache.org/repos/asf?p=accumulo.git;a=blob;f=README;h=a9f4645186c6431a0b68d115c7a92d18753c36f1;hb=HEAD
> >
> > On Tue, Dec 9, 2014 at 1:07 PM, John Vines  wrote:
> >
> >> +1
> >>
> >> On Tue, Dec 9, 2014 at 1:30 PM, Keith Turner  wrote:
> >>
> >> > +1
> >> >
> >> > On Tue, Dec 9, 2014 at 1:23 PM, Billie Rinaldi 
> >> wrote:
> >> >
> >> > > I would like to call a vote on adopting semantic versioning (
> >> > > http://semver.org/) for future releases.
> >> > >
> >> > > This vote is subject to majority approval and will remain open for
> 72
> >> > > hours.
> >> > >
> >> > > +1: Adopt semantic versioning for all future releases
> >> > > +0: Don't care
> >> > > -1: Do not adopt semantic versioning because ...
> >> > >
> >> > > Here is my +1.
> >> > >
> >> > > Billie
> >> > >
> >> >
> >>
> >
> >
> >
> > --
> > Sean
>

Re: [VOTE] adoption of semver

[David Medinets]

+1

On Tue, Dec 9, 2014 at 2:22 PM, Sean Busbey  wrote:
> +0
>
> Just for clarification, this vote isn't defining what the semver applies
> to? I presume that means the same things already covered in "Section 9 API"
> from the README[1]?
>
> [1]:
> https://git-wip-us.apache.org/repos/asf?p=accumulo.git;a=blob;f=README;h=a9f4645186c6431a0b68d115c7a92d18753c36f1;hb=HEAD
>
> On Tue, Dec 9, 2014 at 1:07 PM, John Vines  wrote:
>
>> +1
>>
>> On Tue, Dec 9, 2014 at 1:30 PM, Keith Turner  wrote:
>>
>> > +1
>> >
>> > On Tue, Dec 9, 2014 at 1:23 PM, Billie Rinaldi 
>> wrote:
>> >
>> > > I would like to call a vote on adopting semantic versioning (
>> > > http://semver.org/) for future releases.
>> > >
>> > > This vote is subject to majority approval and will remain open for 72
>> > > hours.
>> > >
>> > > +1: Adopt semantic versioning for all future releases
>> > > +0: Don't care
>> > > -1: Do not adopt semantic versioning because ...
>> > >
>> > > Here is my +1.
>> > >
>> > > Billie
>> > >
>> >
>>
>
>
>
> --
> Sean

Re: [VOTE] API release policy for 1.7/2.0

[Josh Elser]

Sean Busbey wrote:

On Fri, Dec 5, 2014 at 5:24 PM, Christopher  wrote:


This vote fails, with:

-1: Mike, Sean, John
+1: Christopher, Keith

Even without my implicit +1, or Bill and Josh's late -1's, the vote still
fails.

I think it would help if each person voting -1 (for reasons other than the
fact that there is disagreement or the thread was confusing or difficult to
follow), would please reply with a very short and concise summary of what
guidelines they think we *should* adopt.



The compromise proposed by Josh that works for me is the original with the
addition of

* No client RPC removals or change in behavior of extant calls prior to 2.0
(non-inclusive or inclusive doesn't matter to me)
* Documenting the above in release notes for 1.x by way of tests that
clients compiled with 1.6 work when talking to a cluster running the newer
release



Thanks *so* much for the clarity here. This greatly helps.

The only thing that is a concern about testing of 1.6 clients against 
the newer release. Are you signing up to do said testing? If you fall 
off a bridge/get sick/etc, I don't want all newer releases to be blocked 
until another community member volunteers or you are free to work on it. 
Is that reasonable?

Re: [VOTE] adoption of semver

[Sean Busbey]

+0

Just for clarification, this vote isn't defining what the semver applies
to? I presume that means the same things already covered in "Section 9 API"
from the README[1]?

[1]:
https://git-wip-us.apache.org/repos/asf?p=accumulo.git;a=blob;f=README;h=a9f4645186c6431a0b68d115c7a92d18753c36f1;hb=HEAD

On Tue, Dec 9, 2014 at 1:07 PM, John Vines  wrote:

> +1
>
> On Tue, Dec 9, 2014 at 1:30 PM, Keith Turner  wrote:
>
> > +1
> >
> > On Tue, Dec 9, 2014 at 1:23 PM, Billie Rinaldi 
> wrote:
> >
> > > I would like to call a vote on adopting semantic versioning (
> > > http://semver.org/) for future releases.
> > >
> > > This vote is subject to majority approval and will remain open for 72
> > > hours.
> > >
> > > +1: Adopt semantic versioning for all future releases
> > > +0: Don't care
> > > -1: Do not adopt semantic versioning because ...
> > >
> > > Here is my +1.
> > >
> > > Billie
> > >
> >
>



-- 
Sean

Re: [VOTE] API release policy for 1.7/2.0

[Sean Busbey]

On Fri, Dec 5, 2014 at 5:24 PM, Christopher  wrote:

> This vote fails, with:
>
> -1: Mike, Sean, John
> +1: Christopher, Keith
>
> Even without my implicit +1, or Bill and Josh's late -1's, the vote still
> fails.
>
> I think it would help if each person voting -1 (for reasons other than the
> fact that there is disagreement or the thread was confusing or difficult to
> follow), would please reply with a very short and concise summary of what
> guidelines they think we *should* adopt.
>

The compromise proposed by Josh that works for me is the original with the
addition of

* No client RPC removals or change in behavior of extant calls prior to 2.0
(non-inclusive or inclusive doesn't matter to me)
* Documenting the above in release notes for 1.x by way of tests that
clients compiled with 1.6 work when talking to a cluster running the newer
release


-- 
Sean

Re: [VOTE] adoption of semver

[John Vines]

+1

On Tue, Dec 9, 2014 at 1:30 PM, Keith Turner  wrote:

> +1
>
> On Tue, Dec 9, 2014 at 1:23 PM, Billie Rinaldi  wrote:
>
> > I would like to call a vote on adopting semantic versioning (
> > http://semver.org/) for future releases.
> >
> > This vote is subject to majority approval and will remain open for 72
> > hours.
> >
> > +1: Adopt semantic versioning for all future releases
> > +0: Don't care
> > -1: Do not adopt semantic versioning because ...
> >
> > Here is my +1.
> >
> > Billie
> >
>

Re: [VOTE] adoption of semver

[dlmarion]

+1 

- Original Message -

From: "Billie Rinaldi"  
To: "Accumulo Dev List"  
Sent: Tuesday, December 9, 2014 1:23:02 PM 
Subject: [VOTE] adoption of semver 

I would like to call a vote on adopting semantic versioning ( 
http://semver.org/) for future releases. 

This vote is subject to majority approval and will remain open for 72 hours. 

+1: Adopt semantic versioning for all future releases 
+0: Don't care 
-1: Do not adopt semantic versioning because ... 

Here is my +1. 

Billie 

Re: [VOTE] adoption of semver

[Keith Turner]

+1

On Tue, Dec 9, 2014 at 1:23 PM, Billie Rinaldi  wrote:

> I would like to call a vote on adopting semantic versioning (
> http://semver.org/) for future releases.
>
> This vote is subject to majority approval and will remain open for 72
> hours.
>
> +1: Adopt semantic versioning for all future releases
> +0: Don't care
> -1: Do not adopt semantic versioning because ...
>
> Here is my +1.
>
> Billie
>

Re: [VOTE] adoption of semver

[Josh Elser]

+1

Billie Rinaldi wrote:

I would like to call a vote on adopting semantic versioning (
http://semver.org/) for future releases.

This vote is subject to majority approval and will remain open for 72 hours.

+1: Adopt semantic versioning for all future releases
+0: Don't care
-1: Do not adopt semantic versioning because ...

Here is my +1.

Billie

[VOTE] adoption of semver

[Billie Rinaldi]

I would like to call a vote on adopting semantic versioning (
http://semver.org/) for future releases.

This vote is subject to majority approval and will remain open for 72 hours.

+1: Adopt semantic versioning for all future releases
+0: Don't care
-1: Do not adopt semantic versioning because ...

Here is my +1.

Billie

Re: [VOTE] adoption of semver

[Christopher]

+1


--
Christopher L Tubbs II
http://gravatar.com/ctubbsii

On Tue, Dec 9, 2014 at 1:23 PM, Billie Rinaldi  wrote:

> I would like to call a vote on adopting semantic versioning (
> http://semver.org/) for future releases.
>
> This vote is subject to majority approval and will remain open for 72
> hours.
>
> +1: Adopt semantic versioning for all future releases
> +0: Don't care
> -1: Do not adopt semantic versioning because ...
>
> Here is my +1.
>
> Billie
>

Re: Review Request 28739: ACCUMULO-3134 Added file selection and output configuration to compact command

[keith]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/28739/
---

(Updated Dec. 9, 2014, 5:57 p.m.)


Review request for accumulo.


Changes
---

improved help message


Bugs: ACCUMULO-3134
https://issues.apache.org/jira/browse/ACCUMULO-3134


Repository: accumulo


Description
---

Added file selection and output configuration to shell compact command


Diffs (updated)
-

  
core/src/main/java/org/apache/accumulo/core/compaction/CompactionSettings.java 
PRE-CREATION 
  
server/tserver/src/main/java/org/apache/accumulo/tserver/compaction/strategies/ConfigurableCompactionStrategy.java
 PRE-CREATION 
  
server/tserver/src/test/java/org/apache/accumulo/tserver/compaction/strategies/ConfigurableCompactionStrategyTest.java
 PRE-CREATION 
  shell/src/main/java/org/apache/accumulo/shell/Shell.java 8927ee0 
  shell/src/main/java/org/apache/accumulo/shell/commands/CompactCommand.java 
660630e 
  test/src/test/java/org/apache/accumulo/test/ShellServerIT.java d878c7f 

Diff: https://reviews.apache.org/r/28739/diff/


Testing
---

Added an IT that test file selection options on compact command.  IT does not 
test output file configuration.


Thanks,

kturner

Re: Review Request 28739: ACCUMULO-3134 Added file selection and output configuration to compact command

[Josh Elser]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/28739/#review64395
---

Ship it!


Thanks for adding the doc, after that minor clarification, it's good to commit 
IMO.

- Josh Elser


On Dec. 9, 2014, 5:32 p.m., kturner wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/28739/
> ---
> 
> (Updated Dec. 9, 2014, 5:32 p.m.)
> 
> 
> Review request for accumulo.
> 
> 
> Bugs: ACCUMULO-3134
> https://issues.apache.org/jira/browse/ACCUMULO-3134
> 
> 
> Repository: accumulo
> 
> 
> Description
> ---
> 
> Added file selection and output configuration to shell compact command
> 
> 
> Diffs
> -
> 
>   
> core/src/main/java/org/apache/accumulo/core/compaction/CompactionSettings.java
>  PRE-CREATION 
>   
> server/tserver/src/main/java/org/apache/accumulo/tserver/compaction/strategies/ConfigurableCompactionStrategy.java
>  PRE-CREATION 
>   
> server/tserver/src/test/java/org/apache/accumulo/tserver/compaction/strategies/ConfigurableCompactionStrategyTest.java
>  PRE-CREATION 
>   shell/src/main/java/org/apache/accumulo/shell/Shell.java 8927ee0 
>   shell/src/main/java/org/apache/accumulo/shell/commands/CompactCommand.java 
> 660630e 
>   test/src/test/java/org/apache/accumulo/test/ShellServerIT.java d878c7f 
> 
> Diff: https://reviews.apache.org/r/28739/diff/
> 
> 
> Testing
> ---
> 
> Added an IT that test file selection options on compact command.  IT does not 
> test output file configuration.
> 
> 
> Thanks,
> 
> kturner
> 
>

Re: Review Request 28739: ACCUMULO-3134 Added file selection and output configuration to compact command

[Josh Elser]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/28739/#review64394
---



shell/src/main/java/org/apache/accumulo/shell/commands/CompactCommand.java


This is a little confusing to me. You mean that tablets which have a single 
file are compacted in addition to tablets with more than one file?


- Josh Elser


On Dec. 9, 2014, 5:32 p.m., kturner wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/28739/
> ---
> 
> (Updated Dec. 9, 2014, 5:32 p.m.)
> 
> 
> Review request for accumulo.
> 
> 
> Bugs: ACCUMULO-3134
> https://issues.apache.org/jira/browse/ACCUMULO-3134
> 
> 
> Repository: accumulo
> 
> 
> Description
> ---
> 
> Added file selection and output configuration to shell compact command
> 
> 
> Diffs
> -
> 
>   
> core/src/main/java/org/apache/accumulo/core/compaction/CompactionSettings.java
>  PRE-CREATION 
>   
> server/tserver/src/main/java/org/apache/accumulo/tserver/compaction/strategies/ConfigurableCompactionStrategy.java
>  PRE-CREATION 
>   
> server/tserver/src/test/java/org/apache/accumulo/tserver/compaction/strategies/ConfigurableCompactionStrategyTest.java
>  PRE-CREATION 
>   shell/src/main/java/org/apache/accumulo/shell/Shell.java 8927ee0 
>   shell/src/main/java/org/apache/accumulo/shell/commands/CompactCommand.java 
> 660630e 
>   test/src/test/java/org/apache/accumulo/test/ShellServerIT.java d878c7f 
> 
> Diff: https://reviews.apache.org/r/28739/diff/
> 
> 
> Testing
> ---
> 
> Added an IT that test file selection options on compact command.  IT does not 
> test output file configuration.
> 
> 
> Thanks,
> 
> kturner
> 
>

Re: Review Request 28739: ACCUMULO-3134 Added file selection and output configuration to compact command

[keith]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/28739/
---

(Updated Dec. 9, 2014, 5:32 p.m.)


Review request for accumulo.


Changes
---

updated help for shell compact command


Bugs: ACCUMULO-3134
https://issues.apache.org/jira/browse/ACCUMULO-3134


Repository: accumulo


Description
---

Added file selection and output configuration to shell compact command


Diffs (updated)
-

  
core/src/main/java/org/apache/accumulo/core/compaction/CompactionSettings.java 
PRE-CREATION 
  
server/tserver/src/main/java/org/apache/accumulo/tserver/compaction/strategies/ConfigurableCompactionStrategy.java
 PRE-CREATION 
  
server/tserver/src/test/java/org/apache/accumulo/tserver/compaction/strategies/ConfigurableCompactionStrategyTest.java
 PRE-CREATION 
  shell/src/main/java/org/apache/accumulo/shell/Shell.java 8927ee0 
  shell/src/main/java/org/apache/accumulo/shell/commands/CompactCommand.java 
660630e 
  test/src/test/java/org/apache/accumulo/test/ShellServerIT.java d878c7f 

Diff: https://reviews.apache.org/r/28739/diff/


Testing
---

Added an IT that test file selection options on compact command.  IT does not 
test output file configuration.


Thanks,

kturner

Re: [DISCUSS] Semantic Versioning

[Josh Elser]

This sounds good. Looking forward to a vote on this. Thanks, Christopher.

Christopher wrote:

Also, I think the wording "adopt semver in 1.7.0" is an incorrect way of
thinking about it. What we'd do is adopt semver for future releases, and
the master branch would be bound to those guidelines. We wouldn't be
"adopting in 1.7.0", but adopting rules which determine what the next
version should be called.


--
Christopher L Tubbs II
http://gravatar.com/ctubbsii

On Mon, Dec 8, 2014 at 7:01 PM, Christopher  wrote:


Ack! My clarity failed: I *DO* expect 1.7.0 to be ready before a new
client API is added.


--
Christopher L Tubbs II
http://gravatar.com/ctubbsii

On Mon, Dec 8, 2014 at 7:00 PM, Christopher  wrote:


Yes, that seems like a correct interpretation. However, to be clear, I do
not expect 1.7.0 will be ready before a new client API is added.


--
Christopher L Tubbs II
http://gravatar.com/ctubbsii

On Mon, Dec 8, 2014 at 6:54 PM, John Vines  wrote:


Just to make sure I'm understanding this before we get into another vote
thread kerfluffle, if we adopt semver in 1.7.0, include a new client api
in
1.7.0, deprecate the old api in 1.7.0, then semver would allow (but not
require) removing the deprecated api in 2.0.0, correct?

On Mon, Dec 8, 2014 at 6:21 PM, Christopher  wrote:


Short Summary:

I see 6 informal +1s (including my own) for adopting Semver, and no

-1s.

Other points differ.

Longer Summary:

Including additional strictness for deprecation documented in a major
release does not have significant consensus and, in hindsight, probably
doesn't really add much value. Semver does not bind us to a particular
release cycle for major/minor/bugfix, only what we call it when we make
certain changes. The basic Semver rules are sufficient.

Including additional strictness for forward compatibility isn't

necessary.

Semver requires a minor version bump if new features are added to the

API.

So, this is redundant and not needed.

Including the wire version is tough without a test framework, and maybe
unnecessary, since the main concern about compatibility seems to be

with

applications needing to be modified to function with a newer client
library, which contains the RPC code. If we ensure compatibility at the
API, then users simply need to drop in the appropriate client jars for

wire

compatibility. This is probably sufficient.

There seems to be some confusion about when and where these rules are
applied. However, I believe we can go ahead and start adopting these

rules

from here on, without any issues. This doesn't hurt users, and only

*adds*

to the stability of the API, which we've already been striving for. It

also

doesn't bind us to a particular release cycle or deprecation duration.

It

only helps us determine what minimum version we should call something,

when

we do release. Upon adoption, the "master" branch version can be

computed

from the rules. If that computation requires a bump higher than what

we are

comfortable with, we can always ensure a greater level of compatibility
than what currently exists, in order to avoid that bump, if we so

choose.

Adoption of these rules should help inform such discussions.

Now, to be clear, it may be the case that the 1.5 and 1.6 maintenance
branches already have introduced additional APIs that under Semver

would

have required a minor version bump. I'm not suggesting that we revert

those

changes, but by adopting the Semver, we can agree to avoid doing that

from

here on. Since 1.7 already adds additional features, by adopting

Semver, we

simply agree that the master branch should be called 2.0 if it is not
backwards-compatible with 1.6.x, and 1.7.0 if it is. Adopting these

rules

helps inform that decision, but does not make that decision for us.

Either

way, that decision would be independent of adopting Semver today for

all

future releases. Incidentally, this answers the question of whether

2.0 can

introduce "breaking" (removal of deprecations) changes, but it does

not say

that we must stop support for 1.x or release 2.0 on any particular
timeline.

Action:

In the absence of further discussion, I think we should call a majority
vote (tomorrow) to adopt Semver, so we can immediately start

communicating

better versioning semantics, and we can make progress with a concrete
decision to help with release planning. The specific wording of the
proposition I would suggest (please propose amendments here if you

think it

is unclear) would be:

"Vote to adopt Semantic Versioning 2.0.0 (as described at
https://semver.org)
from this point forward, for all future releases, with the public API
documented in the README."

--
Christopher L Tubbs II
http://gravatar.com/ctubbsii

Re: Accumulo Working Day

[Josh Elser]

I'd be happy to. Not too much discussion yet, but if we talk about 
anything that doesn't end up on JIRA or elsewhere, I'll make sure it 
gets posted here.


- Josh

Mike Drob wrote:

For those of us who were unable to attend, can we get a summary of what
happened? I'd be curious to know if anything particularly novel came out of
this collaboration!

On Mon, Dec 8, 2014 at 4:06 PM, Jason Pyeron  wrote:


If you are meeting near Ft. Meade I would like to drop off thank you
doughnuts.

-Jason


-Original Message-
From: Keith Turner
Sent: Wednesday, December 03, 2014 14:00

Christopher, Eric, Josh, Billie, Mike, and I are meeting on
Dec 9 to work
on Accumulo together for the day in Central MD.  If you are
interested in
joining us, email me directly.   We are meeting in a small
conf room, so
space is limited.

Keith


--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-   -
- Jason Pyeron  PD Inc. http://www.pdinc.us -
- Principal Consultant  10 West 24th Street #100-
- +1 (443) 269-1555 x333Baltimore, Maryland 21218   -
-   -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is copyright PD Inc, subject to license 20080407P00.

Re: Accumulo Working Day

[Mike Drob]

For those of us who were unable to attend, can we get a summary of what
happened? I'd be curious to know if anything particularly novel came out of
this collaboration!

On Mon, Dec 8, 2014 at 4:06 PM, Jason Pyeron  wrote:

> If you are meeting near Ft. Meade I would like to drop off thank you
> doughnuts.
>
> -Jason
>
> > -Original Message-
> > From: Keith Turner
> > Sent: Wednesday, December 03, 2014 14:00
> >
> > Christopher, Eric, Josh, Billie, Mike, and I are meeting on
> > Dec 9 to work
> > on Accumulo together for the day in Central MD.  If you are
> > interested in
> > joining us, email me directly.   We are meeting in a small
> > conf room, so
> > space is limited.
> >
> > Keith
> >
>
> --
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> -   -
> - Jason Pyeron  PD Inc. http://www.pdinc.us -
> - Principal Consultant  10 West 24th Street #100-
> - +1 (443) 269-1555 x333Baltimore, Maryland 21218   -
> -   -
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> This message is copyright PD Inc, subject to license 20080407P00.
>
>