Replace entrypoint script with initcontainers (#718)
* build: install the multus binary in an init container
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: generate kubeconfig via go
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: generate multus cni configuration via golang
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: provide a docker img for daemon based deployments
We will have 2 different images (only on amd64 archs):
- legacy entrypoint script based
- daemonized process
The `image-build` docker action is updated, to build these 2 images.
There will be 2 different deployment specs, along with e2e test
lanes, one for each of the aforementioned alternatives.
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: delegate CNI config watch loop via golang
For the thick-plugin alternative, provide the watch loop for
configuration regeneration via a golang binary.
Over time, this binary is expected to run the control loop to watch
out for pod updates.
To enable current multus users to chose when they upgrade to this new
deployment setup, these changes are provided in separate multus images,
having a different yaml spec files. Both of these alternatives are
tested e2e, since a new lane is introduced.
The following libraries are introduced, along with the motivation for
adding them:
- dproxy: allows traversing the default network configuration arbitrarily,
similar to what an X path / JSON path tool provides.
Repo is available at [0].
- fsnotify: watch for changes in the default CNI configuration file.
Repo is available at [1].
The config map providing the default network CNI configuration is not
copied over, since originally, the user was not required to install a
default network CNI plugin first, but, nowadays, this is a required
step of multus.
As such, it is no longer required to provide a default CNI
configuration.
[0] - https://github.com/koron/go-dproxy
[1] - https://github.com/fsnotify/fsnotify
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* run gofmt
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* refactor: make the builder pattern more idiomatic to golang
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: update github actions to release new imgs
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
2021-10-27 12:42:37 +00:00
// Copyright (c) 2021 Multus Authors
//
// Licensed under the Apache License, Version 2.0 (the "License");
// you may not use this file except in compliance with the License.
// You may obtain a copy of the License at
//
// http://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.
//
2022-06-20 15:58:24 +00:00
// This binary works as a server that receives requests from multus-shim
// CNI plugin and creates network interface for kubernets pods.
Replace entrypoint script with initcontainers (#718)
* build: install the multus binary in an init container
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: generate kubeconfig via go
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: generate multus cni configuration via golang
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: provide a docker img for daemon based deployments
We will have 2 different images (only on amd64 archs):
- legacy entrypoint script based
- daemonized process
The `image-build` docker action is updated, to build these 2 images.
There will be 2 different deployment specs, along with e2e test
lanes, one for each of the aforementioned alternatives.
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: delegate CNI config watch loop via golang
For the thick-plugin alternative, provide the watch loop for
configuration regeneration via a golang binary.
Over time, this binary is expected to run the control loop to watch
out for pod updates.
To enable current multus users to chose when they upgrade to this new
deployment setup, these changes are provided in separate multus images,
having a different yaml spec files. Both of these alternatives are
tested e2e, since a new lane is introduced.
The following libraries are introduced, along with the motivation for
adding them:
- dproxy: allows traversing the default network configuration arbitrarily,
similar to what an X path / JSON path tool provides.
Repo is available at [0].
- fsnotify: watch for changes in the default CNI configuration file.
Repo is available at [1].
The config map providing the default network CNI configuration is not
copied over, since originally, the user was not required to install a
default network CNI plugin first, but, nowadays, this is a required
step of multus.
As such, it is no longer required to provide a default CNI
configuration.
[0] - https://github.com/koron/go-dproxy
[1] - https://github.com/fsnotify/fsnotify
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* run gofmt
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* refactor: make the builder pattern more idiomatic to golang
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: update github actions to release new imgs
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
2021-10-27 12:42:37 +00:00
package main
import (
"flag"
"fmt"
"io"
2022-06-02 09:20:38 +00:00
"net/http"
Replace entrypoint script with initcontainers (#718)
* build: install the multus binary in an init container
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: generate kubeconfig via go
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: generate multus cni configuration via golang
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: provide a docker img for daemon based deployments
We will have 2 different images (only on amd64 archs):
- legacy entrypoint script based
- daemonized process
The `image-build` docker action is updated, to build these 2 images.
There will be 2 different deployment specs, along with e2e test
lanes, one for each of the aforementioned alternatives.
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: delegate CNI config watch loop via golang
For the thick-plugin alternative, provide the watch loop for
configuration regeneration via a golang binary.
Over time, this binary is expected to run the control loop to watch
out for pod updates.
To enable current multus users to chose when they upgrade to this new
deployment setup, these changes are provided in separate multus images,
having a different yaml spec files. Both of these alternatives are
tested e2e, since a new lane is introduced.
The following libraries are introduced, along with the motivation for
adding them:
- dproxy: allows traversing the default network configuration arbitrarily,
similar to what an X path / JSON path tool provides.
Repo is available at [0].
- fsnotify: watch for changes in the default CNI configuration file.
Repo is available at [1].
The config map providing the default network CNI configuration is not
copied over, since originally, the user was not required to install a
default network CNI plugin first, but, nowadays, this is a required
step of multus.
As such, it is no longer required to provide a default CNI
configuration.
[0] - https://github.com/koron/go-dproxy
[1] - https://github.com/fsnotify/fsnotify
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* run gofmt
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* refactor: make the builder pattern more idiomatic to golang
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: update github actions to release new imgs
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
2021-10-27 12:42:37 +00:00
"os"
2022-03-04 07:33:46 +00:00
"os/user"
Replace entrypoint script with initcontainers (#718)
* build: install the multus binary in an init container
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: generate kubeconfig via go
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: generate multus cni configuration via golang
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: provide a docker img for daemon based deployments
We will have 2 different images (only on amd64 archs):
- legacy entrypoint script based
- daemonized process
The `image-build` docker action is updated, to build these 2 images.
There will be 2 different deployment specs, along with e2e test
lanes, one for each of the aforementioned alternatives.
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: delegate CNI config watch loop via golang
For the thick-plugin alternative, provide the watch loop for
configuration regeneration via a golang binary.
Over time, this binary is expected to run the control loop to watch
out for pod updates.
To enable current multus users to chose when they upgrade to this new
deployment setup, these changes are provided in separate multus images,
having a different yaml spec files. Both of these alternatives are
tested e2e, since a new lane is introduced.
The following libraries are introduced, along with the motivation for
adding them:
- dproxy: allows traversing the default network configuration arbitrarily,
similar to what an X path / JSON path tool provides.
Repo is available at [0].
- fsnotify: watch for changes in the default CNI configuration file.
Repo is available at [1].
The config map providing the default network CNI configuration is not
copied over, since originally, the user was not required to install a
default network CNI plugin first, but, nowadays, this is a required
step of multus.
As such, it is no longer required to provide a default CNI
configuration.
[0] - https://github.com/koron/go-dproxy
[1] - https://github.com/fsnotify/fsnotify
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* run gofmt
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* refactor: make the builder pattern more idiomatic to golang
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: update github actions to release new imgs
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
2021-10-27 12:42:37 +00:00
"path/filepath"
thick-plugin: refactor multus
Multus is refactored as a thick plugin, featuring 2 main components:
- a server listening to a unix domain socket, running in a pod
- a shim, a binary on the host that will send JSON requests built from
its environment / stdin values to the aforementioned server.
The pod where the multus daemon is running must share the host's PID
namespace.
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
react to maintainers review
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
thick, deployment: update the daemonset spec
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
thick, config: validate the cni config passed by the runtime
Without this patch, we're blindly trusting anything sent by the server.
This way, we assure the requests arriving at the multus controller are
valid before hand.
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
thick: model client / server config
Also add a new command line parameter on the multus controller, pointing
it to the server configuration.
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
SQUASH candidate, thick, config: cleanup the configuration
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
multus: use args.args instead of an env variable
CNI is already filling the args structure; we should consume that
rather than rely on the environment variables.
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
unit tests: remove weird tests that check an impossible scenario
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
docs, thick: document the thick plugin variant
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
thick, server, multus: re-use common types
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
2021-12-16 17:18:35 +00:00
utilruntime "k8s.io/apimachinery/pkg/util/runtime"
utilwait "k8s.io/apimachinery/pkg/util/wait"
Replace entrypoint script with initcontainers (#718)
* build: install the multus binary in an init container
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: generate kubeconfig via go
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: generate multus cni configuration via golang
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: provide a docker img for daemon based deployments
We will have 2 different images (only on amd64 archs):
- legacy entrypoint script based
- daemonized process
The `image-build` docker action is updated, to build these 2 images.
There will be 2 different deployment specs, along with e2e test
lanes, one for each of the aforementioned alternatives.
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: delegate CNI config watch loop via golang
For the thick-plugin alternative, provide the watch loop for
configuration regeneration via a golang binary.
Over time, this binary is expected to run the control loop to watch
out for pod updates.
To enable current multus users to chose when they upgrade to this new
deployment setup, these changes are provided in separate multus images,
having a different yaml spec files. Both of these alternatives are
tested e2e, since a new lane is introduced.
The following libraries are introduced, along with the motivation for
adding them:
- dproxy: allows traversing the default network configuration arbitrarily,
similar to what an X path / JSON path tool provides.
Repo is available at [0].
- fsnotify: watch for changes in the default CNI configuration file.
Repo is available at [1].
The config map providing the default network CNI configuration is not
copied over, since originally, the user was not required to install a
default network CNI plugin first, but, nowadays, this is a required
step of multus.
As such, it is no longer required to provide a default CNI
configuration.
[0] - https://github.com/koron/go-dproxy
[1] - https://github.com/fsnotify/fsnotify
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* run gofmt
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* refactor: make the builder pattern more idiomatic to golang
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: update github actions to release new imgs
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
2021-10-27 12:42:37 +00:00
"gopkg.in/k8snetworkplumbingwg/multus-cni.v3/pkg/logging"
2022-02-22 08:15:12 +00:00
srv "gopkg.in/k8snetworkplumbingwg/multus-cni.v3/pkg/server"
2022-03-22 17:36:34 +00:00
"gopkg.in/k8snetworkplumbingwg/multus-cni.v3/pkg/server/config"
thick-plugin: refactor multus
Multus is refactored as a thick plugin, featuring 2 main components:
- a server listening to a unix domain socket, running in a pod
- a shim, a binary on the host that will send JSON requests built from
its environment / stdin values to the aforementioned server.
The pod where the multus daemon is running must share the host's PID
namespace.
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
react to maintainers review
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
thick, deployment: update the daemonset spec
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
thick, config: validate the cni config passed by the runtime
Without this patch, we're blindly trusting anything sent by the server.
This way, we assure the requests arriving at the multus controller are
valid before hand.
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
thick: model client / server config
Also add a new command line parameter on the multus controller, pointing
it to the server configuration.
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
SQUASH candidate, thick, config: cleanup the configuration
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
multus: use args.args instead of an env variable
CNI is already filling the args structure; we should consume that
rather than rely on the environment variables.
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
unit tests: remove weird tests that check an impossible scenario
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
docs, thick: document the thick plugin variant
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
thick, server, multus: re-use common types
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
2021-12-16 17:18:35 +00:00
"gopkg.in/k8snetworkplumbingwg/multus-cni.v3/pkg/types"
2022-06-02 09:20:38 +00:00
"github.com/prometheus/client_golang/prometheus/promhttp"
Replace entrypoint script with initcontainers (#718)
* build: install the multus binary in an init container
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: generate kubeconfig via go
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: generate multus cni configuration via golang
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: provide a docker img for daemon based deployments
We will have 2 different images (only on amd64 archs):
- legacy entrypoint script based
- daemonized process
The `image-build` docker action is updated, to build these 2 images.
There will be 2 different deployment specs, along with e2e test
lanes, one for each of the aforementioned alternatives.
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: delegate CNI config watch loop via golang
For the thick-plugin alternative, provide the watch loop for
configuration regeneration via a golang binary.
Over time, this binary is expected to run the control loop to watch
out for pod updates.
To enable current multus users to chose when they upgrade to this new
deployment setup, these changes are provided in separate multus images,
having a different yaml spec files. Both of these alternatives are
tested e2e, since a new lane is introduced.
The following libraries are introduced, along with the motivation for
adding them:
- dproxy: allows traversing the default network configuration arbitrarily,
similar to what an X path / JSON path tool provides.
Repo is available at [0].
- fsnotify: watch for changes in the default CNI configuration file.
Repo is available at [1].
The config map providing the default network CNI configuration is not
copied over, since originally, the user was not required to install a
default network CNI plugin first, but, nowadays, this is a required
step of multus.
As such, it is no longer required to provide a default CNI
configuration.
[0] - https://github.com/koron/go-dproxy
[1] - https://github.com/fsnotify/fsnotify
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* run gofmt
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* refactor: make the builder pattern more idiomatic to golang
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: update github actions to release new imgs
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
2021-10-27 12:42:37 +00:00
)
const (
2022-03-22 17:36:34 +00:00
multusPluginName = "multus-shim"
Replace entrypoint script with initcontainers (#718)
* build: install the multus binary in an init container
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: generate kubeconfig via go
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: generate multus cni configuration via golang
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: provide a docker img for daemon based deployments
We will have 2 different images (only on amd64 archs):
- legacy entrypoint script based
- daemonized process
The `image-build` docker action is updated, to build these 2 images.
There will be 2 different deployment specs, along with e2e test
lanes, one for each of the aforementioned alternatives.
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: delegate CNI config watch loop via golang
For the thick-plugin alternative, provide the watch loop for
configuration regeneration via a golang binary.
Over time, this binary is expected to run the control loop to watch
out for pod updates.
To enable current multus users to chose when they upgrade to this new
deployment setup, these changes are provided in separate multus images,
having a different yaml spec files. Both of these alternatives are
tested e2e, since a new lane is introduced.
The following libraries are introduced, along with the motivation for
adding them:
- dproxy: allows traversing the default network configuration arbitrarily,
similar to what an X path / JSON path tool provides.
Repo is available at [0].
- fsnotify: watch for changes in the default CNI configuration file.
Repo is available at [1].
The config map providing the default network CNI configuration is not
copied over, since originally, the user was not required to install a
default network CNI plugin first, but, nowadays, this is a required
step of multus.
As such, it is no longer required to provide a default CNI
configuration.
[0] - https://github.com/koron/go-dproxy
[1] - https://github.com/fsnotify/fsnotify
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* run gofmt
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* refactor: make the builder pattern more idiomatic to golang
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: update github actions to release new imgs
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
2021-10-27 12:42:37 +00:00
)
const (
defaultCniConfigDir = "/etc/cni/net.d"
defaultMultusGlobalNamespaces = ""
defaultMultusLogFile = ""
2022-04-11 15:22:48 +00:00
defaultMultusLogMaxSize = 100 // megabytes
defaultMultusLogMaxAge = 5 // days
defaultMultusLogMaxBackups = 5
defaultMultusLogCompress = true
Replace entrypoint script with initcontainers (#718)
* build: install the multus binary in an init container
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: generate kubeconfig via go
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: generate multus cni configuration via golang
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: provide a docker img for daemon based deployments
We will have 2 different images (only on amd64 archs):
- legacy entrypoint script based
- daemonized process
The `image-build` docker action is updated, to build these 2 images.
There will be 2 different deployment specs, along with e2e test
lanes, one for each of the aforementioned alternatives.
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: delegate CNI config watch loop via golang
For the thick-plugin alternative, provide the watch loop for
configuration regeneration via a golang binary.
Over time, this binary is expected to run the control loop to watch
out for pod updates.
To enable current multus users to chose when they upgrade to this new
deployment setup, these changes are provided in separate multus images,
having a different yaml spec files. Both of these alternatives are
tested e2e, since a new lane is introduced.
The following libraries are introduced, along with the motivation for
adding them:
- dproxy: allows traversing the default network configuration arbitrarily,
similar to what an X path / JSON path tool provides.
Repo is available at [0].
- fsnotify: watch for changes in the default CNI configuration file.
Repo is available at [1].
The config map providing the default network CNI configuration is not
copied over, since originally, the user was not required to install a
default network CNI plugin first, but, nowadays, this is a required
step of multus.
As such, it is no longer required to provide a default CNI
configuration.
[0] - https://github.com/koron/go-dproxy
[1] - https://github.com/fsnotify/fsnotify
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* run gofmt
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* refactor: make the builder pattern more idiomatic to golang
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: update github actions to release new imgs
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
2021-10-27 12:42:37 +00:00
defaultMultusLogLevel = ""
defaultMultusLogToStdErr = false
defaultMultusMasterCNIFile = ""
defaultMultusNamespaceIsolation = false
defaultMultusReadinessIndicatorFile = ""
)
const (
2022-03-22 17:36:34 +00:00
cniConfigDirVarName = "cni-config-dir"
multusAutoconfigDirVarName = "multus-autoconfig-dir"
multusCNIVersion = "cni-version"
multusConfigFileVarName = "multus-conf-file"
multusGlobalNamespaces = "global-namespaces"
multusLogFile = "multus-log-file"
2022-04-12 10:19:49 +00:00
multusLogMaxSize = "multus-log-max-size"
multusLogMaxAge = "multus-log-max-age"
multusLogMaxBackups = "multus-log-max-backups"
multusLogCompress = "multus-log-compress"
2022-03-22 17:36:34 +00:00
multusLogLevel = "multus-log-level"
multusLogToStdErr = "multus-log-to-stderr"
multusMasterCNIFileVarName = "multus-master-cni-file"
multusNamespaceIsolation = "namespace-isolation"
multusReadinessIndicatorFile = "readiness-indicator-file"
Replace entrypoint script with initcontainers (#718)
* build: install the multus binary in an init container
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: generate kubeconfig via go
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: generate multus cni configuration via golang
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: provide a docker img for daemon based deployments
We will have 2 different images (only on amd64 archs):
- legacy entrypoint script based
- daemonized process
The `image-build` docker action is updated, to build these 2 images.
There will be 2 different deployment specs, along with e2e test
lanes, one for each of the aforementioned alternatives.
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: delegate CNI config watch loop via golang
For the thick-plugin alternative, provide the watch loop for
configuration regeneration via a golang binary.
Over time, this binary is expected to run the control loop to watch
out for pod updates.
To enable current multus users to chose when they upgrade to this new
deployment setup, these changes are provided in separate multus images,
having a different yaml spec files. Both of these alternatives are
tested e2e, since a new lane is introduced.
The following libraries are introduced, along with the motivation for
adding them:
- dproxy: allows traversing the default network configuration arbitrarily,
similar to what an X path / JSON path tool provides.
Repo is available at [0].
- fsnotify: watch for changes in the default CNI configuration file.
Repo is available at [1].
The config map providing the default network CNI configuration is not
copied over, since originally, the user was not required to install a
default network CNI plugin first, but, nowadays, this is a required
step of multus.
As such, it is no longer required to provide a default CNI
configuration.
[0] - https://github.com/koron/go-dproxy
[1] - https://github.com/fsnotify/fsnotify
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* run gofmt
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* refactor: make the builder pattern more idiomatic to golang
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: update github actions to release new imgs
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
2021-10-27 12:42:37 +00:00
)
func main ( ) {
flag . CommandLine = flag . NewFlagSet ( os . Args [ 0 ] , flag . ExitOnError )
cniConfigDir := flag . String ( cniConfigDirVarName , defaultCniConfigDir , "CNI config dir" )
2022-03-04 07:33:46 +00:00
multusConfigFile := flag . String ( multusConfigFileVarName , "auto" , "The multus configuration file to use. By default, a new configuration is generated." )
multusMasterCni := flag . String ( multusMasterCNIFileVarName , "" , "The relative name of the configuration file of the cluster primary CNI." )
Replace entrypoint script with initcontainers (#718)
* build: install the multus binary in an init container
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: generate kubeconfig via go
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: generate multus cni configuration via golang
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: provide a docker img for daemon based deployments
We will have 2 different images (only on amd64 archs):
- legacy entrypoint script based
- daemonized process
The `image-build` docker action is updated, to build these 2 images.
There will be 2 different deployment specs, along with e2e test
lanes, one for each of the aforementioned alternatives.
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: delegate CNI config watch loop via golang
For the thick-plugin alternative, provide the watch loop for
configuration regeneration via a golang binary.
Over time, this binary is expected to run the control loop to watch
out for pod updates.
To enable current multus users to chose when they upgrade to this new
deployment setup, these changes are provided in separate multus images,
having a different yaml spec files. Both of these alternatives are
tested e2e, since a new lane is introduced.
The following libraries are introduced, along with the motivation for
adding them:
- dproxy: allows traversing the default network configuration arbitrarily,
similar to what an X path / JSON path tool provides.
Repo is available at [0].
- fsnotify: watch for changes in the default CNI configuration file.
Repo is available at [1].
The config map providing the default network CNI configuration is not
copied over, since originally, the user was not required to install a
default network CNI plugin first, but, nowadays, this is a required
step of multus.
As such, it is no longer required to provide a default CNI
configuration.
[0] - https://github.com/koron/go-dproxy
[1] - https://github.com/fsnotify/fsnotify
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* run gofmt
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* refactor: make the builder pattern more idiomatic to golang
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: update github actions to release new imgs
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
2021-10-27 12:42:37 +00:00
multusAutoconfigDir := flag . String ( multusAutoconfigDirVarName , * cniConfigDir , "The directory path for the generated multus configuration." )
2022-03-04 07:33:46 +00:00
namespaceIsolation := flag . Bool ( multusNamespaceIsolation , false , "If the network resources are only available within their defined namespaces." )
globalNamespaces := flag . String ( multusGlobalNamespaces , "" , "Comma-separated list of namespaces which can be referred to globally when namespace isolation is enabled." )
logToStdErr := flag . Bool ( multusLogToStdErr , false , "If the multus logs are also to be echoed to stderr." )
logLevel := flag . String ( multusLogLevel , "" , "One of: debug/verbose/error/panic. Used only with --multus-conf-file=auto." )
logFile := flag . String ( multusLogFile , "" , "Path where to multus will log. Used only with --multus-conf-file=auto." )
2022-04-11 15:22:48 +00:00
logMaxSize := flag . Int ( multusLogMaxSize , defaultMultusLogMaxSize , "the maximum size in megabytes of the log file before it gets rotated" )
logMaxAge := flag . Int ( multusLogMaxAge , defaultMultusLogMaxAge , "the maximum number of days to retain old log files in their filename" )
logMaxBackups := flag . Int ( multusLogMaxBackups , defaultMultusLogMaxBackups , "the maximum number of old log files to retain" )
logCompress := flag . Bool ( multusLogCompress , defaultMultusLogCompress , "compress determines if the rotated log files should be compressed using gzip" )
2022-03-04 07:33:46 +00:00
cniVersion := flag . String ( multusCNIVersion , "" , "Allows you to specify CNI spec version. Used only with --multus-conf-file=auto." )
forceCNIVersion := flag . Bool ( "force-cni-version" , false , "force to use given CNI version. only for kind-e2e testing" ) // this is only for kind-e2e
readinessIndicator := flag . String ( multusReadinessIndicatorFile , "" , "Which file should be used as the readiness indicator. Used only with --multus-conf-file=auto." )
2022-03-04 07:01:21 +00:00
overrideNetworkName := flag . Bool ( "override-network-name" , false , "Used when we need overrides the name of the multus configuration with the name of the delegated primary CNI" )
thick-plugin: refactor multus
Multus is refactored as a thick plugin, featuring 2 main components:
- a server listening to a unix domain socket, running in a pod
- a shim, a binary on the host that will send JSON requests built from
its environment / stdin values to the aforementioned server.
The pod where the multus daemon is running must share the host's PID
namespace.
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
react to maintainers review
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
thick, deployment: update the daemonset spec
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
thick, config: validate the cni config passed by the runtime
Without this patch, we're blindly trusting anything sent by the server.
This way, we assure the requests arriving at the multus controller are
valid before hand.
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
thick: model client / server config
Also add a new command line parameter on the multus controller, pointing
it to the server configuration.
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
SQUASH candidate, thick, config: cleanup the configuration
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
multus: use args.args instead of an env variable
CNI is already filling the args structure; we should consume that
rather than rely on the environment variables.
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
unit tests: remove weird tests that check an impossible scenario
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
docs, thick: document the thick plugin variant
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
thick, server, multus: re-use common types
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
2021-12-16 17:18:35 +00:00
configFilePath := flag . String ( "config" , types . DefaultMultusDaemonConfigFile , "Specify the path to the multus-daemon configuration" )
Replace entrypoint script with initcontainers (#718)
* build: install the multus binary in an init container
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: generate kubeconfig via go
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: generate multus cni configuration via golang
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: provide a docker img for daemon based deployments
We will have 2 different images (only on amd64 archs):
- legacy entrypoint script based
- daemonized process
The `image-build` docker action is updated, to build these 2 images.
There will be 2 different deployment specs, along with e2e test
lanes, one for each of the aforementioned alternatives.
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: delegate CNI config watch loop via golang
For the thick-plugin alternative, provide the watch loop for
configuration regeneration via a golang binary.
Over time, this binary is expected to run the control loop to watch
out for pod updates.
To enable current multus users to chose when they upgrade to this new
deployment setup, these changes are provided in separate multus images,
having a different yaml spec files. Both of these alternatives are
tested e2e, since a new lane is introduced.
The following libraries are introduced, along with the motivation for
adding them:
- dproxy: allows traversing the default network configuration arbitrarily,
similar to what an X path / JSON path tool provides.
Repo is available at [0].
- fsnotify: watch for changes in the default CNI configuration file.
Repo is available at [1].
The config map providing the default network CNI configuration is not
copied over, since originally, the user was not required to install a
default network CNI plugin first, but, nowadays, this is a required
step of multus.
As such, it is no longer required to provide a default CNI
configuration.
[0] - https://github.com/koron/go-dproxy
[1] - https://github.com/fsnotify/fsnotify
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* run gofmt
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* refactor: make the builder pattern more idiomatic to golang
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: update github actions to release new imgs
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
2021-10-27 12:42:37 +00:00
flag . Parse ( )
2022-03-22 17:36:34 +00:00
if err := startMultusDaemon ( * configFilePath ) ; err != nil {
thick-plugin: refactor multus
Multus is refactored as a thick plugin, featuring 2 main components:
- a server listening to a unix domain socket, running in a pod
- a shim, a binary on the host that will send JSON requests built from
its environment / stdin values to the aforementioned server.
The pod where the multus daemon is running must share the host's PID
namespace.
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
react to maintainers review
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
thick, deployment: update the daemonset spec
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
thick, config: validate the cni config passed by the runtime
Without this patch, we're blindly trusting anything sent by the server.
This way, we assure the requests arriving at the multus controller are
valid before hand.
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
thick: model client / server config
Also add a new command line parameter on the multus controller, pointing
it to the server configuration.
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
SQUASH candidate, thick, config: cleanup the configuration
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
multus: use args.args instead of an env variable
CNI is already filling the args structure; we should consume that
rather than rely on the environment variables.
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
unit tests: remove weird tests that check an impossible scenario
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
docs, thick: document the thick plugin variant
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
thick, server, multus: re-use common types
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
2021-12-16 17:18:35 +00:00
logging . Panicf ( "failed start the multus thick-plugin listener: %v" , err )
os . Exit ( 3 )
Replace entrypoint script with initcontainers (#718)
* build: install the multus binary in an init container
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: generate kubeconfig via go
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: generate multus cni configuration via golang
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: provide a docker img for daemon based deployments
We will have 2 different images (only on amd64 archs):
- legacy entrypoint script based
- daemonized process
The `image-build` docker action is updated, to build these 2 images.
There will be 2 different deployment specs, along with e2e test
lanes, one for each of the aforementioned alternatives.
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: delegate CNI config watch loop via golang
For the thick-plugin alternative, provide the watch loop for
configuration regeneration via a golang binary.
Over time, this binary is expected to run the control loop to watch
out for pod updates.
To enable current multus users to chose when they upgrade to this new
deployment setup, these changes are provided in separate multus images,
having a different yaml spec files. Both of these alternatives are
tested e2e, since a new lane is introduced.
The following libraries are introduced, along with the motivation for
adding them:
- dproxy: allows traversing the default network configuration arbitrarily,
similar to what an X path / JSON path tool provides.
Repo is available at [0].
- fsnotify: watch for changes in the default CNI configuration file.
Repo is available at [1].
The config map providing the default network CNI configuration is not
copied over, since originally, the user was not required to install a
default network CNI plugin first, but, nowadays, this is a required
step of multus.
As such, it is no longer required to provide a default CNI
configuration.
[0] - https://github.com/koron/go-dproxy
[1] - https://github.com/fsnotify/fsnotify
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* run gofmt
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* refactor: make the builder pattern more idiomatic to golang
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: update github actions to release new imgs
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
2021-10-27 12:42:37 +00:00
}
2022-03-04 07:33:46 +00:00
// Generate multus CNI config from current CNI config
if * multusConfigFile == "auto" {
if * cniVersion == "" {
Replace entrypoint script with initcontainers (#718)
* build: install the multus binary in an init container
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: generate kubeconfig via go
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: generate multus cni configuration via golang
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: provide a docker img for daemon based deployments
We will have 2 different images (only on amd64 archs):
- legacy entrypoint script based
- daemonized process
The `image-build` docker action is updated, to build these 2 images.
There will be 2 different deployment specs, along with e2e test
lanes, one for each of the aforementioned alternatives.
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: delegate CNI config watch loop via golang
For the thick-plugin alternative, provide the watch loop for
configuration regeneration via a golang binary.
Over time, this binary is expected to run the control loop to watch
out for pod updates.
To enable current multus users to chose when they upgrade to this new
deployment setup, these changes are provided in separate multus images,
having a different yaml spec files. Both of these alternatives are
tested e2e, since a new lane is introduced.
The following libraries are introduced, along with the motivation for
adding them:
- dproxy: allows traversing the default network configuration arbitrarily,
similar to what an X path / JSON path tool provides.
Repo is available at [0].
- fsnotify: watch for changes in the default CNI configuration file.
Repo is available at [1].
The config map providing the default network CNI configuration is not
copied over, since originally, the user was not required to install a
default network CNI plugin first, but, nowadays, this is a required
step of multus.
As such, it is no longer required to provide a default CNI
configuration.
[0] - https://github.com/koron/go-dproxy
[1] - https://github.com/fsnotify/fsnotify
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* run gofmt
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* refactor: make the builder pattern more idiomatic to golang
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: update github actions to release new imgs
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
2021-10-27 12:42:37 +00:00
_ = logging . Errorf ( "the CNI version is a mandatory parameter when the '-multus-config-file=auto' option is used" )
}
var configurationOptions [ ] config . Option
thick-plugin: refactor multus
Multus is refactored as a thick plugin, featuring 2 main components:
- a server listening to a unix domain socket, running in a pod
- a shim, a binary on the host that will send JSON requests built from
its environment / stdin values to the aforementioned server.
The pod where the multus daemon is running must share the host's PID
namespace.
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
react to maintainers review
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
thick, deployment: update the daemonset spec
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
thick, config: validate the cni config passed by the runtime
Without this patch, we're blindly trusting anything sent by the server.
This way, we assure the requests arriving at the multus controller are
valid before hand.
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
thick: model client / server config
Also add a new command line parameter on the multus controller, pointing
it to the server configuration.
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
SQUASH candidate, thick, config: cleanup the configuration
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
multus: use args.args instead of an env variable
CNI is already filling the args structure; we should consume that
rather than rely on the environment variables.
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
unit tests: remove weird tests that check an impossible scenario
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
docs, thick: document the thick plugin variant
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
thick, server, multus: re-use common types
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
2021-12-16 17:18:35 +00:00
Replace entrypoint script with initcontainers (#718)
* build: install the multus binary in an init container
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: generate kubeconfig via go
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: generate multus cni configuration via golang
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: provide a docker img for daemon based deployments
We will have 2 different images (only on amd64 archs):
- legacy entrypoint script based
- daemonized process
The `image-build` docker action is updated, to build these 2 images.
There will be 2 different deployment specs, along with e2e test
lanes, one for each of the aforementioned alternatives.
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: delegate CNI config watch loop via golang
For the thick-plugin alternative, provide the watch loop for
configuration regeneration via a golang binary.
Over time, this binary is expected to run the control loop to watch
out for pod updates.
To enable current multus users to chose when they upgrade to this new
deployment setup, these changes are provided in separate multus images,
having a different yaml spec files. Both of these alternatives are
tested e2e, since a new lane is introduced.
The following libraries are introduced, along with the motivation for
adding them:
- dproxy: allows traversing the default network configuration arbitrarily,
similar to what an X path / JSON path tool provides.
Repo is available at [0].
- fsnotify: watch for changes in the default CNI configuration file.
Repo is available at [1].
The config map providing the default network CNI configuration is not
copied over, since originally, the user was not required to install a
default network CNI plugin first, but, nowadays, this is a required
step of multus.
As such, it is no longer required to provide a default CNI
configuration.
[0] - https://github.com/koron/go-dproxy
[1] - https://github.com/fsnotify/fsnotify
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* run gofmt
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* refactor: make the builder pattern more idiomatic to golang
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: update github actions to release new imgs
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
2021-10-27 12:42:37 +00:00
if * namespaceIsolation {
configurationOptions = append (
configurationOptions , config . WithNamespaceIsolation ( ) )
}
if * globalNamespaces != defaultMultusGlobalNamespaces {
configurationOptions = append (
configurationOptions , config . WithGlobalNamespaces ( * globalNamespaces ) )
}
if * logToStdErr != defaultMultusLogToStdErr {
configurationOptions = append (
configurationOptions , config . WithLogToStdErr ( ) )
}
if * logLevel != defaultMultusLogLevel {
configurationOptions = append (
configurationOptions , config . WithLogLevel ( * logLevel ) )
}
if * logFile != defaultMultusLogFile {
configurationOptions = append (
configurationOptions , config . WithLogFile ( * logFile ) )
}
if * readinessIndicator != defaultMultusReadinessIndicatorFile {
configurationOptions = append (
configurationOptions , config . WithReadinessFileIndicator ( * readinessIndicator ) )
}
2022-02-28 13:04:23 +00:00
2022-04-11 15:22:48 +00:00
// logOptions
var logOptionFuncs [ ] config . LogOptionFunc
if * logMaxAge != defaultMultusLogMaxAge {
logOptionFuncs = append ( logOptionFuncs , config . WithLogMaxAge ( logMaxAge ) )
}
if * logMaxSize != defaultMultusLogMaxSize {
logOptionFuncs = append ( logOptionFuncs , config . WithLogMaxSize ( logMaxSize ) )
}
if * logMaxBackups != defaultMultusLogMaxBackups {
logOptionFuncs = append ( logOptionFuncs , config . WithLogMaxBackups ( logMaxBackups ) )
}
if * logCompress != defaultMultusLogCompress {
logOptionFuncs = append ( logOptionFuncs , config . WithLogCompress ( logCompress ) )
}
if len ( logOptionFuncs ) > 0 {
logOptions := & config . LogOptions { }
config . MutateLogOptions ( logOptions , logOptionFuncs ... )
configurationOptions = append ( configurationOptions , config . WithLogOptions ( logOptions ) )
}
2022-03-22 17:36:34 +00:00
multusConfig , err := config . NewMultusConfig ( multusPluginName , * cniVersion , configurationOptions ... )
2022-02-28 13:04:23 +00:00
if err != nil {
_ = logging . Errorf ( "Failed to create multus config: %v" , err )
os . Exit ( 3 )
}
Replace entrypoint script with initcontainers (#718)
* build: install the multus binary in an init container
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: generate kubeconfig via go
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: generate multus cni configuration via golang
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: provide a docker img for daemon based deployments
We will have 2 different images (only on amd64 archs):
- legacy entrypoint script based
- daemonized process
The `image-build` docker action is updated, to build these 2 images.
There will be 2 different deployment specs, along with e2e test
lanes, one for each of the aforementioned alternatives.
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: delegate CNI config watch loop via golang
For the thick-plugin alternative, provide the watch loop for
configuration regeneration via a golang binary.
Over time, this binary is expected to run the control loop to watch
out for pod updates.
To enable current multus users to chose when they upgrade to this new
deployment setup, these changes are provided in separate multus images,
having a different yaml spec files. Both of these alternatives are
tested e2e, since a new lane is introduced.
The following libraries are introduced, along with the motivation for
adding them:
- dproxy: allows traversing the default network configuration arbitrarily,
similar to what an X path / JSON path tool provides.
Repo is available at [0].
- fsnotify: watch for changes in the default CNI configuration file.
Repo is available at [1].
The config map providing the default network CNI configuration is not
copied over, since originally, the user was not required to install a
default network CNI plugin first, but, nowadays, this is a required
step of multus.
As such, it is no longer required to provide a default CNI
configuration.
[0] - https://github.com/koron/go-dproxy
[1] - https://github.com/fsnotify/fsnotify
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* run gofmt
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* refactor: make the builder pattern more idiomatic to golang
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: update github actions to release new imgs
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
2021-10-27 12:42:37 +00:00
var configManager * config . Manager
if * multusMasterCni == "" {
2022-03-04 07:33:46 +00:00
configManager , err = config . NewManager ( * multusConfig , * multusAutoconfigDir , * forceCNIVersion )
Replace entrypoint script with initcontainers (#718)
* build: install the multus binary in an init container
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: generate kubeconfig via go
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: generate multus cni configuration via golang
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: provide a docker img for daemon based deployments
We will have 2 different images (only on amd64 archs):
- legacy entrypoint script based
- daemonized process
The `image-build` docker action is updated, to build these 2 images.
There will be 2 different deployment specs, along with e2e test
lanes, one for each of the aforementioned alternatives.
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: delegate CNI config watch loop via golang
For the thick-plugin alternative, provide the watch loop for
configuration regeneration via a golang binary.
Over time, this binary is expected to run the control loop to watch
out for pod updates.
To enable current multus users to chose when they upgrade to this new
deployment setup, these changes are provided in separate multus images,
having a different yaml spec files. Both of these alternatives are
tested e2e, since a new lane is introduced.
The following libraries are introduced, along with the motivation for
adding them:
- dproxy: allows traversing the default network configuration arbitrarily,
similar to what an X path / JSON path tool provides.
Repo is available at [0].
- fsnotify: watch for changes in the default CNI configuration file.
Repo is available at [1].
The config map providing the default network CNI configuration is not
copied over, since originally, the user was not required to install a
default network CNI plugin first, but, nowadays, this is a required
step of multus.
As such, it is no longer required to provide a default CNI
configuration.
[0] - https://github.com/koron/go-dproxy
[1] - https://github.com/fsnotify/fsnotify
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* run gofmt
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* refactor: make the builder pattern more idiomatic to golang
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: update github actions to release new imgs
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
2021-10-27 12:42:37 +00:00
} else {
configManager , err = config . NewManagerWithExplicitPrimaryCNIPlugin (
2022-03-04 07:33:46 +00:00
* multusConfig , * multusAutoconfigDir , * multusMasterCni , * forceCNIVersion )
Replace entrypoint script with initcontainers (#718)
* build: install the multus binary in an init container
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: generate kubeconfig via go
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: generate multus cni configuration via golang
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: provide a docker img for daemon based deployments
We will have 2 different images (only on amd64 archs):
- legacy entrypoint script based
- daemonized process
The `image-build` docker action is updated, to build these 2 images.
There will be 2 different deployment specs, along with e2e test
lanes, one for each of the aforementioned alternatives.
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: delegate CNI config watch loop via golang
For the thick-plugin alternative, provide the watch loop for
configuration regeneration via a golang binary.
Over time, this binary is expected to run the control loop to watch
out for pod updates.
To enable current multus users to chose when they upgrade to this new
deployment setup, these changes are provided in separate multus images,
having a different yaml spec files. Both of these alternatives are
tested e2e, since a new lane is introduced.
The following libraries are introduced, along with the motivation for
adding them:
- dproxy: allows traversing the default network configuration arbitrarily,
similar to what an X path / JSON path tool provides.
Repo is available at [0].
- fsnotify: watch for changes in the default CNI configuration file.
Repo is available at [1].
The config map providing the default network CNI configuration is not
copied over, since originally, the user was not required to install a
default network CNI plugin first, but, nowadays, this is a required
step of multus.
As such, it is no longer required to provide a default CNI
configuration.
[0] - https://github.com/koron/go-dproxy
[1] - https://github.com/fsnotify/fsnotify
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* run gofmt
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* refactor: make the builder pattern more idiomatic to golang
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: update github actions to release new imgs
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
2021-10-27 12:42:37 +00:00
}
if err != nil {
_ = logging . Errorf ( "failed to create the configuration manager for the primary CNI plugin: %v" , err )
os . Exit ( 2 )
}
if * overrideNetworkName {
if err := configManager . OverrideNetworkName ( ) ; err != nil {
_ = logging . Errorf ( "could not override the network name: %v" , err )
}
}
generatedMultusConfig , err := configManager . GenerateConfig ( )
if err != nil {
_ = logging . Errorf ( "failed to generated the multus configuration: %v" , err )
}
logging . Verbosef ( "Generated MultusCNI config: %s" , generatedMultusConfig )
if err := configManager . PersistMultusConfig ( generatedMultusConfig ) ; err != nil {
_ = logging . Errorf ( "failed to persist the multus configuration: %v" , err )
}
configWatcherDoneChannel := make ( chan struct { } )
go func ( stopChannel chan struct { } , doneChannel chan struct { } ) {
defer func ( ) {
stopChannel <- struct { } { }
} ( )
2022-06-08 04:49:17 +00:00
if err := configManager . MonitorPluginConfiguration ( configWatcherDoneChannel , stopChannel ) ; err != nil {
Replace entrypoint script with initcontainers (#718)
* build: install the multus binary in an init container
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: generate kubeconfig via go
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: generate multus cni configuration via golang
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: provide a docker img for daemon based deployments
We will have 2 different images (only on amd64 archs):
- legacy entrypoint script based
- daemonized process
The `image-build` docker action is updated, to build these 2 images.
There will be 2 different deployment specs, along with e2e test
lanes, one for each of the aforementioned alternatives.
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: delegate CNI config watch loop via golang
For the thick-plugin alternative, provide the watch loop for
configuration regeneration via a golang binary.
Over time, this binary is expected to run the control loop to watch
out for pod updates.
To enable current multus users to chose when they upgrade to this new
deployment setup, these changes are provided in separate multus images,
having a different yaml spec files. Both of these alternatives are
tested e2e, since a new lane is introduced.
The following libraries are introduced, along with the motivation for
adding them:
- dproxy: allows traversing the default network configuration arbitrarily,
similar to what an X path / JSON path tool provides.
Repo is available at [0].
- fsnotify: watch for changes in the default CNI configuration file.
Repo is available at [1].
The config map providing the default network CNI configuration is not
copied over, since originally, the user was not required to install a
default network CNI plugin first, but, nowadays, this is a required
step of multus.
As such, it is no longer required to provide a default CNI
configuration.
[0] - https://github.com/koron/go-dproxy
[1] - https://github.com/fsnotify/fsnotify
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* run gofmt
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* refactor: make the builder pattern more idiomatic to golang
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: update github actions to release new imgs
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
2021-10-27 12:42:37 +00:00
_ = logging . Errorf ( "error watching file: %v" , err )
}
} ( make ( chan struct { } ) , configWatcherDoneChannel )
<- configWatcherDoneChannel
} else {
if err := copyUserProvidedConfig ( * multusConfigFile , * cniConfigDir ) ; err != nil {
logging . Errorf ( "failed to copy the user provided configuration %s: %v" , * multusConfigFile , err )
}
}
}
2022-03-22 17:36:34 +00:00
func startMultusDaemon ( configFilePath string ) error {
daemonConfig , config , err := types . LoadDaemonNetConf ( configFilePath )
if err != nil {
logging . Panicf ( "failed to load the multus-daemon configuration: %v" , err )
os . Exit ( 1 )
}
2022-03-04 07:33:46 +00:00
if user , err := user . Current ( ) ; err != nil || user . Uid != "0" {
return fmt . Errorf ( "failed to run multus-daemon with root: %v, now running in uid: %s" , err , user . Uid )
}
2022-02-22 08:15:12 +00:00
if err := srv . FilesystemPreRequirements ( daemonConfig . MultusSocketDir ) ; err != nil {
thick-plugin: refactor multus
Multus is refactored as a thick plugin, featuring 2 main components:
- a server listening to a unix domain socket, running in a pod
- a shim, a binary on the host that will send JSON requests built from
its environment / stdin values to the aforementioned server.
The pod where the multus daemon is running must share the host's PID
namespace.
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
react to maintainers review
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
thick, deployment: update the daemonset spec
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
thick, config: validate the cni config passed by the runtime
Without this patch, we're blindly trusting anything sent by the server.
This way, we assure the requests arriving at the multus controller are
valid before hand.
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
thick: model client / server config
Also add a new command line parameter on the multus controller, pointing
it to the server configuration.
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
SQUASH candidate, thick, config: cleanup the configuration
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
multus: use args.args instead of an env variable
CNI is already filling the args structure; we should consume that
rather than rely on the environment variables.
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
unit tests: remove weird tests that check an impossible scenario
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
docs, thick: document the thick plugin variant
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
thick, server, multus: re-use common types
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
2021-12-16 17:18:35 +00:00
return fmt . Errorf ( "failed to prepare the cni-socket for communicating with the shim: %w" , err )
}
2022-04-08 14:08:07 +00:00
server , err := srv . NewCNIServer ( daemonConfig , config )
thick-plugin: refactor multus
Multus is refactored as a thick plugin, featuring 2 main components:
- a server listening to a unix domain socket, running in a pod
- a shim, a binary on the host that will send JSON requests built from
its environment / stdin values to the aforementioned server.
The pod where the multus daemon is running must share the host's PID
namespace.
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
react to maintainers review
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
thick, deployment: update the daemonset spec
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
thick, config: validate the cni config passed by the runtime
Without this patch, we're blindly trusting anything sent by the server.
This way, we assure the requests arriving at the multus controller are
valid before hand.
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
thick: model client / server config
Also add a new command line parameter on the multus controller, pointing
it to the server configuration.
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
SQUASH candidate, thick, config: cleanup the configuration
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
multus: use args.args instead of an env variable
CNI is already filling the args structure; we should consume that
rather than rely on the environment variables.
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
unit tests: remove weird tests that check an impossible scenario
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
docs, thick: document the thick plugin variant
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
thick, server, multus: re-use common types
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
2021-12-16 17:18:35 +00:00
if err != nil {
return fmt . Errorf ( "failed to create the server: %v" , err )
}
2022-06-02 09:20:38 +00:00
if daemonConfig . MetricsPort != nil {
go utilwait . Forever ( func ( ) {
http . Handle ( "/metrics" , promhttp . Handler ( ) )
logging . Debugf ( "metrics port: %d" , * daemonConfig . MetricsPort )
logging . Debugf ( "metrics: %s" , http . ListenAndServe ( fmt . Sprintf ( ":%d" , * daemonConfig . MetricsPort ) , nil ) )
} , 0 )
}
2022-02-22 08:15:12 +00:00
l , err := srv . GetListener ( srv . SocketPath ( daemonConfig . MultusSocketDir ) )
thick-plugin: refactor multus
Multus is refactored as a thick plugin, featuring 2 main components:
- a server listening to a unix domain socket, running in a pod
- a shim, a binary on the host that will send JSON requests built from
its environment / stdin values to the aforementioned server.
The pod where the multus daemon is running must share the host's PID
namespace.
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
react to maintainers review
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
thick, deployment: update the daemonset spec
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
thick, config: validate the cni config passed by the runtime
Without this patch, we're blindly trusting anything sent by the server.
This way, we assure the requests arriving at the multus controller are
valid before hand.
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
thick: model client / server config
Also add a new command line parameter on the multus controller, pointing
it to the server configuration.
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
SQUASH candidate, thick, config: cleanup the configuration
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
multus: use args.args instead of an env variable
CNI is already filling the args structure; we should consume that
rather than rely on the environment variables.
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
unit tests: remove weird tests that check an impossible scenario
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
docs, thick: document the thick plugin variant
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
thick, server, multus: re-use common types
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
2021-12-16 17:18:35 +00:00
if err != nil {
2022-02-22 08:15:12 +00:00
return fmt . Errorf ( "failed to start the CNI server using socket %s. Reason: %+v" , srv . SocketPath ( daemonConfig . MultusSocketDir ) , err )
thick-plugin: refactor multus
Multus is refactored as a thick plugin, featuring 2 main components:
- a server listening to a unix domain socket, running in a pod
- a shim, a binary on the host that will send JSON requests built from
its environment / stdin values to the aforementioned server.
The pod where the multus daemon is running must share the host's PID
namespace.
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
react to maintainers review
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
thick, deployment: update the daemonset spec
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
thick, config: validate the cni config passed by the runtime
Without this patch, we're blindly trusting anything sent by the server.
This way, we assure the requests arriving at the multus controller are
valid before hand.
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
thick: model client / server config
Also add a new command line parameter on the multus controller, pointing
it to the server configuration.
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
SQUASH candidate, thick, config: cleanup the configuration
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
multus: use args.args instead of an env variable
CNI is already filling the args structure; we should consume that
rather than rely on the environment variables.
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
unit tests: remove weird tests that check an impossible scenario
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
docs, thick: document the thick plugin variant
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
thick, server, multus: re-use common types
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
2021-12-16 17:18:35 +00:00
}
server . SetKeepAlivesEnabled ( false )
go utilwait . Forever ( func ( ) {
logging . Debugf ( "open for business" )
if err := server . Serve ( l ) ; err != nil {
utilruntime . HandleError ( fmt . Errorf ( "CNI server Serve() failed: %v" , err ) )
}
} , 0 )
return nil
}
Replace entrypoint script with initcontainers (#718)
* build: install the multus binary in an init container
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: generate kubeconfig via go
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: generate multus cni configuration via golang
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: provide a docker img for daemon based deployments
We will have 2 different images (only on amd64 archs):
- legacy entrypoint script based
- daemonized process
The `image-build` docker action is updated, to build these 2 images.
There will be 2 different deployment specs, along with e2e test
lanes, one for each of the aforementioned alternatives.
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: delegate CNI config watch loop via golang
For the thick-plugin alternative, provide the watch loop for
configuration regeneration via a golang binary.
Over time, this binary is expected to run the control loop to watch
out for pod updates.
To enable current multus users to chose when they upgrade to this new
deployment setup, these changes are provided in separate multus images,
having a different yaml spec files. Both of these alternatives are
tested e2e, since a new lane is introduced.
The following libraries are introduced, along with the motivation for
adding them:
- dproxy: allows traversing the default network configuration arbitrarily,
similar to what an X path / JSON path tool provides.
Repo is available at [0].
- fsnotify: watch for changes in the default CNI configuration file.
Repo is available at [1].
The config map providing the default network CNI configuration is not
copied over, since originally, the user was not required to install a
default network CNI plugin first, but, nowadays, this is a required
step of multus.
As such, it is no longer required to provide a default CNI
configuration.
[0] - https://github.com/koron/go-dproxy
[1] - https://github.com/fsnotify/fsnotify
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* run gofmt
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* refactor: make the builder pattern more idiomatic to golang
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
* build: update github actions to release new imgs
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
2021-10-27 12:42:37 +00:00
func copyUserProvidedConfig ( multusConfigPath string , cniConfigDir string ) error {
srcFile , err := os . Open ( multusConfigPath )
if err != nil {
return fmt . Errorf ( "failed to open (READ only) file %s: %w" , multusConfigPath , err )
}
dstFileName := cniConfigDir + "/" + filepath . Base ( multusConfigPath )
dstFile , err := os . Create ( dstFileName )
if err != nil {
return fmt . Errorf ( "creating copying file %s: %w" , dstFileName , err )
}
nBytes , err := io . Copy ( srcFile , dstFile )
if err != nil {
return fmt . Errorf ( "error copying file: %w" , err )
}
srcFileInfo , err := srcFile . Stat ( )
if err != nil {
return fmt . Errorf ( "failed to stat the file: %w" , err )
} else if nBytes != srcFileInfo . Size ( ) {
return fmt . Errorf ( "error copying file - copied only %d bytes out of %d" , nBytes , srcFileInfo . Size ( ) )
}
return nil
}