[openstack-dev] [Fuel] Removing logs from Fuel Web UI and Nailgun
Dmitry Pyzhov
dpyzhov at mirantis.com
Fri Mar 25 12:31:10 UTC 2016
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 <me at 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 <bdobrelia at 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 <xarses at gmail.com
> >> <mailto:xarses at 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
> >> <mscherbakov at mirantis.com <mailto:mscherbakov at 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
> >> <vkramskikh at mirantis.com <mailto:vkramskikh at 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
> >> <mscherbakov at mirantis.com <mailto:mscherbakov at 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
> >> <me at romcheg.me <mailto:me at 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
> >>> <bdobrelia at mirantis.com
> >>> <mailto:bdobrelia at 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
> >>>> <ppetit at mirantis.com <mailto:ppetit at mirantis.com>
> >>>> <mailto:ppetit at mirantis.com>> wrote:
> >>>>
> >>>>
> >>>> On 11 March 2016 at 12:51:40, Igor Kalnitsky
> >>>> (ikalnitsky at mirantis.com
> >>>> <mailto:ikalnitsky at mirantis.com> <mailto:
> ikalnitsky at 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
> >>>>> <ppetit at mirantis.com
> >>>>> <mailto:ppetit at mirantis.com> <mailto:
> ppetit at mirantis.com>>
> >>>>> wrote:
> >>>>>>
> >>>>>> On 11 March 2016 at 11:34:32, Igor Kalnitsky
> >>>>>> (ikalnitsky at mirantis.com
> >>>>>> <mailto:ikalnitsky at mirantis.com> <mailto:
> ikalnitsky at 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
> >>>>>> <ppetit at mirantis.com
> >>>>>> <mailto:ppetit at mirantis.com> <mailto:
> ppetit at 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
> >>>>>>> (spasquier at mirantis.com
> >>>>>>> <mailto:spasquier at mirantis.com> <mailto:
> spasquier at mirantis.com>)
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>> Hello Roman,
> >>>>>>>
> >>>>>>> On Fri, Mar 11, 2016 at 9:57 AM, Roman
> >>>>>>> Prykhodchenko <me at romcheg.me
> >>>>>>> <mailto:me at romcheg.me> <mailto:me at 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-request at lists.openstack.org
> >>>>>>>> <mailto:
> OpenStack-dev-request at lists.openstack.org>?subject:unsubscribe
> >>>>> <
> http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
> >>>>> <
> http://OpenStack-dev-request@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-request at lists.openstack.org
> >>>>>>> <mailto:
> OpenStack-dev-request at lists.openstack.org>?subject:unsubscribe
> >>>>> <
> http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
> >>>>> <
> http://OpenStack-dev-request@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-request at lists.openstack.org
> >>>>>>> <mailto:
> OpenStack-dev-request at lists.openstack.org>?subject:unsubscribe
> >>>>> <
> http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
> >>>>> <
> http://OpenStack-dev-request@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-request at lists.openstack.org
> >>>>>> <mailto:
> OpenStack-dev-request at lists.openstack.org>?subject:unsubscribe
> >>>>> <
> http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
> >>>>> <
> http://OpenStack-dev-request@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-request at lists.openstack.org
> >>>> <mailto:OpenStack-dev-request at lists.openstack.org
> >?subject:unsubscribe
> >>>> <
> http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
> >>>> <
> http://OpenStack-dev-request@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-request at lists.openstack.org
> >>>> <mailto:OpenStack-dev-request at 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-request at lists.openstack.org
> >>> <mailto:OpenStack-dev-request at 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-request at lists.openstack.org?subject:unsubscribe
> >> <
> http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe
> >> <
> http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe <
> http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe
> >> <
> http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe
> >> <
> http://OpenStack-dev-request@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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160325/ccba6a2c/attachment.html>
More information about the OpenStack-dev
mailing list