Just to clarify, we're saying when adding a service to the mpack that Kerberos 
support is required... but we're not saying that installing Metron requires a 
kerberized cluster correct? I think we should support it but should allow 
installation and use of Metron without it (for testing or other reasons 
determined by the user).

-Kyle

> On Apr 13, 2017, at 12:55 PM, Otto Fowler <ottobackwa...@gmail.com> wrote:
> 
> My thought was that if it was a requirement, or blocker for contribution we
> would want
> to provide something to help.
> 
> I am not sure everyone will have a kerberos cluster to test with.  Maybe
> they will.
> Maybe the answer is Docker or Vagrant as Casey suggests and not integration
> testing.
> 
> 
> 
> On April 13, 2017 at 12:02:08, James Sirota (jsir...@apache.org) wrote:
> 
> Hi Guys,
> 
> I don't like further bloating our integration tests so I am not sure I like
> the idea. I think when people add new services they should test on real
> clusters using kerberos. Also, community members can take on end-to-end
> testing in advance of a release on a cluster using kerberos. But I think
> adding this to our integration test framework is just too much.
> 
> 13.04.2017, 08:12, "Casey Stella" <ceste...@gmail.com>:
>> 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
>>>>> 
> 
> -------------------
> Thank you,
> 
> James Sirota
> PPMC- Apache Metron (Incubating)
> jsirota AT apache DOT org

Reply via email to