I honestly don't know if we can mock out a KDC for integration tests. If we did move the integration tests to running against docker, that might be an option as we could dockerize a KDC as well.
Long story short, "probably, but not for free. ;)" On Thu, Apr 13, 2017 at 10:41 AM, Otto Fowler <ottobackwa...@gmail.com> wrote: > Can we test kerberized support in integration? > > > On April 13, 2017 at 10:24:43, Casey Stella (ceste...@gmail.com) wrote: > > Agreed, +1 > > On Thu, Apr 13, 2017 at 10:14 AM, Otto Fowler <ottobackwa...@gmail.com> > wrote: > >> This should be in the dev guide and pr template >> >> >> On April 13, 2017 at 09:43:48, Casey Stella (ceste...@gmail.com) wrote: >> >> 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 >> > >> >> >
