Try EDA Like a Pro#

Our tiny but mighty make try-eda command carries out the entire EDA Playground installation. It installs a Kubernetes cluster, deploys the EDA core apps, and creates the necessary playground components along with a simulated network topology.
Automation greatness, one click away. Just like we love it.

But as you build up your EDA experience, you may find yourself eager to step off the beaten path and start customizing your installation experience to your needs. In this blog post we share some new additions made to the Playground installation to make your Try EDA experience more enjoyable.

Preferences file#

Most likely you started your EDA journey by following our quickstart guide and deployed your playground environment like this:

export EXT_DOMAIN_NAME=${DNS-name-or-IP} \
make try-eda

Yes, this is all you need to get the ball rolling, but providing the variable values inline is not always convenient. Often you want to store the values in a configuration file.

EDA's Playground config is powered by the make preferences file and we ship the instance of it - prefs.mk - within the playground repo itself.

The preferences file contains a selected set of the "most wanted" variables that you would want to tune for your playground installation. Things like the address you use to access the UI, the proxy settings, and kind cluster name.

You can of course edit the provided prefs.mk file, but what I like to do is to create a new file within the ./private directory where I can store my values without changing the original file. There are a few reasons for this:

1. Keep the git repo clean, as the files in the private directory are not tracked by git.
2. Doing git pull won't overwrite the changes I made to a copy of the prefs.mk file.
3. I can create multiple preferences files for different installation scenarios.

If you opt in using a custom preferences file you would need to set the PLAYGROUND_PREFS_FILE environment variable to point to the file you want to use.

export PLAYGROUND_PREFS_FILE="private/kind-prefs.mk" #(1)!
make try-eda

1. Both absolute and relative paths are supported.

export PLAYGROUND_PREFS_FILE="private/kind-prefs.mk"

KPT Setters File#

Alright, you noticed that the make preferences file contain only a handful of variables. But what if you want to customize the installation further?

EDA uses the kpt to deploy and manage the configuration of its components. When browsing the nokia-eda/kpt repository you may notice the kpt-set comments in various kubernetes manifests:

apiVersion: core.eda.nokia.com/v1
kind: EngineConfig
metadata:
  name: engine-config # kpt-set: ${CLUSTER_MEMBER_NAME}
spec:
  # ...
  llm:
    apiKey: "" # kpt-set: ${LLM_API_KEY}
    model: gpt-4o # kpt-set: ${LLM_MODEL}
  simulate: true # kpt-set: ${SIMULATE}

These kpt-set comments are markers for the kpt tool that these values can set by Kpt using the ${VARIABLE_NAME} syntax. How would you set the values of these variables you ask? Using the Kpt setters file.

The setters file allow you to specify the values for the setters that will be used when you install EDA Playground. For example, to set the PV claim volume size for the Git server deployment, you would create a yaml file like this:

apiVersion: v1
kind: ConfigMap #(1)!
metadata:
  name: my-setters
data:
  GOGS_REPLICA_PV_CLAIM_SIZE: 10Gi #(2)!
  # your other setters here

1. As you can see, the setters file is a ConfigMap resource, but it is not applied to your cluster, it is only used by the kpt tool to read the values from it.
2. The setter's key must match the name of the setter variable in the manifest file.

Now that you have your setters file with the necessary values, you should set the path to it in the preferences file:

KPT_SETTERS_FILE := private/my-setters.yml

And that's it! The kpt will read the values from the setters file and apply them to the manifests when you run the make try-eda command.

Kind Config#

The default EDA Playground installation deploys the platform on a KinD cluster. And by default we deploy a default KinD cluster using a barebones cluster configuration.

This works great for the most installation scenarios, but sometimes you need to customize the kind cluster configuration. For example, you may need to add extra bits of configuration to play with Ingress resources and expose additional ports for your cluster.

We allow you to use your own kind configuration file by setting the KIND_CONFIG_FILE variable in the preferences file pointing to the desired config file. Here is an example of a custom kind config file that I use to setup ingress nginx with kind:

---
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
networking:
  ipFamily: dual
  apiServerAddress: "127.0.0.1"
nodes:
  - role: control-plane
    kubeadmConfigPatches:
      - |
        kind: InitConfiguration
        nodeRegistration:
          kubeletExtraArgs:
            node-labels: "ingress-ready=true"
    extraPortMappings:
      - containerPort: 80
        hostPort: 80
        protocol: TCP
      - containerPort: 443
        hostPort: 443
        protocol: TCP

KIND_CONFIG_FILE := private/kind-ingress-config.yml

LLM API Key#

The Natural Language Query feature requires an OpenAI API key to be set in the EDA's Engine Config resource. You can provide the key directly in the preferences file using the LLM_API_KEY variable, but providing a "secret" in a file body is not the most secure way to do it.

Instead, you can set the environment variable under the same key LLM_API_KEY in your .profile, .zshenv, .bashrc, .zshrc, or any other file that your shell reads on startup. Make tool will read the env variable under this key by default, so you may leave the variable unset in the preferences file.

Kind API Server Address#

When we deploy a Kind cluster for EDA Playground, the k8s API server address is kept at its default value of 127.0.0.1. The localhost nature of the address results in the k8s API server being inaccessible from outside the machine you run the cluster on.

We noticed that many users would like to spin up playground on a remote servers and access the k8s API server via a network. To support this use case, we added the KIND_API_SERVER_ADDRESS variable to the preferences file which allows you to set the non localhost IP address for the k8s API server. This effectively allows you to access the k8s API server from outside the machine you run the cluster on.

More Permanent UI Access#

And the last tip for today concerns the UI. Originally, you access the UI by forwarding the port of the eda-api service to your local machine using the make start-ui-port-forward command. This works great, but a slight inconvenience is that you need to keep your session open to keep the port forwarding alive.

In pursue of a more permanent port forwarding solution, we added the enable-ui-port-forward-service make target that will create a eda-ui.service systemd service that uses the same port forwarding logic, but will run in the background. Run this target once, and then you can access the UI anytime you want.

When your redeploy the cluster without changing the EXT_HTTPS_PORT you may just restart the service to get it up and running again.