Since there are a lot of supporters for this idea, what do you folks think about creating a BP spec where we can describe what we should do in order to remove logs from UI and Nailgun? I also propose to file a bug about adding a deprecation warning to Mitaka release of Fuel.
> 11 бер. 2016 р. о 16:55 Bogdan Dobrelya <bdobre...@mirantis.com> написав(ла): > > 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> >> <mailto: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> >> <mailto: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> >>> <mailto: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> <mailto: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/ >>>> <https://review.openstack.org/#/c/243240/> >>>> >>>> On Fri, Mar 11, 2016 at 11:53 AM, Patrick Petit <ppe...@mirantis.com >>>> <mailto:ppe...@mirantis.com> <mailto: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> <mailto: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> <mailto: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://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe>> >>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>>> <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 >>>>> <mailto:openstack-dev-requ...@lists.openstack.org>?subject:unsubscribe >>> <http://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 >>>>> <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 >>>>> <mailto:openstack-dev-requ...@lists.openstack.org>?subject:unsubscribe >>> <http://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 >>>>> <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 >>>> <mailto:openstack-dev-requ...@lists.openstack.org>?subject:unsubscribe >>> <http://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 >>>> <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 >> <mailto:openstack-dev-requ...@lists.openstack.org>?subject:unsubscribe >> <http://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 >> <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 >> <mailto:openstack-dev-requ...@lists.openstack.org>?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> <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 > <mailto:openstack-dev-requ...@lists.openstack.org>?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
signature.asc
Description: Message signed with OpenPGP using GPGMail
__________________________________________________________________________ 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
