Installation customization#

If you followed the Installation process section, you already know that EDA uses kpt k8s package manager to install its components. Without getting too much into the details of kpt, you can expect that as any other package manager, kpt packages can be customized before the actual manifests will be applied to the cluster.
This allows users to customize EDA installation according to their needs.

In kpt, the customization is done by setting the values of the parameters marked with the kpt-set annotation. Consider the Catalog manifest from the eda-kpt-base package:

apiVersion: appstore.eda.nokia.com/v1
kind: Catalog
metadata:
  name: eda-catalog-builtin-apps
spec:
  title: EDA built in apps catalog
  remoteURL: https://github.com/nokia-eda/catalog.git #kpt-set: ${APP_CATALOG}
  authSecretRef: gh-catalog

The #kpt-set: ${APP_CATALOG} annotation is used to set indicate that this value can be set by kpt and overwrite the default value. If you were to install EDA with another catalog, you would do the following:

1. Clone the nokia-eda/kpt repository
2. Change into the eda-kpt-base package directory. This directory is the root of the package and contains the Kptfile.

3. Run the kpt function¹ with the setter image to modify the APP_CATALOG parameter:

   kpt fn eval --image ghcr.io/srl-labs/kpt-apply-setters:0.1.1 \
   --truncate-output=false -- \
   APP_CATALOG=https://github.com/acme/my-custom-catalog.git
   

4. Once the APP_CATALOG parameter is set, you can apply the EDA package:

   kpt live apply
   

In the KPT Setters Reference section you will find all the setters parameters that can be customized per package that we have in the nokia-eda/kpt repository.

Playground#

An EDA installation that is deployed with a set of pre-configured components and a small virtual network is called a playground. The Getting Started guide introduces EDA to the users by deploying the EDA Playground on a KinD-based kubernetes cluster.

Users can deploy the playground using a single make command that will come up with some sane defaults for all platform settings. While this is sufficient for the most common use cases, we also provide a way to customize the playground installation via:

• make variables in the preferences file or inline
• kpt setters file

Preferences file#

The preferences file is a file that contains high-level variables that are taken into account by the Makefile used to orchestrate the playground deployment.

The EDA Playground repository contains the prefs.mk preference file that lists these high-level variables along with a short description of their purpose.

# User preferences
# Options in this file override options specified on the command line
# and the default values specified in the Makefile.
# To enable an option simply uncomment a line and give it a value

# KinD cluster options
# -----------------------------------------------------------------------------|
# Do not deploy the kind cluster
# Uncomment this variable to perform playground installation
# on an already available k8s cluster
# NO_KIND := yes

# Use a custom kind configuration file
# KIND_CONFIG_FILE := private/kind-ingress-config.yml

# Use a different kind cluster name
# KIND_CLUSTER_NAME := eda-demo2

# Do not install metallb as part of the kind cluster
# NO_LB := yes

# Use a custom k8s cluster API server address
# KIND_API_SERVER_ADDRESS := "10.1.2.3"

# How do clients reach your cluster?
#  EXT_DOMAIN_NAME can also be set to an ipv4/6 address if no domain record
#  is present. In that case EXT_IPV4_ADDR = $(EXT_DOMAIN_NAME) or its ipv6
#  counterpart.
# -----------------------------------------------------------------------------|

# EXT_DOMAIN_NAME = "<Your domain name or ip address>"
# EXT_HTTP_PORT = "<Port for http access>"
# EXT_HTTPS_PORT = "<Port for https access>"
# EXT_IPV4_ADDR = "<LB IP or external route>"
# EXT_IPV6_ADDR = "<Same thing but in ipv6>"

# EDA CX options
# -----------------------------------------------------------------------------|
# Do not deploy simulator nodes in CX for the TopoNode resources
# set to false when connecting hardware nodes to the cluster
# or when simulators nodes are deployed by another system.
# When set to false, the topology-load make target will be skipped and
# no TopoNode resources will be created.
# SIMULATE := false

# Don't prefer dual stack services if possible in the configured cluster.
# -----------------------------------------------------------------------------|

# SINGLESTACK_SVCS = false

# Proxy vars specific to the cluster nodes
# rather than the host machine that the make is running from
# -----------------------------------------------------------------------------|

# HTTPS_PROXY ?= ""
# HTTP_PROXY ?= ""
# NO_PROXY ?= ""
# https_proxy ?= ""
# http_proxy ?= ""
# no_proxy ?= ""

# OpenAI API key
# -----------------------------------------------------------------------------|

# LLM_API_KEY ?= ""

# KPT Core setters config file
#  A path to the apply-setters function config file that holds the values
#  you intend to apply to the EDA Core packages.
#  See config/kpt-core-setters.yml for an example.
# -----------------------------------------------------------------------------|

# KPT_SETTERS_FILE := private/kpt-setters.yml

# External packages options
# -----------------------------------------------------------------------------|

# do not install cert-manager. Set to "yes" when you have your own cert-manager
# in a "cert-manager" namespace
# NO_CERT_MANAGER_INSTALL := yes

# KPT init options
# -----------------------------------------------------------------------------|

# Ignore if a package was already init'd against a cluster (resourcegroup.yaml)
# Use --force to overwrite an existing inventory
# KPT_LIVE_INIT_FORCE := 1

# Add --inventory-policy=adopt to live apply, this will allow kpt to adopt
# already applied *unmanaged* resources that the kpt package is trying to
# clear, it will update/reconcile any differences.
# KPT_INVENTORY_ADOPT := 1

Users can set the variables in this file to the intended values and then run the make command to deploy the playground with the desired settings. To use a custom location of the preferences file instead of the default ./prefs.mk set the PLAYGROUND_PREFS_FILE environment variable to the desired path².

KPT Setters file#

When the preferences file contains a set of high-level variables, the KPT setters file may contain values for every KPT setter used in nokia-kpt KPT repository. The complete list of setters, their example values and types are provided in the KPT Setters Reference section as well as in the kpt-setters.yaml file.

To use your own KPT setters file, create a copy of the kpt-setters.yaml file with the required parameters set and set the KPT_SETTERS_FILE variable in the preferences file to the path of your setters file.

Keycloak admin password#

The Keycloak administrator password can be updated during install with KPT setters, or post-install with the following procedure:

1. Navigate in web browser to {EDA_URL}/core/httpproxy/v1/keycloak
2. Login with the current Keycloak administrator username and password.
3. Select "Manage Account" on the top right dropdown for the user.
4. Select "Account Security > Signing In" from the left menu.
5. Click "Update" next to "My Password".
6. Configure a new password and save it.
7. Generate the Base 64 hash of the new password.
8. Using a system with access to the Kubernetes API of the EDA deployment, update the keycloak-admin-secret and restart Keycloak:

kubectl -n eda-system patch secret keycloak-admin-secret \
-p '{"data": { "password": "<NEW BASE64 HASH>" }}'

kubectl -n eda-system rollout restart deployment/eda-keycloak

KPT Setters Reference#

Core package#

Package location: eda-kpt-base

External packages#

Package location: eda-external-packges

Playground packages#

Package location: eda-playground