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 :)
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.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
