[dev] per-platform/os defaults

Rodny Molina rodnymolina at gmail.com
Fri Apr 21 03:11:29 EDT 2017


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 at 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 at 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 at lists.frrouting.org
>> https://lists.frrouting.org/listinfo/dev




More information about the dev mailing list