Make Default subnet in pkg/cninetwork/cni_network.go configurable

[protonjhow]

Expected Behaviour

Option to choose the cni_network prefix that is persistent across restarts of the faasd stack.

Current Behaviour

Right now 10.62.0.0/16 is harcoded in pkg/cninetwork/cni_network.go and the code generates and deploys this into /etc/cni/net.d/10-openfaas.conflist on faasd startup. Editing this file manually is replaced by faasd on next execution.

Are you a GitHub Sponsor (Yes/No?)

• Yes
• No

List all Possible Solutions

It seems like this is something that can be exposed to the user with an /etc/default/faasd or /etc/sysconfig/faasd file hosting the setting, and then pulling that into the faasd binary on startup as an env var or somesuch within the systemd unit file.

List the one solution that you would recommend

Environment Vars with defaults from install in the sysconfig/defaults file

Context

This hardcoded range overlaps with an area of my network where I would actually like to consume this, which causes simple networking issues with traffic blackholing. I can (and have had to) do NAT in the middle, but this introduces complexity without benefit.

Having spent some time around Lambda etc I'm a big fan of the approach, and in a very customised network automation setting my options boil down to building something on top of a framework like FastAPI, or utilise something like FaaS. My attention is on the code that does something, not the glue around it.

Right now i'm in a PoC phase where I do a bake off between the two approaches, evaluating things like ease of use, integration and developer experience. I have at least one but hopefully up to three developers to contribute at least 40% time to open source projects.

Whilst we operate Kubernetes in our business, this would sit in a corner of our network and rolling even a Minikube is probably overkill for this. That's why faasd is very interesting to me.

The limitation I have is that overlap with my existing lab subnet, which is just unfortunate I guess. That said, I expect RFC1918 is extremely crowded, and this is why a lot of people use CGNAT space (100.64.0.0/10) for cloud and Kubernetes internal ranges nowadays.

On what I saw so far, making it user configurable should be possible.

Your Environment

• OS and architecture:
• Versions:

go version
go not installed on host

containerd -version
containerd github.com/containerd/containerd v1.5.4 69107e47a62e1d690afa2b9b1d43f8ece3ff4483

uname -a
Linux my.lab.host 3.10.0-1127.13.1.el7.x86_64 #1 SMP Tue Jun 23 15:46:38 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

cat /etc/os-release
NAME="CentOS Linux"
VERSION="7 (Core)"
ID="centos"
ID_LIKE="rhel fedora"
VERSION_ID="7"
PRETTY_NAME="CentOS Linux 7 (Core)"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:centos:centos:7"
HOME_URL="https://www.centos.org/"
BUG_REPORT_URL="https://bugs.centos.org/"

CENTOS_MANTISBT_PROJECT="CentOS-7"
CENTOS_MANTISBT_PROJECT_VERSION="7"
REDHAT_SUPPORT_PRODUCT="centos"
REDHAT_SUPPORT_PRODUCT_VERSION="7"

faasd version
  __                     _
 / _| __ _  __ _ ___  __| |
| |_ / _` |/ _` / __|/ _` |
|  _| (_| | (_| \__ \ (_| |
|_|  \__,_|\__,_|___/\__,_|

faasd version: 0.15.0-rc3	commit: 4b132315c7ed5e125a524f87aaeb76a603f79110

[alexellis]

Hi @protonjhow please take a moment to fill out the whole issue template, not just the fields that you decided you wanted to fill out.

Then once we have that, we'll review this on the weekly community call, feel free to attend and provide more context about why this is important to you, and whether it's for your personal or commercial consumption.

Alex

[protonjhow]

Hi @alexellis,

Please accept my sincere apologies for my brevity. Hopefully this provides you more context.

I have a clash during your office hours call, but I will see if I can jiggle things around and drop in to answer any additional questions, and understand what support we can offer.

John

[protonjhow]

FYI i'm using CentOS7 on this host, but production uses Rocky8.5. It feels like that is not hugely relevant to his discussion however.