[openstack-dev] [Fuel] Removing logs from Fuel Web UI and Nailgun
Roman Prykhodchenko
me at romcheg.me
Mon Mar 14 12:02:31 UTC 2016
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160314/1332b3d0/attachment.pgp>
More information about the OpenStack-dev
mailing list