The configs in zookeeper should be exactly the same.  If you have command
line args to start_parser_topology.sh that adjust # of workers, parallelism
hint, etc. for individual bolts, those would need to translate into changes
to the flux configs.  This would make the parsers consistent with the
enrichment and indexing topology (modify storm topology configs in flux,
modify metron configs in the zookeeper held JSON).

On Mon, Sep 26, 2016 at 1:36 PM, Rider, Jonathan <
[email protected]> wrote:

> Will this be functionally different than feeding the parser json files to
> the ParserTopologyBuilder class like it is done currently?
> Additionally, will it require us to change all of the configs that we
> currently have, or will they continue to work with the proposed move to
> flux?
>
> Jon
>
>
> On 9/26/16, 1:26 PM, "Casey Stella" <[email protected]> wrote:
>
>     Sure, so there would be one flux file defining the topology that all
> the
>     parsers use.
>     Each parser topology has a:
>
>        - Kafka Spout
>        - Parser bolt
>        - Error Writer Bolt
>        - Invalid Message Writer Bolt
>
>     The actual parser that you are using and the writer that you write out
> to
>     from the parser bolt is parameterized inside of the zookeeper config
> for
>     that parser.  Since the actual parser implementation and writer to use
> are
>     already parameterized inside of the config, we should be able to get
> away
>     with one flux file and a property that indicates the name of the
> config in
>     zookeeper.
>
>     Casey
>
>
>     On Mon, Sep 26, 2016 at 1:19 PM, Otto Fowler <[email protected]>
>     wrote:
>
>     > Casey, can you explain the one flux file with separate
> configurations a
>     > little more?
>     >
>     > On September 26, 2016 at 12:22:45, Casey Stella ([email protected])
>     > wrote:
>     >
>     > We moved the parser topologies away from Flux early on, mostly
> because the
>     > way it was working originally would require separate flux files per
>     > topology. I think that we are, with the current architecture, would
> be
>     > able to use one flux file for all of the topology (different params,
>     > obviously). Flux is quite configurable and if we could use one flux
> file
>     > and just have separate configs per parser topology, then I think we
> might
>     > get the best of both worlds.
>     >
>     > What do you guys think?
>     >
>     >
>
>
>
> ________________________________________________________
>
> The information contained in this e-mail is confidential and/or
> proprietary to Capital One and/or its affiliates and may only be used
> solely in performance of work or services for Capital One. The information
> transmitted herewith is intended only for use by the individual or entity
> to which it is addressed. If the reader of this message is not the intended
> recipient, you are hereby notified that any review, retransmission,
> dissemination, distribution, copying or other use of, or taking of any
> action in reliance upon this information is strictly prohibited. If you
> have received this communication in error, please contact the sender and
> delete the material from your computer.
>

Reply via email to