Hi everyone, (Back from holidays too)
Le 2015-04-13 05:11, Hermann Lauer a écrit : > Hello All, > > On Wed, Apr 08, 2015 at 09:51:07AM +0800, Andy Xie wrote: >> currently, there are some docker container in dockerhub. Here is the >> url: >> https://registry.hub.docker.com/search?q=shinken > > nice to know, thanks. > >> > still issue on debian (I didn't test centos). But the Travis part is ok. >> > >> >> But I have two comments about all of this: >> >> >> >> - BETA tags seem to be useless, otherwise someone would have reported >> >> this bug earlier... >> >> >> >> Sad but true. don't expect people to test a beta (unless they are core >> > dev). Even the test level is quite low on RC. It's mainly on few days after >> > the release that we have the most bug ticket. >> > Well, to be honest I don't think (all) core devs tried it. I personally gave a try focusing on BSD part (to not bother ddurieux everytime) and the new feature added (develop). Unless you try the virtualenv part only, I doubt you did try the beta tag Nap. My solution to that is barely the one I give every time : add some automation and testing. If we are lazy to test then code something to make it for us (sysadmin default behavior). But nothing will replace peer reviewing. >> >> >> >> - Also, I think we don't use setuptools as we should. If you look at >> >> what ansible/salt do, they don't ship any files outside /usr/local/ >> >> folder >> >> (using ie: sudo pip install salt). I didn't find any python software >> >> which >> >> copy configuration files in /etc/ or makes some chown during the >> >> installation (pip install ...). > > That are exactely the issues I saw also while trying to debianize > shinken > in the past. With a well written setup.py you can: > - install in your home directory > - run "python setup.py --command-packages=stdeb.command debianize" to > build a .deb at any time. > That was the whole purpose of the setup rework : to have a "well written" file :) >> >> I feel like pip is made to install libs more than full software >> >> >> >> Yes, the whole python ecosystem was done for libs, not tools :( Then why stick with non standard / dirty / custom setup files? After all, I think the install script is not that stupid. What we defined previously as a "normal" install is not really normal in the python world. Maybe we should just call a "clean" setup.py from a shell script to make this "normal" install. I bet it's only a matter of 3 lines in shell (adduser, chown, python setup.py --magical-paramaters). Of course, this prevent from doing a "normal" install from pip, but I don't think we are using it the good way. It's something to really think about because it simplify a lot the maintaining. This first step done, nightly packaging should be a piece of cake. > > Not familiar to this, but read about a month ago (from a french guy > btw): > Did the wheel format bring any improvement in this area ? > As far as I known wheel is for caching purpose. >> > In the next years, I think docker-like ship will be the default (think >> > about docker-like plugins! no more system/python/perl lib issue ^^), and >> > users won't even have to mix local system and applications. And they won't >> > even care where it's installed in the container (as it's a black box and it >> > won't break their system). > > Not so shure about this - you need still a good base distribution > maintained by trustfull > people with long term support. > Well, for now docker has still work to do IMO. It's a new "in" technology but it need some improvements (last time I tried with fedora was a failure). I don't think we can wait for docker to be "cool" enough to provide the community "proper" install methods. >> > All we need for this are (easier) orchestration tools and more powerful > > Better system administration tools - salt is an improvement in this > area, > but there is much room left in this area. But that will need time, so > this is > relying on to be written software... > >> > container monitoring (currently it's not so natural to monitor containers >> > as they can spawn quickly). > > New tasks for shinken ;-) > >> > It can be docker or another container solution, but as it can save a lot >> > of time to admins to install/link new tools, I think it will be really >> > asked in production, and not just a dev playground tool ^^ > > That is also my feeling, while the classical distribution systems will > be used > also - at least during the next years. One plus I see there is also the > keeping > of record of configuration of packages you installed in the past in a > cheap way. > I would like to come back on the way this release is handled. This is the devel list but we all now that some users are on it. This is our main way to keep them updated on what is happening now. Unfortunately I cannot see any info about what is going to happen to the release on this list. I try my best on the previous email to explain why the release was late and what were the next steps but nothing more since. Am I the only one to care about being consistent with what we've announced before? The release is 13 days late, I think people deserve some news. IRC is a place to share but there are not as many people on that medium. I really think there is communication problem there. Issues are not clearly stated and there is no real direction to fix them. I mean, there was no clear communication saying : "Ok we are reverting on this day if no fix is found and release on this (other) day. We want the setup.py to be consistent balbla". Is this being too "pro" to do so? People that don't check what's going on Github won't know that we reverted that today, too bad for them. I'm raising all this here because it's devel list, maybe we should create users list because people may not be interested in this debate. Regards, Sébastien > But just my 2pence after Easter holidays, > thanks for your work and > 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 > > ------------------------------------------------------------------------------ > BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT > Develop your own process in accordance with the BPMN 2 standard > Learn Process modeling best practices with Bonita BPM through live > exercises > http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- > event?utm_ > source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF > _______________________________________________ > Shinken-devel mailing list > Shinken-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shinken-devel ------------------------------------------------------------------------------ BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF _______________________________________________ Shinken-devel mailing list Shinken-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shinken-devel
