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