Hi All,
Any feedback on the new look of the Metron site with the ASF links in the
bottom?
https://imgur.com/3Y8ZLWL
Thanks
Anand
On 2/16/18, 9:25 PM, "Michael Miklavcic" wrote:
That's awesome Anand, thanks for tackling this!
On Fri, Feb 16, 2018 at
If it meets the requirements, I am happy with it, Anand.
Thanks for taking care of this.
On Wed, Feb 21, 2018 at 5:49 AM, Anand Subramanian <
asubraman...@hortonworks.com> wrote:
> Hi All,
>
> Any feedback on the new look of the Metron site with the ASF links in the
> bottom?
>
Github user asfgit closed the pull request at:
https://github.com/apache/metron/pull/895
---
Github user merrimanr commented on the issue:
https://github.com/apache/metron/pull/895
+1 by inspection. Thanks @MohanDV!
---
Github user mmiklavc commented on the issue:
https://github.com/apache/metron/pull/933
Thanks for the info guys. @nickwallen With the reduced swap space, did you
notice any issues with performance or services dying? I'm +1 by inspection if
you believe we're good.
---
Hi Simon,
Thre are three reasons for why I thought a separate topology may help
(However, it was just an example).
1- Threat intel model flexibility: I thought there is no Stellar config
available for the threat-intel section, so we will end up using normal
Stellar enrichment to address threat
Github user nickwallen commented on the issue:
https://github.com/apache/metron/pull/933
I did not notice any issues, but I'll spin it up again and compare the
difference in swap space just so we know what we're getting into.
Thanks for the info @dlyle65535 !
---
Anyone have any opinions on how we should version the ES/Kibana MPack?
We currently rev the Metron one based on current Metron version and apply
it to both the overall MPack as well as the individual service versions,
e.g. metron_mpack-0.4.3.0/common-services/METRON/0.4.3. For ES we have been
+1 to the first approach, as you've laid it out. That makes the most sense
to me. We need a way to rev the version of the ES Mpack independent of the
ES version.
On Wed, Feb 21, 2018 at 11:30 AM, Michael Miklavcic <
michael.miklav...@gmail.com> wrote:
> Anyone have any opinions on how we
I agree, the first approach makes the most sense to me.
Jon
On Wed, Feb 21, 2018 at 11:45 AM Nick Allen wrote:
> +1 to the first approach, as you've laid it out. That makes the most sense
> to me. We need a way to rev the version of the ES Mpack independent of the
> ES
What are you trying to do?
I am not aware of any requirement for a Vagrant plugin called
'vagrant-aws'. The only Vagrant plugin that we require when deploying the
development environments is 'vagrant-hostmanager'.
On Tue, Feb 20, 2018 at 8:26 PM, Kevin Waterson
Github user mmiklavc commented on the issue:
https://github.com/apache/metron/pull/933
This looks good, but before I +1 this, what are we doing in the current
special metron cut of centos 6? I'm not familiar enough with why we forked to
understand what we're possibly giving up or
Hi Mike,
I agree. Def +1 on the first approach. Keep it with the Metron version.
-D...
On Wed, Feb 21, 2018 at 11:30 AM, Michael Miklavcic <
michael.miklav...@gmail.com> wrote:
> Anyone have any opinions on how we should version the ES/Kibana MPack?
>
> We currently rev the Metron one based
Github user nickwallen commented on the issue:
https://github.com/apache/metron/pull/933
> what are we doing in the current special metron cut of centos 6? I'm not
familiar enough with why we forked to understand what we're possibly giving up
or exchanging by switching to the main
Github user dlyle65535 commented on the issue:
https://github.com/apache/metron/pull/933
@mmiklavc - the special cut has a larger swap volume than the standard
image. It also is customized to what Metron required at the time to run. That's
pretty much it. If that's still desirable,
15 matches
Mail list logo