Looks like my replies were only going to Otto, sorry about that- I'll gather them here:
"What does this do for Monit?" Monit would be deprecated for components under Ambari management. "How would this effect deploying new parsers or parsers not shipped? When I prototyped this I added a monit entry." Hard to say having not seen Otto's prototype, but I suspect no effect. Fwiw, there is a jira about sideloading that is meant for deploying custom parsers. Last I looked, the management was still up for design. I"ve opened https://issues.apache.org/jira/browse/METRON-667 to track this work. I'd like to get started. Thoughts? -D... On Wed, Jan 18, 2017 at 1:28 PM, David Lyle <[email protected]> wrote: > Hard to say having not seen your prototype, but I suspect no effect. > > Fwiw, there is a jira about sideloading that is meant for deploying custom > parsers. Last I looked, the management was still up for design. > > -D... > > On Wed, Jan 18, 2017 at 13:07 Otto Fowler <[email protected]> wrote: > >> How would this effect deploying new parsers or parsers not shipped? >> When I prototyped this I added a monit entry. >> >> >> On January 17, 2017 at 10:34:32, David Lyle ([email protected]) wrote: >> >> In our "Dev Guide and Committer Review Guide additions" discussion, we had >> >> >> a bit of a side discussion about reducing reliance (perhaps to zero) on >> >> >> Ansible for our installation. >> >> >> >> >> >> It seemed there was consensus around that idea (if not, please let me >> >> >> know), so I propose the following steps to get there: >> >> >> >> >> >> 1) Refactor existing Ansible deployment to use the Ambari MPack to install >> >> >> metron-common, metron-enrichments and metron-parsers. >> >> >> 2) Regenerate quick-dev to leverage the change. >> >> >> 3) Create rpm packages for all deployed components that don't currently >> >> >> have them. >> >> >> - Sensor probes >> >> >> - Sensor stubs >> >> >> 4) Create MPack service defs for the RPMs in (2). >> >> >> 5) Refactor existing Ansible deployment to use the Ambari MPack to install >> >> >> all services. >> >> >> 6) Regenerate quick-dev to leverage the change. >> >> >> 7) Plan iteration 2 to see if there are other opportunities to reduce our >> >> >> use of Ansible. >> >> >> >> >> >> One note: if we decide to go this direction, it'd be helpful if, during >> the >> >> >> transition, we stopped adding additional Ansible deployment code. >> >> >> >> >> >> Thoughts? >> >> >> >> >> >> Thanks, >> >> >> >> >> >> -David... >> >> >>
