Github user mmiklavc commented on a diff in the pull request:
https://github.com/apache/metron/pull/909#discussion_r163737895
--- Diff:
metron-platform/metron-indexing/src/test/java/org/apache/metron/indexing/dao/SearchIntegrationTest.java
---
@@ -724,6 +503,52 @@ public void
Github user mmiklavc commented on a diff in the pull request:
https://github.com/apache/metron/pull/909#discussion_r163737939
--- Diff:
metron-platform/metron-indexing/src/test/java/org/apache/metron/indexing/dao/SearchIntegrationTest.java
---
@@ -724,6 +503,52 @@ public void
One other benefit of this revised approach - we can more effectively use
index template patterns to specify our base set of Metron property types.
Call me crazy, but I think we should be able to do something like:
{
*"template": "metron_*",*
"mappings": {
"metron_doc": {
I hear you Ali. I think this type of change would actually ease issues with
downtime because it offers an easy path to migrating existing indices. I'd
have to review the specifics in the ES docs again, but I believe you could
duplicate the old indexes and migrate them to "metron_" in advance of
Github user mmiklavc commented on the issue:
https://github.com/apache/metron/pull/907
@Ali - I think the reason for Storm 1.1 is that it's the version that comes
with HDP 2.6.
https://docs.hortonworks.com/HDPDocuments/HDP2/HDP-2.6.4/bk_release-notes/content/comp_versions.html
Github user ottobackwards commented on the issue:
https://github.com/apache/metron/pull/902
I can almost always be bought off with a jira number
---
Github user nickwallen commented on the issue:
https://github.com/apache/metron/pull/902
> @ottobackwards: I think of there being two users for these scripts...
That makes perfect sense to me. Can we tackle that in a follow-on?
---
Github user mraliagha commented on the issue:
https://github.com/apache/metron/pull/907
@cestella Would it be possible to target Storm 1.2 (which was released 2
days ago) as well?
---
Hi All,
I just wanted to say it would be great if we can be careful with these type
of changes. From the development point of view, it is just a few lines of
code which can provide multiple advantages, but for live large-scale Metron
platforms, some of these changes might be really expensive to
GitHub user merrimanr opened a pull request:
https://github.com/apache/metron/pull/909
METRON-1429: SearchIntegrationTest refactor
## Contributor Comments
This PR cleans up SearchIntegrationTest which will make it easier to create
a Solr implementation. Changes include:
Github user asfgit closed the pull request at:
https://github.com/apache/metron/pull/905
---
Github user mmiklavc commented on the issue:
https://github.com/apache/metron/pull/905
Thanks @nickwallen, I plan to spend some time reviewing 903 as well.
---
Github user asfgit closed the pull request at:
https://github.com/apache/metron/pull/904
---
+1
On January 24, 2018 at 16:28:42, Nick Allen (n...@nickallen.org) wrote:
+1 to a standard prefix for all Metron indices. I've had the same thought
myself and you laid out the advantages well.
On Wed, Jan 24, 2018 at 3:47 PM zeo...@gmail.com wrote:
> I agree with
There isn’t a maven plugin for this?
On January 24, 2018 at 16:44:02, Nick Allen (n...@nickallen.org) wrote:
We should re-jigger `platform-info.sh` (or create a new tool) that very
obviously passes or fails based on what it discovers in the user's
environment. Right now, a user just runs the
Github user nickwallen commented on the issue:
https://github.com/apache/metron/pull/905
I should also say, #903 certainly doesn't preclude this. This has a +1
from me.
---
Github user nickwallen commented on the issue:
https://github.com/apache/metron/pull/905
I one-up'd you in #903 by just removing Monit all-together. There is
really no need for it any longer. It was useful before the MPack; now not so
much.
---
A big +1 to this. Good suggestion.
On Jan 24, 2018 2:44 PM, "Nick Allen" wrote:
> We should re-jigger `platform-info.sh` (or create a new tool) that very
> obviously passes or fails based on what it discovers in the user's
> environment. Right now, a user just runs the
We should re-jigger `platform-info.sh` (or create a new tool) that very
obviously passes or fails based on what it discovers in the user's
environment. Right now, a user just runs the `platform-info.sh` and it is
not apparent to them what the problem is.
The script could be manually executed by
+1 to a standard prefix for all Metron indices. I've had the same thought
myself and you laid out the advantages well.
On Wed, Jan 24, 2018 at 3:47 PM zeo...@gmail.com wrote:
> I agree with having a metron_ prefix for ES indexes, and the timing.
>
> Jon
>
> On Wed, Jan
I agree with having a metron_ prefix for ES indexes, and the timing.
Jon
On Wed, Jan 24, 2018 at 3:20 PM Michael Miklavcic <
michael.miklav...@gmail.com> wrote:
> With the completion of https://github.com/apache/metron/pull/840
> (METRON-939: Upgrade ElasticSearch and Kibana), we have the
With the completion of https://github.com/apache/metron/pull/840
(METRON-939: Upgrade ElasticSearch and Kibana), we have the makings for a
major release rev of Metron in the upcoming release (currently slotted to
0.4.3, I believe). Since there are non-backwards compatible changes
pertaining to ES
Github user asfgit closed the pull request at:
https://github.com/apache/metron/pull/908
---
Github user mmiklavc commented on the issue:
https://github.com/apache/metron/pull/908
Realized the change I made is specifically for a test dependency and does
not appear to affect final package dependencies from what I can see in the tgz
- `tar tvf
Fix worked on my fork's Travis build -
https://travis-ci.org/mmiklavc/metron/builds/332889008?utm_source=email_medium=notification.
Just waiting on the mainline build to run and we should be good to go.
On Wed, Jan 24, 2018 at 10:36 AM, Michael Miklavcic <
michael.miklav...@gmail.com> wrote:
>
Github user cestella commented on the issue:
https://github.com/apache/metron/pull/908
+1 lgtm
---
Github user ottobackwards commented on the issue:
https://github.com/apache/metron/pull/888
+1 by inspection
---
Fix is out for the UI build error. Please try it out/review -
https://github.com/apache/metron/pull/908
Between these 2 PR's, this should resolve our current build problems. I'm
looking at what I have to do for metron-config licensing updates right now.
1.
GitHub user mmiklavc opened a pull request:
https://github.com/apache/metron/pull/908
1428: Travis build failing from metron-config
## Contributor Comments
https://issues.apache.org/jira/browse/METRON-1428
Travis is failing because of npm downstream package
Github user ottobackwards commented on a diff in the pull request:
https://github.com/apache/metron/pull/901#discussion_r163616902
--- Diff:
metron-deployment/packaging/ambari/metron-mpack/src/main/resources/common-services/METRON/CURRENT/package/scripts/enrichment_commands.py
---
Github user cestella commented on a diff in the pull request:
https://github.com/apache/metron/pull/901#discussion_r163607202
--- Diff:
metron-deployment/packaging/ambari/metron-mpack/src/main/resources/common-services/METRON/CURRENT/package/scripts/enrichment_commands.py
---
@@
Github user cestella commented on a diff in the pull request:
https://github.com/apache/metron/pull/907#discussion_r163606292
--- Diff: metron-deployment/roles/ambari_config/vars/single_node_vm.yml ---
@@ -87,6 +87,11 @@ configurations:
supervisor.slots.ports: "[6700,
Github user cestella commented on a diff in the pull request:
https://github.com/apache/metron/pull/907#discussion_r163602345
--- Diff:
metron-deployment/packaging/ambari/metron-mpack/src/main/resources/common-services/ELASTICSEARCH/5.6.2/package/scripts/service_check.py
---
@@
Github user anandsubbu commented on a diff in the pull request:
https://github.com/apache/metron/pull/907#discussion_r163600738
--- Diff:
metron-deployment/packaging/ambari/metron-mpack/src/main/resources/common-services/ELASTICSEARCH/5.6.2/package/scripts/service_check.py
---
@@
Github user justinleet commented on a diff in the pull request:
https://github.com/apache/metron/pull/907#discussion_r163600063
--- Diff: metron-deployment/roles/ambari_config/vars/single_node_vm.yml ---
@@ -87,6 +87,11 @@ configurations:
supervisor.slots.ports: "[6700,
Working with Ryan Merriman on fixes for the build. There are 2 issues
currently. I have a PR out for one of them, which is an intermittent test
failure around the search config test -
https://github.com/apache/metron/pull/906. The other appears to be us
getting bitten once again by npm packages
GitHub user cestella opened a pull request:
https://github.com/apache/metron/pull/907
METRON-1427: Add support for storm 1.1 and hdp 2.6
## Contributor Comments
Right now our ambari mpack won't run cleanly on HDP 2.6 and Storm 1.1
because of some classpath issues and not
GitHub user mmiklavc opened a pull request:
https://github.com/apache/metron/pull/906
1426: SensorIndexingConfigControllerIntegrationTest fails intermittently
## Contributor Comments
https://issues.apache.org/jira/browse/METRON-1426
Sensor indexing config has a
Github user nickwallen commented on the issue:
https://github.com/apache/metron/pull/888
+1 by inspection. Nice work @anandsubbu .
We'll need to figure out this intermittent test failure (impacting all PRs,
not just yours) before we merge.
---
Github user anandsubbu commented on the issue:
https://github.com/apache/metron/pull/888
@ottobackwards @cestella and @nickwallen - any other feedback on this PR?
The travis failures seems to be in an unrelated piece of code.
---
Github user anandsubbu commented on the issue:
https://github.com/apache/metron/pull/904
+1 works fine @mmiklavc .
Verified on CentOS 7 multinode cluster. Simulated the problem first and
then ran with the fix.
Here is a sample output with the fix in place.
41 matches
Mail list logo