Re: [DISCUSS] Regression introduced in Full Dev

2017-04-26 Thread David Lyle
I just filter on 'to:(iss...@metron.incubator.apache.org)' and skip the
inbox. There's an interesting (and useful to me anyway) side-effect in
Gmail- issues I'm watching still end up in my inbox because JIRA also
emails me directly.

-D...


On Wed, Apr 26, 2017 at 8:13 AM, Otto Fowler 
wrote:

> It did, I didn’t see it until later in the night though, all my jira spam
> goes into one folder
> and honestly, nifi issues is flooding it.  I’ll have to split that out.
>
> Is there a metron issues list?
>
>
> On April 26, 2017 at 08:08:59, David Lyle (dlyle65...@gmail.com) wrote:
>
> Thanks Otto, the original JIRA is good. I reopened it yesterday when I had
> the issue. I was hoping it would have emailed you.
>
> -D...
>
>
> On Wed, Apr 26, 2017 at 8:04 AM, zeo...@gmail.com 
> wrote:
>
> > Interesting. I found it via pony mail -
> > https://lists.apache.org/thread.html/82e194ad8f8b8378676a28c09b074f
> > 45dee82820ead6ff8ee8fbebcc@
> > 
> >
> > But nothing in my inbox. I suspected it was @metron.incubator.apache.org
> > vs @metron.apache.org but when I attempted to subscribe to the top
> level
> > mailing list I was told I'm already subscribed. Same with User.
> >
> > Jon
> >
> > On Wed, Apr 26, 2017, 7:39 AM Justin Leet 
> wrote:
> >
> > > I have it (and had it yesterday). Subject is: "[DISCUSS] The various
> > > methods and incantations to spin up Metron".
> > >
> > > On Wed, Apr 26, 2017 at 7:33 AM, zeo...@gmail.com 
> > > wrote:
> > >
> > > > Yeah, I don't see the other thread either. Stuck in the outbox
> Casey?
> > > >
> > > > Jon
> > > >
> > > > On Wed, Apr 26, 2017, 6:53 AM Otto Fowler 
> > > wrote:
> > > >
> > > > > What other thread?
> > > > >
> > > > >
> > > > > On April 25, 2017 at 19:56:56, Casey Stella (ceste...@gmail.com)
> > > wrote:
> > > > >
> > > > > Ok, I spun up that discussion in another thread. Hopefully we can
> get
> > > > some
> > > > > better sense about the various ways to spin up metron and a
> > centralized
> > > > > place to direct people to along with with guidance on when some
> > > approach
> > > > > would be better than another.
> > > > >
> > > > > I'll be honest, I've totally lost track and never really consider
> > > > anything
> > > > > outside of full-dev anymore since it's the one that is generally
> > stable
> > > > > (quick-dev gets out of date quickly because mpack changes cause it
> to
> > > get
> > > > > stale) and is sufficient for validating PRs. Most of the other
> ones
> > > tend
> > > > > to either not have all of the system spun up (i.e. the hadoop
> > > components)
> > > > > and therefore end up with me having to test in full-dev anyway or
> > just
> > > > > weren't apparent to me and have unknown pros and cons. ;)
> > > > >
> > > > > On Tue, Apr 25, 2017 at 7:21 PM, Casey Stella 
>
> > > > wrote:
> > > > >
> > > > > > Yeah, I tend to agree that a rundown of the various methods and
> > when
> > > > you
> > > > > > would use them is in order. I will say that full-dev is
> especially
> > > > > > important to have working since it is required for validating
> PRs.
> > > > > >
> > > > > > On Tue, Apr 25, 2017 at 18:56 zeo...@gmail.com 
>
> > > > wrote:
> > > > > >
> > > > > >> Can somebody map out all of the current methods and procedures
> to
> > > spin
> > > > > up
> > > > > >> Metron components? I swear I find out about new ones every
> month.
> > > > > >> Metron-docker, the 4 vagrants, rpm-docker, ansible-docker, any
> > > others?
> > > > > >> Perhaps an agreed upon write up of when to use what would be
> > > helpful.
> > > > > >>
> > > > > >> Jon
> > > > > >>
> > > > > >> On Tue, Apr 25, 2017, 6:17 PM Ryan Merriman <
> merrim...@gmail.com>
> > > > > wrote:
> > > > > >>
> > > > > >> > A regression was introduced recently that breaks full dev.
> I've
> > > > > >> narrowed
> > > > > >> > down the commit that introduced it and have submitted a PR to
> > > revert
> > > > > >> that
> > > > > >> > commit: https://github.com/apache/incubator-metron/pull/549.
> > > > > >> >
> > > > > >> > Given there has been confusion recently over our deployment
> > build
> > > > > >> process,
> > > > > >> > I think it's appropriate that we discuss and come to a
> consensus
> > > and
> > > > > on
> > > > > >> > how this should work.
> > > > > >> >
> > > > > >> > Ryan
> > > > > >> >
> > > > > >> --
> > > > > >>
> > > > > >> Jon
> > > > > >>
> > > > > >
> > > > >
> > > > --
> > > >
> > > > Jon
> > > >
> > >
> > --
> >
> > Jon
> >
>
>


