Hi, I agreed to adopt a new install way than the install script. But in my opinion we have to keep the facility to integrate addon and plugin from install script. It is a great tool for beginner that want to integrate some addons to shinken without problems, or for us to test them.
-- *Romain Forlot* ---- Le Sat, 02 Feb 2013 06:37:33 +0100 David GUENAULT a écrit ---- >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 > > >2013/2/1 nap > > >On Fri, Feb 1, 2013 at 12:20 PM, Hermann Lauer 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 > ------------------------------------------------------------------------------ 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
