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
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
