Github user ottobackwards commented on the issue:
https://github.com/apache/metron/pull/858
Re-upping what I said before
---
Github user ottobackwards commented on the issue:
https://github.com/apache/metron/pull/858
@merrimanr I am +1 on getting this down to the feature branch and moving on.
Due to the way the feature branch works, I think it is OK to do so if
@cestella doesn't get back in time. It's
Github user merrimanr commented on the issue:
https://github.com/apache/metron/pull/858
@cestella are you good with merging this in to the feature branch? I
believe I addressed your comments.
---
Github user ottobackwards commented on the issue:
https://github.com/apache/metron/pull/858
@merrimanr, I have created labels in jira that are applicable to feature
branch Jiras,
This will allow for tracking these jiras in confluence as I have done here
:
Github user cestella commented on the issue:
https://github.com/apache/metron/pull/858
I'd actually recommend not using METRON-1344 as the base JIRA. I'd
recommend creating a new JIRA where the requirements for the end-state are laid
out in the description. I'd call this one a PoC
Github user merrimanr commented on the issue:
https://github.com/apache/metron/pull/858
I agree with everything that has been said. I will address the minor
changes @cestella suggested and start the discussion thread. Will METRON-1344
work as the base Jira for the feature branch?
Github user justinleet commented on the issue:
https://github.com/apache/metron/pull/858
@merrimanr Is it worth having a new discuss thread where you lay out what
you've done, where you expect this to end, and what (if any) work that would be
nice to have but isn't essential for this
Github user cestella commented on the issue:
https://github.com/apache/metron/pull/858
Yep, I think a JIRA for the feature branch and each PR as a subtask is a
good idea.
---
Github user ottobackwards commented on the issue:
https://github.com/apache/metron/pull/858
Similar to https://issues.apache.org/jira/browse/METRON-876
---
Github user ottobackwards commented on the issue:
https://github.com/apache/metron/pull/858
Maybe a Jira for the feature branch, and each PR as a subtask?
---
Github user justinleet commented on the issue:
https://github.com/apache/metron/pull/858
I think getting the feature branch set up was a great first step, so thanks
for setting that up, @merrimanr.
I agree with @ottobackwards, that we need a discussion on what the next
steps
Github user ottobackwards commented on the issue:
https://github.com/apache/metron/pull/858
I would be for +1 and landing this pr on the feature branch, then we can
discuss next steps, proposals and start new pr's against FB
---
Github user merrimanr commented on the issue:
https://github.com/apache/metron/pull/858
I created a feature branch called "feature/METRON-1344-test-infrastructure"
and switched the base of this PR to that instead of master. What is the next
step?
---
Github user cestella commented on the issue:
https://github.com/apache/metron/pull/858
This smells like it might be a bigger effort than one PR, I think I'd
rather have smaller PRs on a feature branch so each is easier to review. I
would expec that we will want to try it out and
Github user merrimanr commented on the issue:
https://github.com/apache/metron/pull/858
As long as breakpoints are limited to code we maintain in Metron, I think
it's just a matter of documenting how to set it up. For example, I run REST
locally in Intellij and debugging works fine
Github user cestella commented on the issue:
https://github.com/apache/metron/pull/858
If we think that remote debugging would cause this to balloon, should we
consider making this a feature branch so multiple PRs with iterative solutions
can exist and be reviewed separately? Just a
Github user cestella commented on the issue:
https://github.com/apache/metron/pull/858
We would want to remote debug any code that we maintain in Metron, so any
services which run metron code would need to have remote debugging (e.g. storm,
the REST app). Ironically, this is one of
Github user merrimanr commented on the issue:
https://github.com/apache/metron/pull/858
Point taken on maintaining 2 different solutions. Which services would
people want to enable remote debugging on? I've only ever debugged Metron code
so I don't know which services are important
Github user ottobackwards commented on the issue:
https://github.com/apache/metron/pull/858
@merrimanr would you imagine someone just leaving this running all the
time? or starting on demand per use?
---
Github user ottobackwards commented on the issue:
https://github.com/apache/metron/pull/858
OK,
After getting the new changes, everything works as advertised. I was able
to run on mac os , and the end to end passed. I ran a few times in a row and
there where no issues, so it
Github user justinleet commented on the issue:
https://github.com/apache/metron/pull/858
I agree with @cestella (and this might spill over into a discuss thread as
@ottobackwards mentioned). Maintaining both anything over other than short,
short term is going to be a nightmare.
Github user merrimanr commented on the issue:
https://github.com/apache/metron/pull/858
@ottobackwards I don't see anything obviously wrong. Maybe you could try
pulling the latest commits or copying the one here:
Github user merrimanr commented on the issue:
https://github.com/apache/metron/pull/858
Docker Compose provides a CLI just like vagrant does:
https://docs.docker.com/compose/reference/overview/. I would be happy to wrap
those commands in easy to understand scripts.
---
Github user cestella commented on the issue:
https://github.com/apache/metron/pull/858
Regarding remote debugging, it seems that having both in memory components
AND docker is the worst of all worlds here. I would prefer to not live in a
world where we can't simplify this to one
Github user ottobackwards commented on the issue:
https://github.com/apache/metron/pull/858
We will, if this pr goes through need to have a 'writing new integration
tests' readme about namespacing etc..
---
Github user ottobackwards commented on the issue:
https://github.com/apache/metron/pull/858
No matter what approach we take, my point is that we need to have some
thing that says you need to run docker to debug the tests. Beyond that, we
don't have to over back this. I think the
Github user merrimanr commented on the issue:
https://github.com/apache/metron/pull/858
I would love to have a Debugging readme that is even more comprehensive
than just integration tests. Being able to easily debug is important to me and
I do it all the time.
I had to do
Github user ottobackwards commented on the issue:
https://github.com/apache/metron/pull/858
```bash
metron-alerts configure table
â should select columns from table configuration
- Error: connect ECONNREFUSED 127.0.0.1:9210
- Error: socket hang up
Github user ottobackwards commented on the issue:
https://github.com/apache/metron/pull/858
Ok, I'm going to try running through some things.
One point, and I will admit this just may be me:
I see the same problem with this as I had with the original docker stuff.
The
Github user ottobackwards commented on the issue:
https://github.com/apache/metron/pull/858
I was more thinking about having to have a "Debugging Integration Tests"
readme.
I think having the in-memory stuff available is worth getting some feedback.
I have in the past
Github user merrimanr commented on the issue:
https://github.com/apache/metron/pull/858
Doesn't necessarily have to be Docker but yes you would have to start
something up. That step is now outside of the integration tests.
We could keep the current in memory code and offer
Github user ottobackwards commented on the issue:
https://github.com/apache/metron/pull/858
So, debugging the integration tests will require having docker running in
the background now?
---
Github user merrimanr commented on the issue:
https://github.com/apache/metron/pull/858
@ottobackwards I also added a way to run the e2e tests locally. Once your
Docker app is up and running locally, get the $DOCKER_HOST ip address and
replace "localhost" with that ip address in
Github user merrimanr commented on the issue:
https://github.com/apache/metron/pull/858
@justinleet latest commit includes the changes I had to make to switch a
preexisting integration test to the new infrastructure. I verified it works
locally, we'll see how it goes with Travis.
Github user merrimanr commented on the issue:
https://github.com/apache/metron/pull/858
Sure a discussion on that topic is fine with me. I'm referring to the
existing integration tests.
---
Github user ottobackwards commented on the issue:
https://github.com/apache/metron/pull/858
Any chance we can have a discuss on moving other integration tests over?
You mean the regular tests right, like profiler etc?
---
Github user merrimanr commented on the issue:
https://github.com/apache/metron/pull/858
@justinleet I think that is a great idea. I didn't do it initially to keep
the size of this PR modest but I can add it in (we can always roll it back and
move it to another PR if we want). I'll
Github user merrimanr commented on the issue:
https://github.com/apache/metron/pull/858
Sorry @ottobackwards, you're right the instructions are a little vague.
First, `metron-contrib/metron-docker-e2e/compose` is the directory you should
be in. I should have added that at the
Github user ottobackwards commented on the issue:
https://github.com/apache/metron/pull/858
@merrimanr can you add what directory you should be in when you run the
commands?
---
Github user justinleet commented on the issue:
https://github.com/apache/metron/pull/858
@merrimanr Did you look into what migrating our non-e2e tests integration
tests would involve? I think for a POC, it's important to get a sense of how
we'd be able to unify the infrastructure of
Github user ottobackwards commented on the issue:
https://github.com/apache/metron/pull/858
Wow, this is awesome. I'm looking forward to getting into it. First thing
that pops to mind is how this relates to or is effected by @nickwallen's
https://github.com/apache/metron/pull/854
41 matches
Mail list logo
