Open Stack

Guys, thank you for your feedback. As a quick and dirty solution we
continue to hide extra information from UI. It will not break existing user
experience.

Roman, there were attempts to get rid of our current web logs page and use
Logstash. As usual, it's all about time and resources. It is our backlog,
but it is not in our current roadmap.

On Mon, Dec 15, 2014 at 6:11 PM, Roman Prykhodchenko <me at romcheg.me> wrote:
>
> Hi folks!
>
> In most productions environments I’ve seen bare logs as they are shown now
> in Fuel web UI were pretty useless. If someone has an infrastructure that
> consists of more that 5 servers and 5 services running on them they are
> most likely to use logstash, loggly or any other log management system.
> There are options for forwarding these logs to a remote log server and
> that’s what is likely to be used IRL.
>
> Therefore for production environments formatting logs in Fuel web UI or
> even showing them is a cool but pretty useless feature. In addition to
> being useless in production environments it also creates additional load to
> the user interface.
>
> However, I can see that developers actually use it for debugging or
> troubleshooting, so my proposal is to introduce an option for disabling
> this feature completely.
>
>
> - romcheg
>
> > On 15 Dec 2014, at 12:40, Tomasz Napierala <tnapierala at mirantis.com>
> wrote:
> >
> > Also +1 here.
> > In huge envs we already have problems with parsing performance. In long
> long term we need to think about other log management solution
> >
> >
> >> On 12 Dec 2014, at 23:17, Igor Kalnitsky <ikalnitsky at mirantis.com>
> wrote:
> >>
> >> +1 to stop parsing logs on UI and show them "as is". I think it's more
> >> than enough for all users.
> >>
> >> On Fri, Dec 12, 2014 at 8:35 PM, Dmitry Pyzhov <dpyzhov at mirantis.com>
> wrote:
> >>> We have a high priority bug in 6.0:
> >>> https://bugs.launchpad.net/fuel/+bug/1401852. Here is the story.
> >>>
> >>> Our openstack services use to send logs in strange format with extra
> copy of
> >>> timestamp and loglevel:
> >>> ==> ./neutron-metadata-agent.log <==
> >>> 2014-12-12T11:00:30.098105+00:00 info: 2014-12-12 11:00:30.003 14349
> INFO
> >>> neutron.common.config [-] Logging enabled!
> >>>
> >>> And we have a workaround for this. We hide extra timestamp and use
> second
> >>> loglevel.
> >>>
> >>> In Juno some of services have updated oslo.logging and now send logs in
> >>> simple format:
> >>> ==> ./nova-api.log <==
> >>> 2014-12-12T10:57:15.437488+00:00 debug: Loading app ec2 from
> >>> /etc/nova/api-paste.ini
> >>>
> >>> In order to keep backward compatibility and deal with both formats we
> have a
> >>> dirty workaround for our workaround:
> >>> https://review.openstack.org/#/c/141450/
> >>>
> >>> As I see, our best choice here is to throw away all workarounds and
> show
> >>> logs on UI as is. If service sends duplicated data - we should show
> >>> duplicated data.
> >>>
> >>> Long term fix here is to update oslo.logging in all packages. We can
> do it
> >>> in 6.1.
> >>>
> >>> _______________________________________________
> >>> OpenStack-dev mailing list
> >>> OpenStack-dev at lists.openstack.org
> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>
> >>
> >> _______________________________________________
> >> OpenStack-dev mailing list
> >> OpenStack-dev at lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> > --
> > Tomasz 'Zen' Napierala
> > Sr. OpenStack Engineer
> > tnapierala at mirantis.com
> >
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> 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/20141216/2ea37b64/attachment.html>