On 03/11/2016 04:46 PM, Mike Scherbakov wrote: > +1 to remove logs from Fuel UI in Fuel Newton. > In Fuel Mitaka we'd need to put a deprecation warning somewhere.
I agree, there is not much sense having non flexible (no content filters) logs view in UI. LMA plugins shall cover this area as well. > > > On Fri, Mar 11, 2016, 04:57 Patrick Petit <ppe...@mirantis.com > <mailto:ppe...@mirantis.com>> wrote: > > > On 11 March 2016 at 12:51:40, Igor Kalnitsky > (ikalnit...@mirantis.com <mailto:ikalnit...@mirantis.com>) wrote: > >> 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. > > Right. This is the chicken and egg problem I mentioned earlier... > > But this is not a “problem” specific to Fuel. My take on this is is > that ops management tooling (logging, monitoring) should be > installed off-band before any OpenStack deployment. In fact, in > real-world usage, we frequently get asks to have the monitoring and > logging services of StackLight installed permanently for > multi-enviroments. And so, one approach would be to make Stacklight > backend services the first bits of software installed by Fuel (if > not already there), then reconfigure Fuel to hook into those > services and only then, enter into the regular OpenStack > provisioning mode. > >> >> >> On Fri, Mar 11, 2016 at 12:52 PM, Patrick Petit >> <ppe...@mirantis.com <mailto:ppe...@mirantis.com>> wrote: >> > >> > On 11 March 2016 at 11:34:32, Igor Kalnitsky (ikalnit...@mirantis.com >> <mailto: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 >> <mailto: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 >> <mailto:spasqu...@mirantis.com>) >> >> wrote: >> >> >> >> Hello Roman, >> >> >> >> On Fri, Mar 11, 2016 at 9:57 AM, Roman Prykhodchenko <m...@romcheg.me >> <mailto: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://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://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://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://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://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- > Mike Scherbakov > #mihgen > > > __________________________________________________________________________ > 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 > -- Best regards, Bogdan Dobrelya, Irc #bogdando __________________________________________________________________________ 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
