Open Stack

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160311/a6f52e1a/attachment.html>