[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