Re: [DISCUSS] Regression introduced in Full Dev

2017-04-26 Thread zeo...@gmail.com
Interesting.  I found it via pony mail -
https://lists.apache.org/thread.html/82e194ad8f8b8378676a28c09b074f45dee82820ead6ff8ee8fbebcc@


But nothing in my inbox.  I suspected it was @metron.incubator.apache.org
vs @metron.apache.org but when I attempted to subscribe to the top level
mailing list I was told I'm already subscribed.  Same with User.

Jon

On Wed, Apr 26, 2017, 7:39 AM Justin Leet  wrote:

> I have it (and had it yesterday). Subject is:  "[DISCUSS] The various
> methods and incantations to spin up Metron".
>
> On Wed, Apr 26, 2017 at 7:33 AM, zeo...@gmail.com 
> wrote:
>
> > Yeah, I don't see the other thread either.  Stuck in the outbox Casey?
> >
> > Jon
> >
> > On Wed, Apr 26, 2017, 6:53 AM Otto Fowler 
> wrote:
> >
> > > What other thread?
> > >
> > >
> > > On April 25, 2017 at 19:56:56, Casey Stella (ceste...@gmail.com)
> wrote:
> > >
> > > Ok, I spun up that discussion in another thread. Hopefully we can get
> > some
> > > better sense about the various ways to spin up metron and a centralized
> > > place to direct people to along with with guidance on when some
> approach
> > > would be better than another.
> > >
> > > I'll be honest, I've totally lost track and never really consider
> > anything
> > > outside of full-dev anymore since it's the one that is generally stable
> > > (quick-dev gets out of date quickly because mpack changes cause it to
> get
> > > stale) and is sufficient for validating PRs. Most of the other ones
> tend
> > > to either not have all of the system spun up (i.e. the hadoop
> components)
> > > and therefore end up with me having to test in full-dev anyway or just
> > > weren't apparent to me and have unknown pros and cons. ;)
> > >
> > > On Tue, Apr 25, 2017 at 7:21 PM, Casey Stella 
> > wrote:
> > >
> > > > Yeah, I tend to agree that a rundown of the various methods and when
> > you
> > > > would use them is in order. I will say that full-dev is especially
> > > > important to have working since it is required for validating PRs.
> > > >
> > > > On Tue, Apr 25, 2017 at 18:56 zeo...@gmail.com 
> > wrote:
> > > >
> > > >> Can somebody map out all of the current methods and procedures to
> spin
> > > up
> > > >> Metron components? I swear I find out about new ones every month.
> > > >> Metron-docker, the 4 vagrants, rpm-docker, ansible-docker, any
> others?
> > > >> Perhaps an agreed upon write up of when to use what would be
> helpful.
> > > >>
> > > >> Jon
> > > >>
> > > >> On Tue, Apr 25, 2017, 6:17 PM Ryan Merriman 
> > > wrote:
> > > >>
> > > >> > A regression was introduced recently that breaks full dev. I've
> > > >> narrowed
> > > >> > down the commit that introduced it and have submitted a PR to
> revert
> > > >> that
> > > >> > commit: https://github.com/apache/incubator-metron/pull/549.
> > > >> >
> > > >> > Given there has been confusion recently over our deployment build
> > > >> process,
> > > >> > I think it's appropriate that we discuss and come to a consensus
> and
> > > on
> > > >> > how this should work.
> > > >> >
> > > >> > Ryan
> > > >> >
> > > >> --
> > > >>
> > > >> Jon
> > > >>
> > > >
> > >
> > --
> >
> > Jon
> >
>
-- 

