Re: Architectural reason to split in 4 topologies / impact on the kafka ressources

Hey Michel, Those are good questions and there were some reasons surrounding that. In fact, historically, we had fewer topologies (e.g. indexing and enrichment were merged). Even earlier on, we had just one giant topology per parser that enriched and indexed. The long story short is that we move

Architectural reason to split in 4 topologies / impact on the kafka ressources

Hi Everyone, I was asking myself what was the architectural reason to split the ingestion in metron in 4 differents toppologies that all read/write to kafka? For example, why the parsing and enrichment topologies have not been merged? Would it not be possible when you parse the message to directl

Re: [DISCUSS] Merging Solr feature branch (METRON-1416) into master

That's more or less why I didn't flesh out testing. Might be worth spinning up full dev and the site-book to smoke test, but the branch should be in a good state. I figured if we get a couple +1's on the PR, it's essentially voting anyway, but this is pretty new in terms of process. On Fri, Ju

Re: [DISCUSS] Merging Solr feature branch (METRON-1416) into master

If all the PR’s are on master->feature branch. Why do we need testing? this is almost a vote situation. On June 22, 2018 at 12:01:11, Justin Leet (justinjl...@gmail.com) wrote: The (formerly) active PRs are now merged in and closed. We don't seem to have defined way to merge a feature branch

Re: [DISCUSS] Merging Solr feature branch (METRON-1416) into master

The (formerly) active PRs are now merged in and closed. We don't seem to have defined way to merge a feature branch into master (unless I missed it), so I went ahead and opened a PR against the parent ticket. Please see #1076 . I haven't fleshed out tes