First of all i have to say that i really love livestatus as it is a great
tool for interacting with third party addons. The only thing i do not like
in current livestatus implementation is just the log part that break the
high availibility model. This is just because livestatus use by default
sqlite3 databases (IMOO sqlite3 is only for desktop applications or embeded
development on phones and tablets). The only way to workaround this is to
use mongologs implementation that is still unstable and not ready for
production. So i can't recommend livestatus in production environments.
But i agree that implementing the webui in such a critic place as the
broker is not the ideal way but it is the easiest one.
2013/2/1 Olivier Hanesse <olivier.hane...@gmail.com>
>
>
> 2013/2/1 nap <napar...@gmail.com>
>
>>
>>
>> On Fri, Feb 1, 2013 at 12:20 PM, Hermann Lauer <
>> hermann.la...@iwr.uni-heidelberg.de> wrote:
>>
>>> Hello,
>>>
>> Hi :)
>>
>>
>>>
>>> [...]
>>>
>>> The standard way in python in my opinion is "setup.py", which translates
>>> nowadays
>>> with two simple commands for example in a deb pkg.
>>> Maybe folding (some) functionality of install into setup.py with only
>>> leaving install
>>> a small driver script is a good way ?
>>>
>> It's true that in python setup.py is the king, but because 90% of the
>> python install is about libs :p
>> For tools with scripts, configuration files and data like us, it's just a
>> nightmare to manage with it, especially now the setup.py is quite hard to
>> read (for myself).
>>
>> I think we should focus on packages for common distributions, make
>> setup.py very simple so packagers and other distribs can use it (but with
>> far less features than install script), and the script can just be a
>> wrapper to put good repositories and install/upgrade packages. There are
>> some tools/plugins that we won't be able to package, so the install script
>> can be useful for them (until every thing is package perfectly :) ).
>>
>>
>>>
>>> > What about the others? What do you want to remove? :)
>>> > I know it's a difficult task, but will help the project to be more
>>> focus on
>>> > what is important.
>>>
>>> Probaly not a real kill of a feature, but anyways:
>>> Separating out the web interface from the broker and make it a wsgi
>>> script communication
>>> with the broker would be in my opinion a good thingTM:
>>> - broker is a somehow overloaded critical component (I noticed that
>>> stopping debug output
>>> in a screen stops the web ui at the moment)
>>> - wsgi the best way known to me for integration into apache for example
>>> - This would allow to kill all login/ssl security stuff from webui, as
>>> you can
>>> get an authenticated user name via environment (needed for the webui
>>> db stuff)
>>> - Also a split in a shinken core and a webui package would be possible,
>>> as
>>> done in carbon-graphite and the graphite-webui package.
>>>
>> It's true, and I though a lot about it when I put webui inside the
>> broker. One problem was about performances, especially for "this" WebUI. If
>> you look at where we got the major performances problems in Shinken (yes
>> there are :) ), it's all about serialization (like all tools, nothing magic
>> here in fact). The goal of being *inside" the broker was to avoid a huge
>> serialization of (huge) objects for each request (direct memory access make
>> 120K object parsing instant :) ).
>>
>> And why "this" webui is so impacted : we are using it to show lot of
>> dependency trees everywhere, and making use of queries for this will kill
>> performances (or you dump the whole tree, or you make X queries for each
>> nodes, but both is asking for huge serialization phase) :(
>>
>> One last thing about "why a module" was the windows run. Putting a wsgi
>> env under windows is not trivial (not too hard, but not trivial too). With
>> a broker module, we got a multi-platform with high availability feature by
>> design. Yes I know that lot of you think running under windows is not a
>> priority, but I think lot of windows admins are blocked with bad tools
>> because they got no good alternative and don't have the time to learn Unix.
>>
>> Of course there are drawback, like the ssl/sso thing (but a reverse proxy
>> can do the trick, there is an option in WebUI for it). One major problem is
>> the lack of scalability for the broker. I think about N broker levels (on
>> in a realm, AND one in the global realm for example, in active/active way),
>> but this won't solve the WebUI scaling problem. I'm still wondering how we
>> can solve this :)
>>
>
>
> We really need to think about this "N broker" stuff.
> - n brokers / realm (so each broker can deal with one module)
> - 1 broker / realm, with potential broker in higher realm
>
> By the way, I don't know (shame on me) how exactly WebUi is working
> internally, but why not using Livestatus as a backend for Webui ?
> I know having all object in memory is a great thing for speed, but I'm
> using Livestatus Uis every day, and the speed of the LiveStatus stack isn't
> an issue at all.
> We will lose (maybe) some 'micro-seconds' of reactivity, but scalability
> will be much easier. And we could have a wsgi env.
>
>
>> Currently, WebUI is strongly linked to the core, and so putting in in
>> another repository is not possible (or we will have lot of problem of "oh
>> why my old webui is not working with y new core" thread on the forums....
>> :( ), but can be possible if we put an abstraction layer like queries
>> between it and some brokers.
>>
>> Can you open a new thread and explain your "screen stop" problem? Sounds
>> strange and we should be able to fix it.
>>
>>
>>>
>>> This are just my 2 cents.
>>> Thanks for the new release now sitting here and has to wait for
>>> installation ;-(
>>>
>> Wait a bit or look at the livestatus patch on the new thread before
>> applying it ;)
>>
>> Thanks a lot for this output :)
>>
>>
>> Jean
>>
>
>
> Olivier
>
>
>>
>>
>>>
>>> greetings
>>> Hermann
>>>
>>> --
>>> Netzwerkadministration/Zentrale Dienste, Interdiziplinaeres
>>> Zentrum fuer wissenschaftliches Rechnen der Universitaet Heidelberg
>>> IWR; INF 368; 69120 Heidelberg; Tel: (06221)54-8236 Fax: -5224
>>> Email: hermann.la...@iwr.uni-heidelberg.de
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Everyone hates slow websites. So do we.
>>> Make your web apps faster with AppDynamics
>>> Download AppDynamics Lite for free today:
>>> http://p.sf.net/sfu/appdyn_d2d_jan
>>> _______________________________________________
>>> Shinken-devel mailing list
>>> Shinken-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/shinken-devel
>>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://p.sf.net/sfu/appdyn_d2d_jan
>> _______________________________________________
>> Shinken-devel mailing list
>> Shinken-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/shinken-devel
>>
>>
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_jan
> _______________________________________________
> Shinken-devel mailing list
> Shinken-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/shinken-devel
>
>
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_jan
_______________________________________________
Shinken-devel mailing list
Shinken-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shinken-devel