Jon


Re: [DISCUSS] Regression introduced in Full Dev

2017-04-26 Thread Otto Fowler
So I have a fix, vagrant full installs for me, with the rpm’s in
/localrepo.  I do have issues
post deploy cluster, but I think they are resource related.

How should I go about this?  What Jira would I post the PR against?  The
same as the original?



On April 26, 2017 at 07:39:07, Justin Leet (justinjl...@gmail.com) wrote:

I have it (and had it yesterday). Subject is: "[DISCUSS] The various
methods and incantations to spin up Metron".

On Wed, Apr 26, 2017 at 7:33 AM, zeo...@gmail.com  wrote:

> Yeah, I don't see the other thread either. Stuck in the outbox Casey?
>
> Jon
>
> On Wed, Apr 26, 2017, 6:53 AM Otto Fowler 
wrote:
>
> > What other thread?
> >
> >
> > On April 25, 2017 at 19:56:56, Casey Stella (ceste...@gmail.com) wrote:
> >
> > Ok, I spun up that discussion in another thread. Hopefully we can get
> some
> > better sense about the various ways to spin up metron and a centralized
> > place to direct people to along with with guidance on when some
approach
> > would be better than another.
> >
> > I'll be honest, I've totally lost track and never really consider
> anything
> > outside of full-dev anymore since it's the one that is generally stable
> > (quick-dev gets out of date quickly because mpack changes cause it to
get
> > stale) and is sufficient for validating PRs. Most of the other ones
tend
> > to either not have all of the system spun up (i.e. the hadoop
components)
> > and therefore end up with me having to test in full-dev anyway or just
> > weren't apparent to me and have unknown pros and cons. ;)
> >
> > On Tue, Apr 25, 2017 at 7:21 PM, Casey Stella 
> wrote:
> >
> > > Yeah, I tend to agree that a rundown of the various methods and when
> you
> > > would use them is in order. I will say that full-dev is especially
> > > important to have working since it is required for validating PRs.
> > >
> > > On Tue, Apr 25, 2017 at 18:56 zeo...@gmail.com 
> wrote:
> > >
> > >> Can somebody map out all of the current methods and procedures to
spin
> > up
> > >> Metron components? I swear I find out about new ones every month.
> > >> Metron-docker, the 4 vagrants, rpm-docker, ansible-docker, any
others?
> > >> Perhaps an agreed upon write up of when to use what would be
helpful.
> > >>
> > >> Jon
> > >>
> > >> On Tue, Apr 25, 2017, 6:17 PM Ryan Merriman 
> > wrote:
> > >>
> > >> > A regression was introduced recently that breaks full dev. I've
> > >> narrowed
> > >> > down the commit that introduced it and have submitted a PR to
revert
> > >> that
> > >> > commit: https://github.com/apache/incubator-metron/pull/549.
> > >> >
> > >> > Given there has been confusion recently over our deployment build
> > >> process,
> > >> > I think it's appropriate that we discuss and come to a consensus
and
> > on
> > >> > how this should work.
> > >> >
> > >> > Ryan
> > >> >
> > >> --
> > >>
> > >> Jon
> > >>
> > >
> >
> --
>
> Jon
>


Re: [DISCUSS] Regression introduced in Full Dev

