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:59:15 GMT
Anything is possible. Personally, I don't really like the idea of 
bringing in Spring dependencies, especially when I already have 
something very similar looking to their example working with Jersey.

However, my opinions shouldn't stop you from trying out Spring Boot if 
you'd like.

David Medinets wrote:
> 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