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