[dev] Package discussion & Init scripts

[Martin Winter]

Donald,

ok, these are different issues (mostly) than the combined/separate init 
script

In general, these are all good goals, but I do believe the goal to get 
ANY
packages should be a much higher priority than having the perfect 
packages.

I’m constantly asked about packages and I think we need something 
ASAP.

After all, nobody asks for perfect implementation on protocols either on
the first attempt.

Specific comments inline


On 14 May 2017, at 17:35, Donald Sharp wrote:

> Here are a list of my requirements that I feel we must be able to 
> support
>
> 1. Must be able to:
>     1. Start -> Start specified daemons
>     2. Stop -> Stop specified daemons

Obvious basic functionality

>     3. Reload -> Reread in config, without destroying existing
> connections (example would be that if I added a new peer to the bgp
> config, existing bgp sessions are not brought down and then back up)

How should/would this work on systems WITHOUT integrated config?
Or are you proposing to block integrated config and rip that code out?
And how does integrated config work without zebra running?

The only solution we have as of know is with some python script and
for the integrated config only.
I strongly recommend to make this optional as not everyone uses
integrated configs or has a system which supports the python (and
required python packages) needed to run this.

My proposed solution is to have this in a sub package which can
be installed if required (and it’s built by the same spec/debian
files.
I seriously want to avoid having a python 2.7 or 3 (actually you
have to pick one specific one in packages as you can’t have a 
either/or
requirement) for the base package.

I was hoping Silas would find a way how to do this better, but his
solution has a bug as he doesn’t require python at all and it will 
fail
if no python 2.7 or 3.x is installed at build or installation time.

Best solution would be to convert the python into a binary somehow
(compiler python -> binary?? or rewrite it)

>     4. Restart -> Restart the daemons( Hard reset )

Done. But basically the same as stop & start

> 2. Consistency of look/feel across multiple platforms for reference 
> packaging
>     1. Pre Systemd
>         1. Redhat and Debian must have the same ability to handle 
> 1.(1-4) above
>         2. FRR monitoring is a nice to have (watchfrr comes to mind)

Except 3 (where I implemented it in an optional add-on package) it is 
done.

>     2. Post Systemd
>         1. Redhat and Debian must have the same ability to handle 
> 1.(1-4) above
>         2. System Monitoring via systemd must be integrated in some 
> manner

Done same as pre-systems as it uses the same init script

>     3. Both Pre and Post Systemd must have the same ability to specify
> which daemons to startup in the same manner

Currently done, but may not be liked be package maintainers they way
we did it. We have this based on /etc/frr/daemons, but I do believe
package maintainers prefer it as /etc/default/frr.conf (debian) or
/etc/sysconfig/frr.conf (red hat) and other ways on *BSD systems.

>     These pre systemd systems( from a linux perspective )are becoming
> rarer, startup across these platforms still needs to be thought about

Still a large amount of systems without systemd (i.e. Suse)
The way we have it now with a init script and then systemd encapsulating
it should be fine for some time.

> 2. Ease of integrating new features across startup scripts
>     1. Example -> New valgrind feature to run all interested daemons
> as part of startup https://github.com/FRRouting/frr/pull/449

Trivial change even with multiple init scripts.
Could be made even easier to move some generic logic into
/etc/frr/daemons which then would need no init script changes

> 3. Startup of new daemons from within vtysh
>     1. I realize that this is not implemented but any solution we
> specify needs to be able to support this in the future.

Future work.

So PLEASE, PLEASE - can we get this in ASAP???

We are talking about 2.0 at this time and we need to improve on it
on 3.0

I really like to get something in first, then start working on
improving it.

- Martin



> On Sun, May 14, 2017 at 6:41 AM, Martin Winter
> <mwinter at opensourcerouting.org> wrote:
>> So I haven’t seen anyone else chiming in.
>>
>> I’ve talked to Jakob Haufe (sur5r at sur5r.net) who is involved on 
>> Debian
>> packages (and a maintainer for several packages).
>>
>> He seems to strongly suggest to keep the init scripts separate 
>> between
>> major distributions (debian vs redhat).
>>
>> I’m going to ask for more specific details on the reasoning…
>>
>> - Martin
>>
>>
>>
>> On 6 May 2017, at 18:38, Martin Winter wrote:
>>
>>> So to start this discussion on the packaging, I would like to base
>>> this discussion on 2 decisions which need to be done first:
>>>
>>> --
>>>
>>> 1) Do we want to use 'vtysh integrated-config' for FRR 2.0 packages 
>>> ?
>>>
>>> I believe we all agree that this is the way to go in the future. I'm
>>> certain
>>> we had this discussion before (but can't find pointers in my email). 
>>> My
>>> understanding is that we decided to use per-daemon config for 2.0, 
>>> but
>>> plan to move to integrated configs soon after.
>>>
>>> The main discussion point was the migration path from classic Quagga
>>> (with separate configs) and the lack of the capability for each
>>> daemon to read directly from the integrated config (which requires
>>> the extra step of vtysh to re-load configs if a daemon restart).
>>>
>>> There is also the issue for users not running zebra (or does 
>>> integrated
>>> config work for a deployment with only BGP?)
>>>
>>> I thought we agreed to somehow address these issues before we push 
>>> users
>>> to the integrated config.
>>>
>>> Anyone remembers this discussion? (Or remembers it different?)
>>>
>>> --
>>>
>>> 2) Do we want the packages on each platform as close to each other
>>> as possible or do we want it to follow the conventions of each 
>>> distro
>>> as close as possible?
>>>
>>> I assume (on the short term), we end up at least with packages for
>>> - Debian (Ubuntu 14.04, 16.04, Debian 8)
>>> - Redhat (RedHat 6, 7, CentOS 6, 7, Fedora)
>>> - FreeBSD
>>> - Snap packages
>>>
>>> I thought about the packages as reference packages for package 
>>> maintainers
>>> to build on (and the merging changes from the back in as far as 
>>> possible)
>>>
>>> Each platform has differences in capabilities and guidelines for
>>> building them:
>>> - Conventions where configs and binaries should be installed
>>> - Startup system (init.d, systemd and others)
>>> - Configuration location (ie /etc/sysconfig for redhat, /etc/debian 
>>> for
>>> debian etc)
>>>
>>> Each system also provides functions and examples for startup 
>>> scripts.
>>>
>>> After this is decided, then I think we can talk about the issues on
>>> exceptions
>>>
>>> Technical challenges like:
>>> - everything runs under root with apparmor (ie Snap's)
>>> - Some required packages are not available from standard repo (ie 
>>> Python
>>> 2.7
>>> or ipaddr python module for Redhat 6)
>>>
>>> --
>>>
>>> My preferred short term solution:
>>>
>>> I would still prefer to get the redhat changes in as they are now 
>>> for the
>>> stable/2.0
>>> branch (and the debian changes as soon as possible as well). We 
>>> could
>>> reopen this
>>> discussion later once we actually have working packages for at least 
>>> these
>>> 2 platforms
>>>
>>> --
>>>
>>> I really like to get more opinions here - beside mine and Donald's.
>>> Specially
>>> if you have experience with packages or you know someone you could 
>>> ask.
>>>
>>> - Martin
>>>
>>> Here is a link to some basic description of an init file for RedHat 
>>> based
>>> systems:
>>> http://www.sensi.org/~alec/unix/redhat/sysvinit.html (Original is 
>>> provided
>>> on
>>> a redhat system in /usr/share/doc/initscripts-*/sysvinitfiles)
>>
>>
>> _______________________________________________
>> dev mailing list
>> dev at lists.frrouting.org
>> https://lists.frrouting.org/listinfo/dev