accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Keith Turner <>
Subject Re: [DISCUSS] MiniAccumuloCluster goals and approach
Date Wed, 26 Mar 2014 18:57:14 GMT
What you are trying to do sounds interesting.  It also sounds experimental
and in the early stages.   Is there anything specific you think should be
done for 1.6.0 w/ regards to MAC API?

On Wed, Mar 26, 2014 at 2:26 PM, Josh Elser <> wrote:

> On 3/26/14, 11:13 AM, Keith Turner wrote:
>> On Wed, Mar 26, 2014 at 2:05 PM, Josh Elser <> wrote:
>>  On 3/26/14, 10:57 AM, Keith Turner wrote:
>>>  Can you give an example of what you are thinking of? I don't understand
>>>> you
>>>> viewpoint either
>>> Sure. One limitation of MAC, in general as a testing harness, is that it
>>> doesn't adequately exercise multi-node implementations. You can run
>>> multiple tservers, but they are all on the same host which limits the
>>> validity of a "robust" test. This is my immediate goal.
>>> Multi-node deployments are capable using something like Mesos or Yarn.
>>> Given that there is already functioning support to deploy Accumulo on
>>> Yarn,
>>> this was my goal.
>>> My goal is to be able to have the ability to run all of our AbstractMacIT
>>> implementations against "real" hardware without changing a single line of
>>> test code (ok - maybe a line or two to do injection of the MAC
>>> implementation). The point is, I believe there could be a huge testing
>>> gain
>>> from being able to write tests which leverage yarn, have the same
>>> programmatic configuration API from MAC, and provide near "real" Accumulo
>>> semantics.
>> Ok so you want to MAC to be an interface so that you can provide a
>> completely different implementation?
> Correct. Some things would serve well in a common abstract base (e.g.
> numTservers, siteXml configuration), but all the nonsense about creating
> directory structures and managing Processes is implementation specific.
> Perhaps I could create a new interface that the current implementation
> implements which still provides the same semantics from 1.4 and 1.5. Let me
> see if I can mock up what I'm thinking -- that will probably be easier than
> me trying to write it out.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message