Open Stack

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> написав(ла):
> 
> 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 <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 <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 <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 <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/ <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 <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 <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 <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?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 <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 <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 <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 <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 <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 <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 <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/20160311/6c248daf/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160311/6c248daf/attachment.pgp>