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> 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>: > >> 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> >> 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> >>> написав(ла): >>> >>> >>> 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 <ppe...@mirantis.com>>> wrote: >>> >>> >>> On 11 March 2016 at 12:51:40, Igor Kalnitsky >>> (ikalnit...@mirantis.com <mailto:ikalnit...@mirantis.com >>> <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 >>> <ppe...@mirantis.com>>> wrote: >>> >>> >>> On 11 March 2016 at 11:34:32, Igor Kalnitsky (ikalnit...@mirantis.com < >>> mailto:ikalnit...@mirantis.com <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 <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 <spasqu...@mirantis.com>>) >>> wrote: >>> >>> Hello Roman, >>> >>> On Fri, Mar 11, 2016 at 9:57 AM, Roman Prykhodchenko <m...@romcheg.me < >>> mailto:m...@romcheg.me <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 >>> >>> >>> >>> __________________________________________________________________________ >>> >>> 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 >>> >>> >>> >>> __________________________________________________________________________ >>> >>> 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 >>> >>> >>> >>> __________________________________________________________________________ >>> >>> 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 >>> >>> >>> >>> __________________________________________________________________________ >>> 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 >>> >>> -- >>> 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 >>> >>> >>> __________________________________________________________________________ >>> 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 >>> >> -- >> 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 >> >> > > > -- > 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://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
