Mailing-List: contact dev-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@accumulo.apache.org
Received-SPF: pass (athena.apache.org: domain of josh.elser@gmail.com
 designates 209.85.192.53 as permitted sender)
Message-ID: <5519C346.9040109@gmail.com>
Date: Mon, 30 Mar 2015 17:42:30 -0400
From: Josh Elser <josh.elser@gmail.com>
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: dev@accumulo.apache.org
Subject: Re: [DISCUSS] Not Deploying Monitor as a WAR
References: 
 <CAFAMeYLmgyTonrddBq_hNZQMiLmfptAURVEhLTEU1OJFZ_5YYw@mail.gmail.com>
In-Reply-To: 
 <CAFAMeYLmgyTonrddBq_hNZQMiLmfptAURVEhLTEU1OJFZ_5YYw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

I don't recall the exact ticket either (despite owning it at least at 
one point), but the intent wasn't to force users to only deploy the 
monitor in some server as a WAR, but enable users who wish to do that to 
be able to.

The default would still be launching a standalone webserver as is done 
presently via Jetty.

Some more inline:

Mike Drob wrote:
> Hey Accumulators,
>
> I was thinking about this, and couldn't find the appropriate JIRA, so I'm
> brining it up on the mailing list.
>
> I think I'm opposed to packaging the monitor as a WAR and trusting users to
> figure out how to make that work.
>   - We'll have to develop community knowledge on several technologies to
> provide support. Some users will prefer Tomcat, some Jetty, others JBoss,
> etc... When a problem is reported, it will be hard to tell if it's a
> container issue or an Accumulo issue, all adding to our support burden.

Relying on Servlet3 should alleviate most of the concerns for 
implementation specifics. I think wiring up a security layer to the 
monitor is very specific. Given that we don't have anything presently, I 
think that's a minor concern (and would need to be addressed if/when we 
get there).

>   - We'll have to seriously rework a bunch of tests to set up containers for
> the Monitor.

What monitor tests? We have next to none that test much anything 
meaningful. I don't see testing burden as a reason to not make a change 
that (is intended) to also make things more testable.

>   - I don't think this would gain us anything in terms of security, and
> might make things like KRB trickier to use.

I'm not sure if the authentication Filter classes fall into any defined 
specification, but enabling SPNEGO is already a todo. Running on a 
Kerberos-enabled cluster doesn't require SPENGO to be enabled as we are 
already banking on nothing (overly) sensitive being displayed in the 
monitor (whereas HDFS has the ability to traverse the filesystem).

> This isn't a complete list, but I would be interested in having this
> conversation. I don't know how much work has already been done on the topic
> (Christopher?).
>
>
> Thanks,
> Mike
>