[Shinken-devel] Shinken 2.4 RC1 is out!
Sebastien Coavoux
We are a bit late on schedule, the 2.4 should have been tagged today but
as we did not made a prior notice for a RC we choose to only tag a RC.
We need some tests and feedback before pushing the real 2.4 because we
still have nothing magic to run a feature-complete test :) (we are
thinking a lot about how to start that).
You can install this tag with a simple pip install
https://github.com/naparuba/shinken/archive/2.4-RC1.zip. Pip will do the
job for you!
The release note are here :
https://github.com/naparuba/shinken/blob/master/Changelog. It is mainly
bug fixing and code stabilization.
However I would like to highlight to of them :
* Pep8 : Shinken is now pep8 compliant (only 3 rules a ignored), and
Travis enforces pep8 for new code.
* Setup.py : if you are used to python virtualenv, you will be happy
with this release. The setup script has been rewritten with pbr and
allow to install Shinken in a virtualenv. You also have the possibility
to install Shinken as a lib (python setup.py develop) so that you don't
have sample config files provided.
We would like to tag the final 2.4 by the end of the week so that we
don't drift too much from the schedule, but of course quality is more
important that strict schedule. Next time we will tag this one or two
week before the official release date.
Have fun trying Shinken 2.4!
Sébastien Coavoux
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Shinken-devel mailing list
Shinke...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shinken-devel
nap
Hi there!
We are a bit late on schedule, the 2.4 should have been tagged today but
as we did not made a prior notice for a RC we choose to only tag a RC.
[...]
Thibault Cohen
Hello everyone !
I'm guilty, this is my fault... :( sorry.
I just created a new pull request that should fix this bug :)
But I have two comments about all of this:
- BETA tags seem to be useless, otherwise someone would have reported this bug earlier...
- 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 ...).
I feel like pip is made to install libs more than full software
Maybe we need to rethink about what setup.py should do and should not do...
For linux installation, I think we should get inspiration from BSD folder architecture generated by pip installation.
You can try with (while the PR is not merged):
- Debian/Ubuntu
- pip install https://github.com/titilambert/shinken/archive/sudo_setup_py.zip --install-option="--install-layout=deb"
- CentOS
- BSD
Don't forget to create shinken user on your shinken ;)
Have nice tests
-- Thibault Cohen
nap
Hello everyone !
I'm guilty, this is my fault... :( sorry.
I just created a new pull request that should fix this bug :)
But I have two comments about all of this:
- BETA tags seem to be useless, otherwise someone would have reported this bug earlier...
- 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 ...).
I feel like pip is made to install libs more than full software
- Maybe we need to rethink about what setup.py should do and should not do...
For linux installation, I think we should get inspiration from BSD folder architecture generated by pip installation.
[...]
-- Thibault Cohen
Andy Xie
------------------------------------------------------------------------------
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
Hermann Lauer
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
> > still issue on debian (I didn't test centos). But the Travis part is ok.
> >
> >> But I have two comments about all of this:
> >>
> >>
> >> 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.
> >
> >>
> >> (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 ...).
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.
> >> I feel like pip is made to install libs more than full software
> >>
> >> Yes, the whole python ecosystem was done for libs, not tools :(
Did the wheel format bring any improvement in this area ?
> > 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).
people with long term support.
> > All we need for this are (easier) orchestration tools and more powerful
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).
> > 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 ^^
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.
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: Herman...@iwr.uni-heidelberg.de
Sebastien Coavoux
(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
Hermann Lauer
On Mon, Apr 13, 2015 at 12:27:17PM -0400, Sebastien Coavoux wrote:
> >> >> - 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 :)
> dpkg-buildpackage -b -rfakeroot
produces a nice python-shinken_2.4-rc2-1_all.deb on jessie, which I have to test now.
Big thanks for that progress, guys!
> > 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.
to Python, where chapter4 is about python packaging and distribution and that PEP 427
was written to define a new python packaging standard: wheel.
> 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.
be finished this year) I like the dev list to hear about your progress,
and also +1 for a users list.
Thanks,