[DISCUSS] Not Deploying Monitor as a WAR

[Mike Drob <md...@apache.org>]

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.
 - We'll have to seriously rework a bunch of tests to set up containers for
the Monitor.
 - I don't think this would gain us anything in terms of security, and
might make things like KRB trickier to use.

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

Re: [DISCUSS] Not Deploying Monitor as a WAR

[Christopher <ct...@apache.org>]

On Mon, Mar 30, 2015 at 5:10 PM, Mike Drob <md...@apache.org> 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.
>

https://issues.apache.org/jira/browse/ACCUMULO-1325

> I think I'm opposed to packaging the monitor as a WAR and trusting users to
> figure out how to make that work.

Packaging as a war doesn't obligate users to figure out how to make it
work. It *may* make it easier to deploy in different environments. It
also *may* make our standalone server implementation simpler (Jetty
can launch/serve a war).

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

I'd expect any user using a war version instead of the standalone
script-launched Jetty version to have some basic knowledge about their
container in order to provide useful information in debugging. Stack
traces also help. Monitor issues tend to be more presentation-based,
anyway. The monitory shouldn't be doing much complex work that would
differ between containers. While I appreciate the fact that this could
become a concern... I think it's a bit early to anticipate this at
this point.

>  - We'll have to seriously rework a bunch of tests to set up containers for
> the Monitor.

Not sure I agree with this one. Wars are intended to be pretty
portable. As long as we're not doing container-specific stuff, code
tested in one container should work in others. In any case, I would
not be a favor of introducing a lot of container-specific code to do
this. If it turned out that was needed, I'd probably abandon the idea
(if it were mean doing the work).

>  - I don't think this would gain us anything in terms of security, and
> might make things like KRB trickier to use.
>

Well, it could buy us some security, if we relied on
container-provided security mechanisms which were standardized between
containers. I don't think that's the case today (we're relying on
Jetty's provided security mechanisms for TLS, if enabled, but that's
pretty much it; in my experience, I've found these things to be
notoriously divergent between containers, and pretty frustrating, so
that may end up being a show-stopper anyway). The reasons for doing
this would not be security-related reasons. They would be "development
ease", "modularity", and "deployment convenience" reasons.

We're more likely to improve our security (significantly, I would
imagine) by using standard tools, like Jersey / Jackson, and other
libraries to generate the content on our pages, rather than writing
directly to HTTP headers / body in raw servlets. But, that's a
separate issue from WAR packaging.

> 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 for bringing up the conversation and expressing your concerns.
I'm glad to have the conversation.

I think if we ended up doing this, it would be after some
experimentation to determine what roadblocks might occur. And, if we
did do it, I would not want to remove the simplicity of the current
standalone JAR-based artifact, rather use the WAR to support other
use-cases while consolidating the actual code. Leaving the current
launchable mechanism in place (rather than flat-out replace it with a
WAR) I think addresses most of your concerns.

To my knowledge, no work has been done since I created the JIRA issue.
As stated in JIRA, I've played around with that kind of packaging (in
the past), and it worked out well enough for me. But, that's not
necessarily a guarantee that it will meet our needs.

>
> Thanks,
> Mike

Re: [DISCUSS] Not Deploying Monitor as a WAR

[Josh Elser <jo...@gmail.com>]

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<jo...@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<jo...@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
>>>>>
>>>>>

Re: [DISCUSS] Not Deploying Monitor as a WAR

[David Medinets <da...@gmail.com>]

Would Spring Boot be a possibility?

On Mon, Mar 30, 2015 at 6:14 PM, Josh Elser <jo...@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<jo...@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
>>>>
>>>>
>>
>

Re: [DISCUSS] Not Deploying Monitor as a WAR

[Josh Elser <jo...@gmail.com>]

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<jo...@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
>>>
>>>
>

Re: [DISCUSS] Not Deploying Monitor as a WAR

[Mike Drob <ma...@cloudera.com>]

On Mon, Mar 30, 2015 at 4:42 PM, Josh Elser <jo...@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


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

Re: [DISCUSS] Not Deploying Monitor as a WAR

[Josh Elser <jo...@gmail.com>]

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.

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

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

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