1) Sorry I misspoke. I meant to say this is not possible in the Alerts UI
as far as I know. I put up a PR with a proposed solution here:
https://github.com/apache/metron/pull/1266.
2) Yes Knox is a service you can install with Ambari, similar to Ranger or
Spark. There are some things that are
Thanks Ryan,
1) Can you clarify "not a good way to do this?" Are you saying we don't
have a way to set this and need to add the config option, or that a
solution is not obvious and it's unclear what to do? It seems to me you're
saying the former, but I'd like to be sure.
2) Is Knox not a service
Ok, this is finally merged! Whew!
Here's how I polished up the history at the end. I used other feature
branch merges as a guideline around commit messaging.
* fcd644ca 2018-11-15 | METRON-1834: Migrate Elasticsearch from
TransportClient to new Java REST API (mmiklavc via mmiklavc) (HEAD ->
Absolutely, that's part of what I did to validate. This output below also
exactly matches the diff I get when I run it from the raw PR branch.
git diff master --stat
Upgrading.md
| 7 +++
dependencies_with_url.csv
Can you diff the trees to be sure?
On November 15, 2018 at 17:52:40, Michael Miklavcic (
michael.miklav...@gmail.com) wrote:
So amazingly, this still has results in conflicts, but I am able to resolve
them manually in a sensible fashion.
git merge -X theirs es-rebased
CONFLICT (rename/rename):
Wanted to give an update on the context path issue. I investigated
rewriting url links in the outgoing static assets with Knox and it was not
trivial. Fortunately I found a simple solution that works with or without
Knox. I changed the base tag in index.html from to , or in other words made
Totally agree Otto. The other concern here is that I believe the automated
release scripts need to see the Jira's on the commits. See my latest update
as I think I got something workable.
On Thu, Nov 15, 2018 at 3:30 PM Otto Fowler wrote:
> Proper attribution and the correct code are the most
Proper attribution and the correct code are the most important things, not
the number of commits.
On November 15, 2018 at 16:29:04, Justin Leet (justinjl...@gmail.com) wrote:
I took a look at this with Mike a bit, and it seems like it's pretty
painful and without a clear way to avoid remerging
I took a look at this with Mike a bit, and it seems like it's pretty
painful and without a clear way to avoid remerging conflicts. If the
latest attempt doesn't work, I'm in favor of getting it in and just getting
it down to as few commits as reasonably possible.
On Thu, Nov 15, 2018 at 4:12 PM
I'm attempting 1 more option, which would be to do a "git merge
--strategy-option theirs" after having done the commit wrangling in the PR
branch. Will reply back with results.
On Thu, Nov 15, 2018 at 2:02 PM Michael Miklavcic <
michael.miklav...@gmail.com> wrote:
> Yes, definitely.
>
> On Thu,
Yes, definitely.
On Thu, Nov 15, 2018 at 2:01 PM Casey Stella wrote:
> Can you at least rename your commits to have METRON-1834 prefixing them?
> On Thu, Nov 15, 2018 at 15:19 Michael Miklavcic <
> michael.miklav...@gmail.com>
> wrote:
>
> > https://github.com/apache/metron/pull/1242
> >
> >
Can you at least rename your commits to have METRON-1834 prefixing them?
On Thu, Nov 15, 2018 at 15:19 Michael Miklavcic
wrote:
> https://github.com/apache/metron/pull/1242
>
> TL;DR
> I'd like to discuss the best option to merge METRON-1834 into master. I
> want to propose handling this like a
https://github.com/apache/metron/pull/1242
TL;DR
I'd like to discuss the best option to merge METRON-1834 into master. I
want to propose handling this like a feature branch and merging it as-is.
---
I'm sure most folks' initial reaction will be some skepticism akin to "have
you tried turning it
Yes, makes sense. +1 to that.
On Thu, Nov 15, 2018 at 12:54 PM James Sirota wrote:
> To clarify my position, I don't have a problem with mySql or any other
> projects relying on it. mySql in itself is not an issue. What I don't
> want is for a customer to be presented with an option to chose
To clarify my position, I don't have a problem with mySql or any other projects
relying on it. mySql in itself is not an issue. What I don't want is for a
customer to be presented with an option to chose and configure two options for
authenticating the UI, which I think is needless. It adds
Just to clarify this point, I am not proposing we alter any interactions
with Ambari and backing stores. I want to make sure we cover all the
problems and provide good solutions where we're able. Again, just to
reiterate my earlier point, I agree with the move to deprecate SQL/JPA for
the UI. And
Incidentally, even without the Metron piece in the picture, what is the
answer for Ambari's database dependency? Which uses a SQL data store. Does
this actually solve the problem of "customers won't install Metron bc SQL
store?" or are there other issues we need to address?
On Thu, Nov 15, 2018
I’m certain that I can make the “adapter” for elastic too. and the adapter
compatible with HBase for those that want hbase (for other reasons). Sorry
that I was not clear about that.
SCott
Scott C. Cote
scottcc...@gmail.com
972.900.1561
twitter: @scottccote
> On Nov 13, 2018, at 5:51 PM,
This is excellent work, Mike and long overdue. Thanks for doing this
05.11.2018, 16:46, "Michael Miklavcic" :
> The PR has now been merged into master and closed.
>
> https://issues.apache.org/jira/browse/METRON-1855
>
> On Sat, Nov 3, 2018 at 6:47 PM Michael Miklavcic <
>
Hi Guys,
My opinion on this, as is with Knox SSO, is that the code should be pluggable
to support JDBC, but we should not continue to support the concrete
implementation and expose it to users via a setting. This is a fairly minor
feature and the added complexity of supporting switching
In my view Knox SSO is such a minor feature when it comes to Metron's
capabilities than it's not worth supporting multiple scenarios where it works
with Knox or without Knox. Where we should be configurable (and are
configurable) is on the analytics and stream processing. But this? As long
21 matches
Mail list logo
