accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Medinets <david.medin...@gmail.com>
Subject Re: [DISCUSS] Not Deploying Monitor as a WAR
Date Mon, 30 Mar 2015 22:25:15 GMT
Would Spring Boot be a possibility?

On Mon, Mar 30, 2015 at 6:14 PM, Josh Elser <josh.elser@gmail.com> wrote:
> 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