accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Drob <mad...@cloudera.com>
Subject Re: [DISCUSS] Not Deploying Monitor as a WAR
Date Mon, 30 Mar 2015 21:47:33 GMT
On Mon, Mar 30, 2015 at 4:42 PM, Josh Elser <josh.elser@gmail.com> wrote:

> 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.
>
> +1


> 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).
>

Well, there could also be stuff like "in Tomcat the default number of
threads is too low for log forwarding to work, you should increase it." In
Jetty, setting Y needs to be changed. We increase our configuration surface
area by however many containers there are.

>
>    - 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 was thinking of the servlet tests, maybe those don't need to change. It
would be important to make sure that things like the shell servlet still
work on Jetty/Tomcat/etc... That would be a pretty embarrassing bug to ship
out, and I can easily see it getting missed.

>
>    - 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).
>
> Again, shell servlet means that everything is potentially displayed.

>
>  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
>>
>>

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