Open Stack

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>
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>
> 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
> __________________________________________________________________________
> 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
>
-- 

--

Andrew Woodward

Mirantis

Fuel Community Ambassador

Ceph Community
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160312/341457a6/attachment.html>