Open Stack

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>> wrote:
> 
> 
>     On 11 March 2016 at 12:51:40, Igor Kalnitsky
>     (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>> wrote: 
>>     > 
>>     > On 11 March 2016 at 11:34:32, Igor Kalnitsky (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>> 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>) 
>>     >> wrote: 
>>     >> 
>>     >> Hello Roman, 
>>     >> 
>>     >> On Fri, Mar 11, 2016 at 9:57 AM, Roman Prykhodchenko <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://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 
>>     >> 
>>     >> 
>>     >> __________________________________________________________________________ 
>>     >> 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://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://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