Open Stack

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>
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>:
>
>> 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>
>> 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>
>>> написав(ла):
>>>
>>>
>>> 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 <ppetit at mirantis.com>>> wrote:
>>>
>>>
>>>    On 11 March 2016 at 12:51:40, Igor Kalnitsky
>>>    (ikalnitsky at mirantis.com <mailto:ikalnitsky at mirantis.com
>>> <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
>>> <ppetit at mirantis.com>>> wrote:
>>>
>>>
>>> On 11 March 2016 at 11:34:32, Igor Kalnitsky (ikalnitsky at mirantis.com <
>>> mailto:ikalnitsky at mirantis.com <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 <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 <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 <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
>>>
>>>
>>>
>>> __________________________________________________________________________
>>>
>>> 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
>>>
>>>
>>>
>>> __________________________________________________________________________
>>>
>>> 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
>>>
>>>
>>>
>>> __________________________________________________________________________
>>>
>>> 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
>>>
>>>
>>>    __________________________________________________________________________
>>>    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
>>>
>>> --
>>> Mike Scherbakov
>>> #mihgen
>>>
>>>
>>>
>>> __________________________________________________________________________
>>> 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
>>>
>> --
>> Mike Scherbakov
>> #mihgen
>>
>> __________________________________________________________________________
>> 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
>>
>>
>
>
> --
> 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://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 
Mike Scherbakov
#mihgen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160311/f2036a8e/attachment.html>