On Fri, Feb 1, 2013 at 12:20 PM, Hermann Lauer <Hermann.Lauer@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 :)

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
 

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.Lauer@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