Deploying an SR Linux application using EDA Workflows#

Sometimes you have to work from the CLI, and there are times when it would be great if you could see a graphical representation of the front ports of the box you are working on. "Which one was ethernet-1/11 again on the D2L?", you might ask yourself.

Given the diverse and ever-growing portfolio of our data center switches, it is not a question with an obvious answer. Instead of looking it up in the documentation or manually searching for an image of the switch (hoping it is labelled with the ports), it would be great if you could get the answer straight from the CLI. With the custom front panel application, you can, thanks to the superpowers of the SR Linux CLI engine and the magic of modern terminals, capable of displaying images inline with the terminal contents.

So you try it out on a lab box, show it to your colleagues, who all agree that it would make for a great tool in your troubleshooting toolbox.
However, installing the application on a fleet of switches is cumbersome - you have to copy multiple files to different directories, and you would prefer if some other tool could automatically roll out this application to all switches in your network, and make it easy to keep it up to date.

Thankfully, we can leverage workflows in Nokia EDA to help us deploy this custom SR Linux app across our entire data center with a single click!

1. Prerequisites#

This task requires some familiarity with EDA - if you know how labels work, and have used the YAML editor before, you're good to go!

2. Objective#

The objective of this task is to make the operators' life easier by deploying the SR Linux Front Panel application to your data center switches and make it possible to view the front panel of the switches right from the CLI.
During this activity, you will learn about EDA's powerful application platform, including custom catalogs and workflows.

To accomplish this goal, you will have to go through the following steps:

1. Configure the custom catalog in EDA to make the platform discover the SR Linux Front Panel application contained in it.
2. Install the SR Linux front panel application in your EDA cluster.
3. Run the SR Linux Front Panel workflow that deploys the application on all the switches in your data center.

3. Technology explanation#

Extending a platform with custom applications is not a new concept - some automation platforms allow customization and extension to a certain degree. However, Nokia EDA takes the extensibility to the next level by providing the whole application lifecycle management, from development to deployment, from execution to monitoring, all in a single and coherent platform.

In this activity, you will focus on a single aspect of the application lifecycle: the distribution and installation of custom EDA applications. At the heart of this process lies EDA Store - the application engine that allows you to discover, list, install and manage native and custom EDA applications. It is powered by a combination of application catalogs and registries where the applications are stored and made available to the platform.

3.1 App Catalogs#

EDA App Catalogs are structured Git repositories that contain all the information EDA needs in order to discover and install an app contained in the catalog.

The catalogs contain one or multiple application directories, which contain app manifests.
The manifests describe the dependencies of an app (which are also apps), a list of custom resource definitions and custom workflows that the application brings with it, and of course the application's container image itself.

The applications are not versioned within the catalog repository's contents, but rather through Git tags - just check out the right tag, and you get the right version of the manifest! Of course, you don't have to do this yourself, all the smarts are contained within the EDA Store to handle this logic.

Of course, the Git repository containing the app catalog can also be private - in which case a user would create a Kubernetes Secret with the correct credentials and refer to it in the Catalog resource.

The default EDA installation comes with a single catalog pre-configured: the default built-in app catalog that contains the applications that Nokia provides out of the box.

3.2 App Registries#

The container OCI image of an EDA App contains the application's content and code, and these container images are hosted on and can be pulled from container image registries.

Application container images, particularly if they are custom apps that an organization has developed for its own use, might not be hosted on the same container image registry as EDA's built-in applications.
Alternatively, an organization might decide not to give the EDA cluster Internet connectivity, in which case, mirroring images from public repositories onto an internal repository is required to install additional EDA Apps.

EDA App Registries allow you to configure non-public container image registries to pull container images from. Authentication can also be configured, if the registry requires it, by configuring a Kubernetes Secret and referring to it in the Registry resource.

EDA comes with one app registry pre-configured: the GitHub Container Registry (or GHCR), which, as it is a public registry, requires no authentication, and is home to EDA's built-in applications.

3.3 App Distribution in EDA#

In order to distribute an already created EDA application, you would typically take the following steps:

• Download the edabuilder CLI tool that assist in every step of the application lifecycle, including publishing the application components to a registry and creating a catalog entry.
• Upload the app container image to a container image registry reachable from EDA.
• Publish the application manifest to a Git repository accessible to EDA - essentially creating a catalog entry.
• Configure the App Registry pointing to the container image registry hosting the app container image - if needed, also create the Kubernetes Secret with the credentials.
• Configure the EDA App Catalog, using the URL you would ordinarily Git pull from - again, create the Kubernetes Secret if needed.

The application you developed should now be available to install in the EDA App Store on your EDA cluster!

4. Tasks#

Back to our task at hand: we want to install, deploy and use the SR Linux Front Panel application on all of our data center switches. This application has already been written and its container image and the manifest are both published to the respective container registry and Git repository. All you need to do is to add the custom catalog and install the application.

The activity will be performed inside of EDA, you will not need any external tools!

4.1 Task 1.1: Adding the Custom Catalog#

The workflow used to deploy the SR Linux Front Panel app is not available in the default catalog that ships with EDA - you will need to add a custom catalog where the app containing the workflow is published in order to install the workflow.

This catalog can be found published under the EDA Labs GitHub organization: https://github.com/eda-labs/catalog
Feel free to check it out and browse it a bit!

Now to add this catalog to our EDA cluster, we can add it under System Administration -> App Management -> Catalogs

While configuring the catalog, you will see a field to configure an authentication secret reference - this is a Kubernetes secret.
Do we need to configure one to deploy the EDA Labs catalog?

Make sure to configure your catalog with a catchy title, for easier use!

