accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Elser <josh.el...@gmail.com>
Subject Re: [DISCUSS] Not Deploying Monitor as a WAR
Date Mon, 30 Mar 2015 22:14:42 GMT
btw, top-level issue: https://issues.apache.org/jira/browse/ACCUMULO-3034

Mike Drob wrote:
> 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

Cool, glad that isn't an issue. Hopefully I can swing back around to 
this and finish it eventually. It was much nicer than before:

https://github.com/joshelser/accumulo/tree/jersey-monitor

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

Absolutely. Things should work out of the box on most app servers; 
hopefully we can rely on the community to share results as people try it 
out themselves. Hard to guess at where things might break.

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

We presently have 4 test classes in monitor/ and none of them test that 
the servlets themselves. I know we have an IT or two which pull the 
index page of the monitor, but they're not actually verifying anything 
other than an HTTP/200 IIRC.

IMO, we have no monitor tests right now. It's extremely likely to be 
broken, gets broken silently often 
(https://issues.apache.org/jira/browse/ACCUMULO-3691 is a great recent 
example), and only get noticed via devs looking at the monitor on their own.

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

Sure, but that's not baked into the server presently -- the 
authentication we do is internal to the "application". As long as we can 
provide uniform means to deploy the application in the server with SSL, 
we should be fine. Stuff like this goes into server.xml (I'm not 100% 
sure if that's uniform across all servers or not -- probably in the 
simplest form).

Obviously, more complicated authentication/authorization schemes will be 
server-dependent.

>
>>   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
View raw message