Package discussion & Init scripts
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)
So I haven’t seen anyone else chiming in. I’ve talked to Jakob Haufe (sur5r@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)
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 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) 4. Restart -> Restart the daemons( Hard reset ) 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) 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 3. Both Pre and Post Systemd must have the same ability to specify which daemons to startup in the same manner These pre systemd systems( from a linux perspective )are becoming rarer, startup across these platforms still needs to be thought about 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 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. On Sun, May 14, 2017 at 6:41 AM, Martin Winter <mwinter@opensourcerouting.org> wrote:
So I haven’t seen anyone else chiming in.
I’ve talked to Jakob Haufe (sur5r@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@lists.frrouting.org https://lists.frrouting.org/listinfo/dev
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@opensourcerouting.org> wrote:
So I haven’t seen anyone else chiming in.
I’ve talked to Jakob Haufe (sur5r@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@lists.frrouting.org https://lists.frrouting.org/listinfo/dev
Well... let's add my 2 euro-cents. This mail will sound somewhat annoyed, please read further down why I think none of this is productive. On Sat, May 06, 2017 at 06:38:57PM -0700, Martin Winter wrote:
1) Do we want to use 'vtysh integrated-config' for FRR 2.0 packages ?
"Mu." - You're asking the wrong question. vtysh and the daemons actually autodetect whether an integrated config is in use. The decision is made by what the distro packages and what the admin has on his system. This also means our code should work with both, for now. We should probably add a deprecation warning if independent-config is in use -- on 3.0. I don't want to touch 2.0 on this anymore.
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?
The latter, because the distro doesn't package "our" pieces, they create packages according to their own guidelines and rules. It's a huge problem if we distribute packages with the same name, but differing conventions. In fact, if we have packaging scripts in our repo, we should pull in the distro's changes. Note Debian explicitly recommends *against* having /debian in a release tarball, cf. https://wiki.debian.org/UpstreamGuide#Pristine_Upstream_Source Note that they explicitly distinguish git vs. tarball, and we actually are in "compliance" with that since our debian/ dir is not listed in Makefile.am. I would argue the same for redhat/. Making FRR usage as similar as possible across different OSes is a nice goal, but when we start talking about init systems we're overstepping our boundaries. Linux distros had and still have individual init systems and conventions for 20 years, and LSB and FHS are putting a lot of work into trying to make the world better here. We won't be solving this in a few weeks. (Neither does systemd, btw.)
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)
That's a nice thought, but this is a great example of the road to hell being paved with good intentions. I can promise you 90% of distros will flat-out delete or ignore it.
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
There is nothing for us to decide here. Our next action is: 0. make tarballs available for frr 2.0. I can't believe we don't have a dist tarball up. THIS IS WHY WE DON'T HAVE FRR PACKAGES IN DISTROS. THERE'S NO TARBALL FOR THEM TO BUILD OFF. DISTROS DON'T WANT TO BUILD FROM GIT. 1. put up a README for the distro maintainers on what we're planning to do. IMHO, it needs to say 2 things: (a) we're moving towards integrated config; right now we're trying to detect and adapt, but at some point this may change. (b) watchfrr may be becoming more important for multi-instance management so we can start ospf #5 on a "router ospf 5" If we have things we need agreement on here - please start a new thread. 2. wait, talk, wait, and talk to the distros. They'll make FRR packages by copying their Quagga build descriptions. If we have good READMEs and talk to them nicely, we can influence this. If we sit on our asses - or try to dictate what they should do - they'll do what they think is best while ignoring our plans. So... I think we're deep in bikeshedding land here. The PR with the RedHat changes doesn't matter, because whoever picks up FRR at RedHat is gonna run it over with a lawnmower anyway. Neither do our attempts to unify FRR across distros - they will get the lawnmower too. To be even more explicit, I am in strong disfavor of even discussing this in yet another meeting (weekly, maintainers or TSC). It's simply not productive. We don't need a decision, because we already went down the wrong path earlier and are now deciding whether we want our highway to nowhere with 4 or 6 lanes. Sighing, -David P.S.: Things being in distro's decision-space pretty sure means neither Martin nor Donald get their cake and eat it.
On Mon, May 22, 2017 at 06:34:24PM +0200, David Lamparter wrote:
There is nothing for us to decide here. Our next action is:
0. make tarballs available for frr 2.0.
I can't believe we don't have a dist tarball up. THIS IS WHY WE DON'T HAVE FRR PACKAGES IN DISTROS. THERE'S NO TARBALL FOR THEM TO BUILD OFF. DISTROS DON'T WANT TO BUILD FROM GIT.
After Quentin pointed out in Slack that you can upload additional files on github on a release tag, I've uploaded .tar.xz and .tar.gz dist tarballs for frr-2.0. Next up:
1. put up a README for the distro maintainers on what we're planning to do. IMHO, it needs to say 2 things:
(a) we're moving towards integrated config; right now we're trying to detect and adapt, but at some point this may change. (b) watchfrr may be becoming more important for multi-instance management so we can start ospf #5 on a "router ospf 5"
If we have things we need agreement on here - please start a new thread.
2. wait, talk, wait, and talk to the distros. They'll make FRR packages by copying their Quagga build descriptions. If we have good READMEs and talk to them nicely, we can influence this. If we sit on our asses - or try to dictate what they should do - they'll do what they think is best while ignoring our plans.
+1 On 5/22/2017 11:34 AM, David Lamparter wrote:
Well... let's add my 2 euro-cents. This mail will sound somewhat annoyed, please read further down why I think none of this is productive.
On Sat, May 06, 2017 at 06:38:57PM -0700, Martin Winter wrote:
1) Do we want to use 'vtysh integrated-config' for FRR 2.0 packages ? "Mu." - You're asking the wrong question.
vtysh and the daemons actually autodetect whether an integrated config is in use. The decision is made by what the distro packages and what the admin has on his system. This also means our code should work with both, for now.
We should probably add a deprecation warning if independent-config is in use -- on 3.0. I don't want to touch 2.0 on this anymore.
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? The latter, because the distro doesn't package "our" pieces, they create packages according to their own guidelines and rules. It's a huge problem if we distribute packages with the same name, but differing conventions. In fact, if we have packaging scripts in our repo, we should pull in the distro's changes.
Note Debian explicitly recommends *against* having /debian in a release tarball, cf. https://wiki.debian.org/UpstreamGuide#Pristine_Upstream_Source Note that they explicitly distinguish git vs. tarball, and we actually are in "compliance" with that since our debian/ dir is not listed in Makefile.am. I would argue the same for redhat/.
Making FRR usage as similar as possible across different OSes is a nice goal, but when we start talking about init systems we're overstepping our boundaries. Linux distros had and still have individual init systems and conventions for 20 years, and LSB and FHS are putting a lot of work into trying to make the world better here. We won't be solving this in a few weeks.
(Neither does systemd, btw.)
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) That's a nice thought, but this is a great example of the road to hell being paved with good intentions. I can promise you 90% of distros will flat-out delete or ignore it.
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 There is nothing for us to decide here. Our next action is:
0. make tarballs available for frr 2.0.
I can't believe we don't have a dist tarball up. THIS IS WHY WE DON'T HAVE FRR PACKAGES IN DISTROS. THERE'S NO TARBALL FOR THEM TO BUILD OFF. DISTROS DON'T WANT TO BUILD FROM GIT.
1. put up a README for the distro maintainers on what we're planning to do. IMHO, it needs to say 2 things:
(a) we're moving towards integrated config; right now we're trying to detect and adapt, but at some point this may change. (b) watchfrr may be becoming more important for multi-instance management so we can start ospf #5 on a "router ospf 5"
If we have things we need agreement on here - please start a new thread.
2. wait, talk, wait, and talk to the distros. They'll make FRR packages by copying their Quagga build descriptions. If we have good READMEs and talk to them nicely, we can influence this. If we sit on our asses - or try to dictate what they should do - they'll do what they think is best while ignoring our plans.
So... I think we're deep in bikeshedding land here. The PR with the RedHat changes doesn't matter, because whoever picks up FRR at RedHat is gonna run it over with a lawnmower anyway. Neither do our attempts to unify FRR across distros - they will get the lawnmower too.
To be even more explicit, I am in strong disfavor of even discussing this in yet another meeting (weekly, maintainers or TSC). It's simply not productive. We don't need a decision, because we already went down the wrong path earlier and are now deciding whether we want our highway to nowhere with 4 or 6 lanes.
Sighing,
-David
P.S.: Things being in distro's decision-space pretty sure means neither Martin nor Donald get their cake and eat it.
_______________________________________________ dev mailing list dev@lists.frrouting.org https://lists.frrouting.org/listinfo/dev
On 22 May 2017, at 9:34, David Lamparter wrote:
Well... let's add my 2 euro-cents. This mail will sound somewhat annoyed, please read further down why I think none of this is productive.
I think you answer the wrong question… see below
On Sat, May 06, 2017 at 06:38:57PM -0700, Martin Winter wrote:
1) Do we want to use 'vtysh integrated-config' for FRR 2.0 packages ?
"Mu." - You're asking the wrong question.
vtysh and the daemons actually autodetect whether an integrated config is in use. The decision is made by what the distro packages and what the admin has on his system. This also means our code should work with both, for now.
There are 2 possible different issues here: Distro’s and our packages. The can (and in a good case should) be similar, but for most OS projects I see them very different - just for the fact that packages in distro’s lag behind the development in years. My believe is to have our own packages up (like many other packages do) and merge in as much as we can/agree from future distro packages.
We should probably add a deprecation warning if independent-config is in use -- on 3.0. I don't want to touch 2.0 on this anymore.
Different discussion, but I’m open on this (at least for 3.0). Personally I would prefer some transition script to convert to integrated config.
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?
The latter, because the distro doesn't package "our" pieces, they create packages according to their own guidelines and rules. It's a huge problem if we distribute packages with the same name, but differing conventions. In fact, if we have packaging scripts in our repo, we should pull in the distro's changes.
Note Debian explicitly recommends *against* having /debian in a release tarball, cf. https://wiki.debian.org/UpstreamGuide#Pristine_Upstream_Source Note that they explicitly distinguish git vs. tarball, and we actually are in "compliance" with that since our debian/ dir is not listed in Makefile.am. I would argue the same for redhat/.
First of all, we don’t have debian package infrastructure yet. We have a start of it as a work-in-progress PR by Silas.
From my discussion with Debian maintainers, the main issue is that their build system is using “debian” as a subdirectory during the building of packages and the issue is because of this (they need to delete it or merge it or something else and it causes extra work)
Some of them prefer the debian part in separate git which I don’t like because of the painful version dependency hacks to match one debian script dir with a specific frr git. An acceptable workaround (as confirmed by multiple debian folks) is to call the directory anything else - i.e. “debianpkg”. This could then be part of the release tarball with no issues. Redhat has no such issues as there is no reserved “redhat” directory name. So I see no problem to have this part of the release tar ball.
Making FRR usage as similar as possible across different OSes is a nice goal, but when we start talking about init systems we're overstepping our boundaries. Linux distros had and still have individual init systems and conventions for 20 years, and LSB and FHS are putting a lot of work into trying to make the world better here. We won't be solving this in a few weeks.
(Neither does systemd, btw.)
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)
That's a nice thought, but this is a great example of the road to hell being paved with good intentions. I can promise you 90% of distros will flat-out delete or ignore it.
Their choice and our influence is probably limited. But I was told that as further away it gets from Quagga (i.e. more work for them to just change the Quagga package) makes it more likely for them to at least have a good look at our package scripts. But they ultimately make their own decision and they have to “support” it in some way.
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
There is nothing for us to decide here. Our next action is:
0. make tarballs available for frr 2.0.
I can't believe we don't have a dist tarball up. THIS IS WHY WE DON'T HAVE FRR PACKAGES IN DISTROS. THERE'S NO TARBALL FOR THEM TO BUILD OFF. DISTROS DON'T WANT TO BUILD FROM GIT.
1. put up a README for the distro maintainers on what we're planning to do. IMHO, it needs to say 2 things:
(a) we're moving towards integrated config; right now we're trying to detect and adapt, but at some point this may change. (b) watchfrr may be becoming more important for multi-instance management so we can start ospf #5 on a "router ospf 5"
If we have things we need agreement on here - please start a new thread.
I see this as a different PR and welcome anyone trying to do this.
2. wait, talk, wait, and talk to the distros. They'll make FRR packages by copying their Quagga build descriptions. If we have good READMEs and talk to them nicely, we can influence this. If we sit on our asses - or try to dictate what they should do - they'll do what they think is best while ignoring our plans.
So... I think we're deep in bikeshedding land here. The PR with the RedHat changes doesn't matter, because whoever picks up FRR at RedHat is gonna run it over with a lawnmower anyway. Neither do our attempts to unify FRR across distros - they will get the lawnmower too.
It matters for multiple folks: - The users which currently use my broken frr-test packages from the CI - Various SDN/Whitebox distros (ODL, OpenSwitch etc) which build based on OUR package directories (no, they are NOT ignoring them unless they need to fix/change them) - My CI system which uses them for testing - Users which come directly to us to look for up-to-date packages I see no bike shedding here - I see different discussions.
To be even more explicit, I am in strong disfavor of even discussing this in yet another meeting (weekly, maintainers or TSC). It's simply not productive. We don't need a decision, because we already went down the wrong path earlier and are now deciding whether we want our highway to nowhere with 4 or 6 lanes.
So you are proposing to NOT provide any packages for specific Distros? And yes, I want this on tomorrows meeting to see how to proceed. - Martin
P.S.: Things being in distro's decision-space pretty sure means neither Martin nor Donald get their cake and eat it.
Or you could ignore the distro cake if you don’t see a need and let everyone else have the option for it.
On Mon, May 22, 2017 at 02:18:55PM -0700, Martin Winter wrote:
On 22 May 2017, at 9:34, David Lamparter wrote:
Well... let's add my 2 euro-cents. This mail will sound somewhat annoyed, please read further down why I think none of this is productive.
I think you answer the wrong question… see below
My argument is that you're asking the wrong question...
On Sat, May 06, 2017 at 06:38:57PM -0700, Martin Winter wrote:
1) Do we want to use 'vtysh integrated-config' for FRR 2.0 packages ?
"Mu." - You're asking the wrong question.
vtysh and the daemons actually autodetect whether an integrated config is in use. The decision is made by what the distro packages and what the admin has on his system. This also means our code should work with both, for now.
There are 2 possible different issues here: Distro’s and our packages. The can (and in a good case should) be similar, but for most OS projects I see them very different - just for the fact that packages in distro’s lag behind the development in years.
So, I've gone to my friendly operator IRC channel of reference and asked what general opinions are. I have received the following input: - yes, people sometimes install project-provided binaries - if they do, they want a repository, not packages -- so updates actually work. - people make their own repositories with their own modified/custom packages if they need to - people actually convert .deb into other things that fit their distro That said, the distro's package is still the first source.
My believe is to have our own packages up (like many other packages do) and merge in as much as we can/agree from future distro packages.
The only thing /possible/ at this point, IMHO, is a generic package that doesn't target any specific distro. This is simply a logical conclusion because we have no idea how exactly a distribution package for a particular distro and version will look like, which means we can't be compatible with it, which means we can't use the same name (because that would create random conflicts when updating distro<->ours), which means we need to ensure isolation to avoid f*cking up user's installations. We can put up our own more-recent packages as soon as a distro has packages for FRR -- or as soon as we know that there won't be such a package for the foreseeable future. The latter is really not the expected case for FRR. So, no, I don't think we shouldn't have our own packages for distros up right now. We should talk to distros, figure out what their package will look like so it's acceptable to their rules, and then we can publish automatically-updated most-recent packages on our own with the same semantics in our own repo. [snip]
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?
The latter, because the distro doesn't package "our" pieces, they create packages according to their own guidelines and rules. It's a huge problem if we distribute packages with the same name, but differing conventions. In fact, if we have packaging scripts in our repo, we should pull in the distro's changes.
Note Debian explicitly recommends *against* having /debian in a release tarball, cf. https://wiki.debian.org/UpstreamGuide#Pristine_Upstream_Source Note that they explicitly distinguish git vs. tarball, and we actually are in "compliance" with that since our debian/ dir is not listed in Makefile.am. I would argue the same for redhat/.
First of all, we don’t have debian package infrastructure yet. We have a start of it as a work-in-progress PR by Silas.
No, we don't have anything, because AFAIK we haven't gotten a Debian maintainer to take up FRR and claim responsibility for it, and start working on it. It doesn't matter what Silas has or what we have in git. What matters is what shows up on: https://packages.debian.org/search?searchon=contents&keywords=frr&mode=path&... ... which is nothing.
From my discussion with Debian maintainers, the main issue is that their build system is using “debian” as a subdirectory during the building of packages and the issue is because of this (they need to delete it or merge it or something else and it causes extra work)
Our debian/ directory is not contained in our dist tarballs.
Some of them prefer the debian part in separate git which I don’t like because of the painful version dependency hacks to match one debian script dir with a specific frr git. An acceptable workaround (as confirmed by multiple debian folks) is to call the directory anything else - i.e. “debianpkg”. This could then be part of the release tarball with no issues.
Redhat has no such issues as there is no reserved “redhat” directory name. So I see no problem to have this part of the release tar ball.
You are arguing "why some things we could do are not a problem". But the question here is "what can we do to get packages in distros". If you ask that question to a Debian maintainer, and they tell you "having a debianpkg/ directory in your repo would help us", THEN I will accept your argument. But even then I will ask you (or the maintainers) "what priority is that?" ... and I'm pretty sure first priority is actually talking to them asking them what /helps/ them.
1. put up a README for the distro maintainers on what we're planning to do. IMHO, it needs to say 2 things:
(a) we're moving towards integrated config; right now we're trying to detect and adapt, but at some point this may change. (b) watchfrr may be becoming more important for multi-instance management so we can start ospf #5 on a "router ospf 5"
If we have things we need agreement on here - please start a new thread.
I see this as a different PR and welcome anyone trying to do this.
There's a dependency chain here. We need this README ASAP, before distros package things differently out of sheer unawareness of our future plans. And the distro packages are a dependency for /our/ high-quality packages. And at that point this discussion we're having here is obsolete, because it'll be obvious what works with the distros. So... I'm still seeing bikeshedding here.
2. wait, talk, wait, and talk to the distros. They'll make FRR packages by copying their Quagga build descriptions. If we have good READMEs and talk to them nicely, we can influence this. If we sit on our asses - or try to dictate what they should do - they'll do what they think is best while ignoring our plans.
So... I think we're deep in bikeshedding land here. The PR with the RedHat changes doesn't matter, because whoever picks up FRR at RedHat is gonna run it over with a lawnmower anyway. Neither do our attempts to unify FRR across distros - they will get the lawnmower too.
It matters for multiple folks: - Various SDN/Whitebox distros (ODL, OpenSwitch etc) which build based on OUR package directories (no, they are NOT ignoring them unless they need to fix/change them)
... and which they will customize to fit their own needs. I'm not accepting this one.
- My CI system which uses them for testing - The users which currently use my broken frr-test packages from the CI
I worry more about the 99% of users who simply don't see any FRR package at all, because we're _not_in_their_distro_.
- Users which come directly to us to look for up-to-date packages
Which we can't address currently because such users would (rightfully) expect that they can update to our packages/repo from their distro - and back. And we can't do that because we don't even know what we should be compatible with.
To be even more explicit, I am in strong disfavor of even discussing this in yet another meeting (weekly, maintainers or TSC). It's simply not productive. We don't need a decision, because we already went down the wrong path earlier and are now deciding whether we want our highway to nowhere with 4 or 6 lanes.
So you are proposing to NOT provide any packages for specific Distros?
Yes. All of them right now, really. If you really want packages up right now, I would make a generic .deb and a generic .rpm. I would NOT call them Debian, Ubuntu, RedHat, CentOS or anything - in fact I would explicitly label them as "generic/no distro". But that's still a secondary priority after talking to the f*cking distros and asking them what we can do to help them get our packages in. And just to be explicit - doing random packaging work without asking them isn't "helping them". Helping people is asking them what you can do for them, and then doing that. -David
On Tue, May 23, 2017 at 05:00:15PM +0200, David Lamparter wrote:
On Mon, May 22, 2017 at 02:18:55PM -0700, Martin Winter wrote:
I see this as a different PR and welcome anyone trying to do this.
I've created https://github.com/FRRouting/frr/wiki/Distro-&-Packaging-README-FAQ and would appreciate if people could look at it, provide feedback, and also *edit* it to add things. (Don't poke me for additions, just do them.) [related discussion (if needed) => Slack] -David
participants (4)
-
David Lamparter -
Donald Sharp -
Jafar Al-Gharaibeh -
Martin Winter