[openstack-dev] [Fuel] Removing logs from Fuel Web UI and Nailgun
Dmitry Pyzhov
dpyzhov at mirantis.com
Fri Mar 25 18:31:50 UTC 2016
Anastasia,
we are going to invest one more day in investigation of high priority bug,
we cannot reproduce it at the moment. I don't think that we should fix
medium bugs in feature that soon will be deprecated.
On Fri, Mar 25, 2016 at 3:54 PM, Anastasia Urlapova <aurlapova at mirantis.com>
wrote:
> 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
>>
>>
>
> __________________________________________________________________________
> 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/5ce5ac97/attachment.html>
More information about the OpenStack-dev
mailing list