Based on my understanding, we have a few axioms that we're working from: - The installer should install a complete and workable product (i.e. after install, everything should work). Afterall, that has to be the sensible definition of 'working' for an installer - Metron should support running in a Kerberized environment
If we are going to support kerberos and the installer is going to install the product, then I would consider lack of kerberos support for a component to block inclusion into the mpack. Casey On Thu, Apr 13, 2017 at 9:29 AM, Ryan Merriman <merrim...@gmail.com> wrote: > There is a PR up for review ( > https://github.com/apache/incubator-metron/pull/518) that updates our > MPack > to support a Kerberized environment. There is also a PR up for review that > adds the REST service to the MPack ( > https://github.com/apache/incubator-metron/pull/500). > > However, the REST application currently does not work in a kerberized > environment. That work has already started so it won't be an issue for > long but how should we handle situations like this in the future where we > want to add a service but it's not quite ready for Kerberos? Should > Kerberos support be a prerequisite before it's added to the MPack? Should > we look at ways to make these services optional? Any other thoughts or > ideas? > > Ryan >
