Open Stack

On 11 March 2016 at 12:51:40, Igor Kalnitsky (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> wrote: 
> 
> On 11 March 2016 at 11:34:32, Igor Kalnitsky (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> 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) 
>> wrote: 
>> 
>> Hello Roman, 
>> 
>> On Fri, Mar 11, 2016 at 9:57 AM, Roman Prykhodchenko <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://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 
>> 
>> 
>> __________________________________________________________________________ 
>> 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 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160311/fcaf36de/attachment.html>