On Mon, Mar 30, 2015 at 4:42 PM, Josh Elser <[email protected]> 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 >> >>
