Donald, thanks for your detailed answer. I see your point. The SONiC changes that I’m talking about are (currently) exclusively related to building-options, daemon configs and default features (fpm), very simple stuff. We are relying on frr's current debian packaging to build our binaries (dpkg-build), but we are replacing certain files by our owns. As far as i can tell, this pretty much mimics the rationale of your existing ‘cumulus' folder, but if you are already thinking about moving that content away by creating a more abstracted building-strategy, then i see no value in creating a SONiC-specific folder now. I’ll keep an eye on the work done in this particular area to make sure we address our concerns later on. /Rodny
On Apr 20, 2017, at 6:22 PM, Donald Sharp <sharpd@cumulusnetworks.com> wrote:
Rodny -
So I'm going to be speaking from both my position as a Cumulus Employee as well a Maintainer of FRR.
The original goal of the cumulus directory( from my perspective ) was to allow a gentle transition from a cumulus based debian package system to a reference debian packaging system. Pretty much everything in the cumulus directory can eventually be moved( I hope! ) to a more appropriate place in the tree.
Eventual goals: one debian packaging system for multiple shipping platforms ( 12.04/14.04/16.04 ) one redhat packaging system for multiple shipping platforms ...
Goals in discussion(See Martin' PR https://github.com/FRRouting/frr/pull/378 for discussion ): A unified experience using FRR on both our reference platforms (redhat and debian). Code maintainability. Every time we add a new protocol, change an existing cli, tweak behavior( ala what we are thinking about making watchfrr becoming smarter) that we don't have to find all the different places we have to touch stuff. We as a group are already having issues remembering all the different places we need to touch when we change something, so let's make it easy on ourselves.
I am going to predict now that the goals in discussion are going to end up as one of the first TSC agenda items.
So we have additionally the HAVE_CUMULUS -> I want to move this out from HAVE_CUMULUS to a more generic config options. See the data center work that David did in the past few weeks for defaults. I want to expand this from a HAVE_CUMULUS to a HAVE_DATACENTER as the check for the Data center. I believe with some careful thought we can get the behavior we want by removing the cumulus specific bits to a more generic options.
So let's circle back around to the question at hand. Can we put SONiC specific stuff into the repo? Yes, but I would like to have a plan to think about the problem from a bigger perspective and how we can make what changes are made to be useful to more than just SONiC.
donald
On Thu, Apr 20, 2017 at 8:48 PM, Rodny Molina <rodnymolina@gmail.com> wrote:
Hi folks,
Wondering if there’s any policy in regards to the location in which we should place building/config/default files corresponding to specific platform/os? I see that there’s already a ‘cumulus’ folder containing this kind of stuff.
Can we go ahead and do something equivalent for SONiC? At this point I’ve pushed this info to SONiC repos (e.g. enable ‘fpm’, default /etc/ values, etc), but i’m pondering the possibility of pushing this info to frr repo to prevent inconsistencies on either side breaking the build. What’s your take on this?
Thanks.
/Rodny _______________________________________________ dev mailing list dev@lists.frrouting.org https://lists.frrouting.org/listinfo/dev