[openstack-dev] [Fuel] Removing logs from Fuel Web UI and Nailgun
Anastasia Urlapova
aurlapova at mirantis.com
Fri Mar 25 12:54:45 UTC 2016
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 <dpyzhov at 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 <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
>>
>>
>
> __________________________________________________________________________
> 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/804843e9/attachment-0001.html>
More information about the OpenStack-dev
mailing list