2017-04-25 Thread Otto Fowler
http://stackoverflow.com/questions/22150209/maven-changes-the-order-of-plugins-of-different-profiles
https://issues.apache.org/jira/browse/MNG-2258


On April 25, 2017 at 22:33:58, Otto Fowler (ottobackwa...@gmail.com) wrote:

So, the copy resources configuration is still there, and not governed by
the profile.
Is it possible that since they both run in package, that they are out of
order?


On April 25, 2017 at 22:31:27, Otto Fowler (ottobackwa...@gmail.com) wrote:

Having said that, i see the problem.
I am very sorry


How do I go about resubmitting if I can fix it?



On April 25, 2017 at 22:29:56, Otto Fowler (ottobackwa...@gmail.com) wrote:

OK, I’ll take a look.  Sorry - I thought they read out of the RPMS dir and
verified that they were produced both ways.
I am not sure how my change would change the target copy.


On April 25, 2017 at 22:25:04, Justin Leet (justinjl...@gmail.com) wrote:

The problem seems to be that full/quick dev rely on having the RPMs in the
/target folder

>From metron-deployment/roles/metron-rpms/defaults:
metron_rpm_glob: "{{ playbook_dir
}}/../packaging/docker/rpm-docker/target/RPMS/noarch/*.rpm"

However, that PR appears to no longer copy to the /target folder run as
expected, so quick and full dev are unable to find the RPMs.

On Tue, Apr 25, 2017 at 9:26 PM, Otto Fowler 
wrote:

> Ryan, did you see why it was not working?
>
>
> On April 25, 2017 at 18:17:29, Ryan Merriman (merrim...@gmail.com) wrote:
>
> A regression was introduced recently that breaks full dev. I've narrowed
> down the commit that introduced it and have submitted a PR to revert that
> commit: https://github.com/apache/incubator-metron/pull/549.
>
> Given there has been confusion recently over our deployment build process,
> I think it's appropriate that we discuss and come to a consensus and on
> how this should work.
>
> Ryan
>


Re: [DISCUSS] Regression introduced in Full Dev

2017-04-25 Thread Otto Fowler
So, the copy resources configuration is still there, and not governed by
the profile.
Is it possible that since they both run in package, that they are out of
order?


On April 25, 2017 at 22:31:27, Otto Fowler (ottobackwa...@gmail.com) wrote:

Having said that, i see the problem.
I am very sorry


How do I go about resubmitting if I can fix it?



On April 25, 2017 at 22:29:56, Otto Fowler (ottobackwa...@gmail.com) wrote:

OK, I’ll take a look.  Sorry - I thought they read out of the RPMS dir and
verified that they were produced both ways.
I am not sure how my change would change the target copy.


On April 25, 2017 at 22:25:04, Justin Leet (justinjl...@gmail.com) wrote:

The problem seems to be that full/quick dev rely on having the RPMs in the
/target folder

>From metron-deployment/roles/metron-rpms/defaults:
metron_rpm_glob: "{{ playbook_dir
}}/../packaging/docker/rpm-docker/target/RPMS/noarch/*.rpm"

However, that PR appears to no longer copy to the /target folder run as
expected, so quick and full dev are unable to find the RPMs.

On Tue, Apr 25, 2017 at 9:26 PM, Otto Fowler 
wrote:

> Ryan, did you see why it was not working?
>
>
> On April 25, 2017 at 18:17:29, Ryan Merriman (merrim...@gmail.com) wrote:
>
> A regression was introduced recently that breaks full dev. I've narrowed
> down the commit that introduced it and have submitted a PR to revert that
> commit: https://github.com/apache/incubator-metron/pull/549.
>
> Given there has been confusion recently over our deployment build process,
> I think it's appropriate that we discuss and come to a consensus and on
> how this should work.
>
> Ryan
>


Re: [DISCUSS] Regression introduced in Full Dev

2017-04-25 Thread Otto Fowler
Having said that, i see the problem.
I am very sorry


How do I go about resubmitting if I can fix it?



On April 25, 2017 at 22:29:56, Otto Fowler (ottobackwa...@gmail.com) wrote:

OK, I’ll take a look.  Sorry - I thought they read out of the RPMS dir and
verified that they were produced both ways.
I am not sure how my change would change the target copy.


On April 25, 2017 at 22:25:04, Justin Leet (justinjl...@gmail.com) wrote:

The problem seems to be that full/quick dev rely on having the RPMs in the
/target folder

>From metron-deployment/roles/metron-rpms/defaults:
metron_rpm_glob: "{{ playbook_dir
}}/../packaging/docker/rpm-docker/target/RPMS/noarch/*.rpm"

However, that PR appears to no longer copy to the /target folder run as
expected, so quick and full dev are unable to find the RPMs.

On Tue, Apr 25, 2017 at 9:26 PM, Otto Fowler 
wrote:

> Ryan, did you see why it was not working?
>
>
> On April 25, 2017 at 18:17:29, Ryan Merriman (merrim...@gmail.com) wrote:
>
> A regression was introduced recently that breaks full dev. I've narrowed
> down the commit that introduced it and have submitted a PR to revert that
> commit: https://github.com/apache/incubator-metron/pull/549.
>
> Given there has been confusion recently over our deployment build process,
> I think it's appropriate that we discuss and come to a consensus and on
> how this should work.
>
> Ryan
>


Re: [DISCUSS] Regression introduced in Full Dev

2017-04-25 Thread Justin Leet
The problem seems to be that full/quick dev rely on having the RPMs in the
/target folder

>From metron-deployment/roles/metron-rpms/defaults:
metron_rpm_glob: "{{ playbook_dir
}}/../packaging/docker/rpm-docker/target/RPMS/noarch/*.rpm"

However, that PR appears to no longer copy to the /target folder run as
expected, so quick and full dev are unable to find the RPMs.

On Tue, Apr 25, 2017 at 9:26 PM, Otto Fowler 
wrote:

> Ryan, did you see why it was not working?
>
>
> On April 25, 2017 at 18:17:29, Ryan Merriman (merrim...@gmail.com) wrote:
>
> A regression was introduced recently that breaks full dev. I've narrowed
> down the commit that introduced it and have submitted a PR to revert that
> commit: https://github.com/apache/incubator-metron/pull/549.
>
> Given there has been confusion recently over our deployment build process,
> I think it's appropriate that we discuss and come to a consensus and on
> how this should work.
>
> Ryan
>


Re: [DISCUSS] Regression introduced in Full Dev

2017-04-25 Thread Casey Stella
Yeah, I tend to agree that a rundown of the various methods and when you
would use them is in order. I will say that full-dev is especially
important to have working since it is required for validating PRs.
On Tue, Apr 25, 2017 at 18:56 zeo...@gmail.com  wrote:

> Can somebody map out all of the current methods and procedures to spin up
> Metron components?  I swear I find out about new ones every month.
> Metron-docker, the 4 vagrants, rpm-docker, ansible-docker, any others?
> Perhaps an agreed upon write up of when to use what would be helpful.
>
> Jon
>
> On Tue, Apr 25, 2017, 6:17 PM Ryan Merriman  wrote:
>
> > A regression was introduced recently that breaks full dev.  I've narrowed
> > down the commit that introduced it and have submitted a PR to revert that
> > commit:  https://github.com/apache/incubator-metron/pull/549.
> >
> > Given there has been confusion recently over our deployment build
> process,
> > I think it's appropriate that we discuss and come to a consensus  and on
> > how this should work.
> >
> > Ryan
> >
> --
>
> Jon
>


[DISCUSS] Regression introduced in Full Dev

2017-04-25 Thread Ryan Merriman
A regression was introduced recently that breaks full dev.  I've narrowed
down the commit that introduced it and have submitted a PR to revert that
commit:  https://github.com/apache/incubator-metron/pull/549.

Given there has been confusion recently over our deployment build process,
I think it's appropriate that we discuss and come to a consensus  and on
how this should work.

Ryan