On Tue, Feb 25, 2014 at 4:59 PM, Rémi Palancher <r...@rezib.org> wrote:
> Hi there,
>
Hi :)
>
> There has been many discussions on IRC channel lately and some commits
> about the setup.py in order to fix some bugs regarding pip and also
> complains about its inner complexity.
>
yep, it's over complex for an easy task indeed.
>
> As a base statement to the following proposals, I think both distutils
> and setuptools are clearly NOT designed to install complex distributed
> daemons like Shinken. This has never been part of the goals of these
> tools. Trying to deeply hacking them for such purpose is totally error
> prone.
>
Yes, pip is designed for lib, setuptools can manage data_files, there is
even some setup() parameters especially for this purpose, and it works
quite well for easy cases like us (bunch of files with the same users and
no real modifications into the files).
>
> Here are 2 things I think Shinken setup.py SHOULDN'T do:
>
> - Installing default init scripts: init scripts (and also systemd unit
> files) must be considered as distributions and OS specifics. Paths,
> shell functions, daemons launchers are not common on all distributions.
> Requirements and constraints also change from one release of a
> distribution to another. Writing working init scripts is hard, this
> responsability should be let to packagers.
>
Writing init scripts that will be accepted by both debian AND redhat
mainteners is not hard, it's impossible :)
(why redhat/debian: they are the main distro we manage by default). It's
possible to write scripts that work well on both without problems (and
maintenable). But I already drop this fight years ago. We wrote init.d
scripts that works well for upstream and make them usable. If packagers
want to write new one that are fitting better the "distro" habits, that's
their job indeed, and it's a really hard work.
But I think you are wrong when you say we should not provide init.d script
in upstream. It should be runnable without asking packager to do another
part of the job or be forced to be run with packages (why if you run the
master version? Like I do? :) ).
Of course lot of the users will be running with packages, and so the init.d
scripts from the package, and so we will provide help to packager to write
init.d scripts that won't hurt the daemons or the user experience :)
> - Managing files owners: users and groups management should be done
> under the control of the package management system. Advanced package
> management systems are able to track groups/owners of installed files
> unless chown is done by scripts.
>
> I think that supporting 'pip install' or 'setup.py install' methods for
> production use of Shinken is a bad idea. Some /magical stuff/ should be
> removed from current setup.py so that RPM/DEB/whatever packaging effort
> could be done easier with these limitations in mind.
>
yes, should be done by package when they are available. But one time again,
upstream is not done to be run only by packages. And hopefully we only need
files with shinken:shinken, so the user management is quite trivial. I
don't plan to add such silly thing in the setup.py that will create the
user if not existing or things like that. Because there of course it will
complexify a LOT the package creation :p
But running a recursive chown of the data_files with the shinken:shinken
user/group is not so terrible or hard to manage, especially that the
directories are quite easy to find (hum... etc, lib and log... I think we
will manage this :) ).
We can have a hard case if the user install with setup.py and then use
shinken as package, that will mix all; but I think admin are not stupid and
won't mix installation methods :)
One last point: the update. I plan to only update the .py (the python lib
and the default cli modules) and scripts with a setup.py update, and do not
touch at the configuration or hard things like this, that only packages can
manage in a good way (.rpmnew and co).
>
> This is only my own personal point of view. I'm looking forward to
> reading your feedback about these thoughts!
>
No thanks for sharing your point of view :)
As a packager I think I understand your thoughts, but one important point
is that we should be not rely only on the packages only. As we are going
quite quickly on the features, we should also be able to run in a "quite a
good" way with upstream. The fact that I personnaly run my servers in this
mode can make me not so objective of course :)
One last important point is that the setup.py should be still usable to
build a package in a good way, and currently the setup.py is just too
complex to handle new files or filterings (like no init.d files option or
thing like this). We will have to rewrite it for the 2.2 version, and this
time I hope it will automatically make it possible to run with pip :)
Jean
>
> --
> Rémi Palancher
>
>
>
> ------------------------------------------------------------------------------
> Flow-based real-time traffic analytics software. Cisco certified tool.
> Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
> Customize your own dashboards, set traffic alerts and generate reports.
> Network behavioral analysis & security monitoring. All-in-one tool.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
> _______________________________________________
> Shinken-devel mailing list
> Shinken-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/shinken-devel
>
------------------------------------------------------------------------------
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis & security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
_______________________________________________
Shinken-devel mailing list
Shinken-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shinken-devel
