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
