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> 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> > 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 > -- -- 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://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
