I think this is better reserved for a version later than 1.6.0. It's an 11th hour change in addition to being a large overhaul of the interfaces to support functionality we never intended for 1.6.0.
On Fri, Mar 28, 2014 at 4:04 PM, Josh Elser <[email protected]> wrote: > Forgot to also add, that I would add the experimental annotation to > alleviate confusion. > > The already mocked minimum set of methods on the interface which I posted > to github Is a first pass. If we miss something that is in fact common, we > can add it later, anything else is likely destined for the implementation. > > On Friday, March 28, 2014, Keith Turner <[email protected]> wrote: > > > On Fri, Mar 28, 2014 at 3:14 PM, Josh Elser <[email protected] > <javascript:;>> > > wrote: > > > > > Not even the addition of a new interface, Christopher? I'd very much > like > > > to have an interface that we can get in 1.6.0 at a minimum. I wouldn't > > even > > > push for any deprecation of what's currently in place. > > > > > > > W/o deprecation it seems very confusing. The intent is that users > should > > use the new one, but the old one is not deprecated. If someone is > > completely new to this, how will they know which option to use? > > > > Once you get down in the weeds of working on this, do you think you might > > end wanting something very different? > > > > > > > > > On Mar 28, 2014 10:02 AM, "Christopher" <[email protected]> wrote: > > > > > > > I don't think any of this should be done for 1.6.0, but I like the > > > > idea of creating a separate cluster interface for testing. I think it > > > > should be integrated into the accumulo-maven-plugin, also. I think > the > > > > idea should be hammered out, and tested as a separate thing, to > > > > experiment with the options, and provided as a complete feature for > > > > the next major release. If it would change packaging dependencies, it > > > > shouldn't even be done for 1.6.x bugfix releases. > > > > > > > > -- > > > > Christopher L Tubbs II > > > > http://gravatar.com/ctubbsii > > > > > > > > > > > > On Fri, Mar 28, 2014 at 12:24 PM, Josh Elser <[email protected]> > > > wrote: > > > > > Oh, I like that idea, Bill & Sean. > > > > > > > > > > Package: org.apache.accumulo.cluster > > > > > Public API: org.apache.accumulo.cluster.AccumuloCluster > > > > > MAC: org.apache.accumulo.cluster.mini.MiniAccumuloCluster > (implements > > > > > AccumuloCluster, allows for backwards compat) > > > > > Yarn: org.apache.accumulo.cluster.yarn > > > > > Docker: ... > > > > > Mesos: ... > > > > > > > > > > etc etc etc. > > > > > > > > > > One question in my mind, do we keep the maven module > > > > 'accumulo-minicluster'? > > > > > I would imagine that if we struck the 'mini' portion from 1.6 that > > > would > > > > > create some confusion. Would it be worth the indirection to rename > > > > > accumulo-minicluster to accumulo-cluster and then create a new > > > > > accumulo-minicluster module that depends on accumulo-minicluster > (but > > > > > contains no code itself) to preserve the 1.4 and 1.5 poms to > > generally > > > > work > > > > > with a version bump? I'm not sure if Maven would be happy with that > > or > > > do > > > > > what I think it "should". > > > > > > > > > > > > > > > On 3/28/14, 6:26 AM, Bill Havanki wrote: > > > > >> > > > > >> I've been watching the conversation on the side, but I wanted to > > > mention > > > > >> that it seems the focus isn't so much on "mini" clusters anymore. > > > You're > > > > >> thinking of programmatic cluster management, whether one node or > > many. > > > > The > > > > >> idea of a basic cluster management interface, with MAC as an > > > > >> implementation, is promising. A package name of just "cluster" > could > > > > work. > > > > >> > > > > >> Carry on :) > > > > >> > > > > >> Bill H > > > > >> > > > > >> > > > > >> On Fri, Mar 28, 2014 at 12:39 AM, Sean Busbey > > > > >> <[email protected]>wrote: > > > > >> > > > > >>> If you decide to go the mapred/mapreduce way, you could go with > the > > > > >>> package > > > > >>> name "mini". > > > > >>> > > > > >>> alternatively, we can do a multi-stage change out > > > > >>> > > > > >>> 1) 1.6.x: introduce TestAccumuloCluster interface, @deprecate > > > > >>> MiniAccumuloCluster class and make it implement > TestAccumuloCluster > > > > >>> > > > > >>> 2) 1.6 + major: change MiniAccumuloCluster to an interface that > > > extends > > > > >>> TestAccumuloCluster, @deprecate TestAccumuloCluster > > > > >>> > > > > >>> 3) 1.6 + 2 major: remove TestAccumuloCluster > > > > >>> > > > > >>> Or just go with TestAccumuloCluster as the interface, have > > > > >>> MiniAccumuloCluster as the local pseudo distributed > implementation, > > > and > > > > >>> then call your new one something like YarnAccumuloCluster. > > > > >>> > > > > >>> In that case we could use the deprecation cycle to move the MAC > > class > > > > out > > > > >>> of the public api. > > > > >>> > > > > >>> > > > > >>> On Thu, Mar 27, 2014 at 6:48 PM, Josh Elser < >
