[openstack-dev] [Fuel] Removing logs from Fuel Web UI and Nailgun
Bogdan Dobrelya
bdobrelia at mirantis.com
Mon Mar 14 08:53:49 UTC 2016
On 03/14/2016 09:38 AM, Anastasia Urlapova wrote:
> +1 to Vitaliy, it would be nice find somewhere a details for migration.
> And one more concern I should highlight - for some users logless UI may
> be challenging thing.
> The logs removing shouldn't affect the UX.
Logs will still live at the master node's /var/log/remote
>
>
> Nastya.
>
>
> On Sat, Mar 12, 2016 at 3:08 AM, Andrew Woodward <xarses at gmail.com
> <mailto:xarses at gmail.com>> wrote:
>
> 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 <mailto: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 <mailto: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 <mailto: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 <mailto: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
>> <mailto: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>
>>> <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> <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> <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> <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> <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> <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> <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
>>>>>>> <mailto: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
>>>>>> <mailto: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
>>>>>> <mailto: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
>>>>> <mailto: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
>>> <mailto: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
>>> <mailto: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
>> <mailto: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://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://OpenStack-dev-request@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://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://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> --
>
> --
>
> Andrew Woodward
>
> Mirantis
>
> Fuel Community Ambassador
>
> Ceph Community
>
>
> __________________________________________________________________________
> 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://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
--
Best regards,
Bogdan Dobrelya,
Irc #bogdando
More information about the OpenStack-dev
mailing list