Dima, if we want to deprecate UI logs in 10.0, it doesn't mean that we shouldn't fix issues in 9.0.
Thank you! Nastya. On Fri, Mar 25, 2016 at 3:31 PM, Dmitry Pyzhov <dpyz...@mirantis.com> wrote: > As we are going to deprecate logs on UI I'm going to mark following bugs > as "won't fix". Any objections? > High priority bug: > https://bugs.launchpad.net/fuel/+bug/1553170 > Medium priority: > https://bugs.launchpad.net/fuel/+bug/1554546 > https://bugs.launchpad.net/fuel/+bug/1539508 > > On Mon, Mar 14, 2016 at 3:02 PM, Roman Prykhodchenko <m...@romcheg.me> > wrote: > >> Folks, I’ve registered a blueprint [1] and created an etherpad document >> [2] where we can co-work on the spec before posting it to a formal review. >> Let’s cooperate to summarize what we need to do. >> >> >> 1. https://blueprints.launchpad.net/fuel/+spec/remove-logs-from-nailgun >> 2. https://etherpad.openstack.org/p/remove-logs-from_Nailgun >> >> - romcheg >> >> > 14 бер. 2016 р. о 09:53 Bogdan Dobrelya <bdobre...@mirantis.com> >> написав(ла): >> > >> > On 03/14/2016 09:38 AM, Anastasia Urlapova wrote: >> >> +1 to Vitaliy, it would be nice find somewhere a details for migration. >> >> And one more concern I should highlight - for some users logless UI may >> >> be challenging thing. >> >> The logs removing shouldn't affect the UX. >> > >> > Logs will still live at the master node's /var/log/remote >> > >> >> >> >> >> >> Nastya. >> >> >> >> >> >> On Sat, Mar 12, 2016 at 3:08 AM, Andrew Woodward <xar...@gmail.com >> >> <mailto:xar...@gmail.com>> wrote: >> >> >> >> I think we can address it by retaining deployment logs in >> >> nailgun/ui, this also removes the chicken and egg problem. after LMA >> >> is deployed it can be allowed to re-own 'logs' button on UI once >> >> it's deployed, including redirecting fuel logs there. >> >> >> >> On Fri, Mar 11, 2016 at 2:07 PM Mike Scherbakov >> >> <mscherba...@mirantis.com <mailto:mscherba...@mirantis.com>> wrote: >> >> >> >> We can sort out details later. In a worst case, the warning will >> >> be there in Newton too, and feature will go away only in O* >> >> release. So let's proceed with the bug.. >> >> >> >> On Fri, Mar 11, 2016 at 1:02 PM Vitaly Kramskikh >> >> <vkramsk...@mirantis.com <mailto:vkramsk...@mirantis.com>> >> wrote: >> >> >> >> We can add the warning, but I think before we do this we >> >> should have clear migration plan. According to this thread, >> >> some parts are still not clear. >> >> >> >> 2016-03-11 22:00 GMT+03:00 Mike Scherbakov >> >> <mscherba...@mirantis.com <mailto:mscherba...@mirantis.com >> >>: >> >> >> >> Deprecation warning for Fuel >> >> Mitaka: https://bugs.launchpad.net/fuel/+bug/1556244. >> >> >> >> >> >> On Fri, Mar 11, 2016 at 8:59 AM Roman Prykhodchenko >> >> <m...@romcheg.me <mailto:m...@romcheg.me>> wrote: >> >> >> >> 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 >> >>> <mailto: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>> wrote: >> >>>> >> >>>> >> >>>> On 11 March 2016 at 12:51:40, Igor Kalnitsky >> >>>> (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>> >> >>>>> wrote: >> >>>>>> >> >>>>>> On 11 March 2016 at 11:34:32, Igor Kalnitsky >> >>>>>> (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/ >> >>>>>> >> >>>>>> On Fri, Mar 11, 2016 at 11:53 AM, Patrick Petit >> >>>>>> <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>) >> >>>>>>> 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>> >> >>>>>>> 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 >> >>>>>>>> <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 >> >>>>>>>> >> >>>>>>> >> >>>>>>> >> __________________________________________________________________________ >> >>>>>>> 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 >> >>>>>>> >> >>>>>>> >> >>>>>>> >> __________________________________________________________________________ >> >>>>>>> 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 >> >>>>>>> >> >>>>>> >> >>>>>> >> __________________________________________________________________________ >> >>>>>> 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 >> >>>> >> __________________________________________________________________________ >> >>>> 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 >> >>>> >> >>>> -- >> >>>> 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 >> >>>> >> >>> >> >>> >> >>> -- >> >>> 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 >> >> >> __________________________________________________________________________ >> >> 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://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> >> >> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> >> >> >> >> >> >> >> -- >> >> Vitaly Kramskikh, >> >> Fuel UI Tech Lead, >> >> Mirantis, Inc. >> >> >> __________________________________________________________________________ >> >> 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://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> >> >> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> >> -- >> >> >> >> -- >> >> >> >> Andrew Woodward >> >> >> >> Mirantis >> >> >> >> Fuel Community Ambassador >> >> >> >> Ceph Community >> >> >> >> >> >> >> __________________________________________________________________________ >> >> 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://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 >> >> >> __________________________________________________________________________ >> 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
