Patrick, Sorry, but I meant another question. I thought that LMA plugin should be installed in some environment before we can start use it. Is this a case? If so, it means we can't use for master node until some environment is deployed.
On Fri, Mar 11, 2016 at 12:52 PM, Patrick Petit <ppe...@mirantis.com> wrote: > > On 11 March 2016 at 11:34:32, Igor Kalnitsky (ikalnit...@mirantis.com) > wrote: > > Hey Roman, > > Thank you for bringing this up. +1 from my side, especially taking > into account the patch where we tried to solve logrotated logs problem > [1]. It's complex and unsupportable, as well as already existed > logview code in Nailgun. > > Patrick, Simon, > > Does LMA plugin support logs from master node? Or it's designed to > watch environment's logs? > > No it’s not designed specifically for environment logs. Can be adapted to > any log format. > > Would just need to write a parser like you would with logstach when logs are > not standard. > > Patrick > > > > Thanks, > Igor > > > [1]: https://review.openstack.org/#/c/243240/ > > On Fri, Mar 11, 2016 at 11:53 AM, Patrick Petit <ppe...@mirantis.com> wrote: >> Fuelers, >> >> As Simon said, we already have a log centralisation solution for MOS >> delivered as a Fuel plugins known as StackLight / LMA toolset. And so >> objectively, there is no need to have log management in Nailgun anymore. >> To >> go one step further we suggested several times to have a StackLight agent >> installed on the Fuel master node to also collect and centralise those >> logs. >> There is a little bit of a chicken and egg problem to resolve but I think >> it >> is worth a try to have that nailed down in the roadmap for Fuel 10. >> Cheers >> - Patrick >> >> >> On 11 March 2016 at 10:07:28, Simon Pasquier (spasqu...@mirantis.com) >> wrote: >> >> Hello Roman, >> >> On Fri, Mar 11, 2016 at 9:57 AM, Roman Prykhodchenko <m...@romcheg.me> >> wrote: >>> >>> Fuelers, >>> >>> I remember we’ve discussing this topic in our couloirs before but I’d >>> like >>> to bring that discussion to a more official format. >>> >>> Let me state a few reasons to do this: >>> >>> - Log management code in Nailgun is overcomplicated >>> - Working with logs on big scale deployments is barely possible given the >>> current representation >>> - Due to overcomplexity and ineffectiveness of the code we always get >>> recurring bugs like [1]. That eats tons of time to resolve. >>> - There are much better specialized tools, say Logstash [2], that can >>> deal >>> with logs much more effectively. >>> >>> >>> There may be more reasons bus I think even the already mentioned ones are >>> enough to think about the following proposal: >>> >>> - Remove Logs tab from Fuel Web UI >>> - Remove logs support from Nailgun >>> - Create mechanism that allows to configure different log management >>> software, say Logstash, Loggly, etc >>> >>> - Choose a default software to install and provide a plugin for it from >>> the box >> >> >> This is what the LMA/StackLight plugins [1][2] are meant for. No need to >> develop anything new. >> >> And I'm +1 with the removal of log management from Fuel. As you said, it >> can't scale... >> >> [1] http://fuel-plugin-lma-collector.readthedocs.org/en/latest/ >> [2] http://fuel-plugin-elasticsearch-kibana.readthedocs.org/en/latest/ >> >> >>> >>> >>> >>> References >>> 1. https://bugs.launchpad.net/fuel/+bug/1553170 >>> 2. https://www.elastic.co/products/logstash >>> >>> >>> - romcheg >>> >>> >>> __________________________________________________________________________ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: >>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