After committing your changes, how can you tell the catalog was successfully loaded?

4.2 Task 1.2: Installing the SR Linux Front Panel app workflow#

Find the newly available SR Linux Front Panel app in the EDA App Store! When you click on it, you will get a detail view of the application.

What new Resources and Workflows will this application install into your EDA cluster?

Once you have verified this is the app you are looking for, it is time to install it! Before you go ahead though, why is there a dropdown next to the Install button?

Try a Dry Run first - once this is complete, you can view the logs of the dry run transaction - check out the output resources, in particular! What do you see there?

If you are satisfied with what you see (and you should be :)), it's time to install the application for real this time. Hit the Install button and let EDA do its thing.

Finally, check whether a new Workflow was actually installed - how can you do this? Try to check both from the EDA UI, and the CLI as well, using kubectl!
You can use what you learned from the dry run transaction earlier.

$ kubectl get WorkflowDefinitions -n eda-system
...
installsrlfrontpanel                 ghcr.io/eda-labs/srl-frontpanel@sha256:0f55857866b121505c258254fd86125d0f1bd645ee16d9f5c08a7c9cbefb893d   7m17s
...

With this, we have successfully installed this custom workflow onto our EDA cluster from a custom catalog!

4.3 Task 2.1: Rolling out the app using the Front Panel Plugin Installation workflow#

In System -> Workflows, create a new workflow for deploying the SR Linux Front Panel app! There are no knobs to tweak or any further configuration needed.

Within seconds, the workflow will finish and you will see the Workflow Results. Seasoned EDA users will immediately spot a difference when running a Workflow compared to say, making a change to an Intent - why do you think there was no option to perform a Dry Run first?

In the Workflow Results, you will see that the workflow went through three phases - initialization, retrieving nodes, and pushing the files. You will also see the status of these listed both in the YAML below, and in the visual representation of the Workflow stage flow graph.
There is a way to find out what nodes the files were pushed to, and what files were pushed to what paths, but it's not here - can you find it?
Hint: The "title" bar holds more than what meets the eye.

4.4 Task 3.1: Trying out the SR Linux Front Panel App#

Now that we have deployed the Front Panel app, it's time to try it out! Log in to the SR Linux CLI on leaf11.

ssh admin@clab-srexperts-leaf11

The Front Panel application's CLI plugin has created a new command for you to use: show platform front-panel.

You might see an empty output (other than a URL) - this is due to the fact the application is using an advanced terminal feature called inline images, you did not install the app wrong!

• If you are using the VS Code editor as your terminal, you can enable this feature by going into Settings (gear icon on bottom left of the IDE) and searching for "terminal image". You will need to toggle this checkbox to enable the feature, and to start a new terminal window (Terminal -> New Terminal).
• If you are using your own terminal application, it likely does not support inline images. If that is the case, please consider using the built-in terminal in the VS Code editor for this task.

Note that we include the URL of the front panel of your switch - so you don't have to pixel peep in your terminal, but rather you can view a high-resolution picture of the switch in your browser.

Now, if you see the front panel of your switch in all its glory on your CLI, you have successfully rolled out the custom app with EDA and made use of it!

The next task is optional, if you are interested in the implementation of the application!

4.5 Bonus Task: Playing with the SR Linux Front Panel App#

The way the Front Panel application works is the following: the CLI plugin collects information about the system using the telemetry system, and calls the frontpanel binary in /home/admin/ parameterized to display the front panel view in the CLI.

To access this binary, we must first switch to the bash shell on leaf11!

$ ssh linuxadmin@d2l

...

[linuxadmin@clab-srexperts-leaf11 ~]$ cd /home/admin/
[linuxadmin@clab-srexperts-leaf11 admin]$

Running the app is just a matter of executing it like any other Linux binary: ./frontpanel. What do you see as an output? Can you figure out what sort of parameters this app has?

admin@clab-srexperts-leaf11:~$ ./frontpanel
Error: --image flag is required

admin@clab-srexperts-leaf11:~$ ./frontpanel -h
Usage of ./frontpanel:
  -image string
        print the front panel image and exit
  -image-protocol string
        image protocol: auto|kitty|iterm (default "auto")
  -port-labels
        overlay port labels (1/1, 1/2, ...)
  -port-states-json string
        JSON object of interface state by name, e.g. {"ethernet-1/1":"up"}
  -version
        print the version and exit

The image parameter, as mentioned in the bare run, requires an input string, the model name of the switch. Try to view the front panel of one of the SXR models, with port labels showing!
Hint: The complete model name is required. Don't forget to put it between quotes.

admin@clab-srexperts-leaf11:~$ ./frontpanel -image "7730 SXR-1x-44S" -port-labels
Error: --image flag is required

For the final challenge of this task: use the front panel app to display the front panel of a switch with ports ethernet-1/2 up and ethernet-1/4 down!
Hint: The help output will be very helpful here.

admin@clab-srexperts-leaf11:~$ ./frontpanel -image  "7220 IXR-D2L" -port-labels -port-states-json '{"ethernet-1/2":"up", "ethernet-1/4":"down"}'

Congrats! You have mastered the SR Linux Front Panel application!

5. Summary and review#

If you got this far, you have:

• Added a custom catalog and installed an application from it in EDA
• Used the installed workflow to deploy the SR Linux Front Panel application
• Tried out an experimental CLI plugin that leverages modern terminal technology to bring your network CLI experience to the 21^st century

The Front Panel application you tried out here is also available to install on actual SR Linux switches - maybe it will help you solve an operational problem in your own network!

We hope you found this information useful and learned lots, and that you enjoyed this SReXperts (h)ac(k)tivity!
Now go on and take a crack at another one!