January 2024: Feature releases & highlights

Preflight check, tenant UI, data flow design pattern

New year, new features! The January releases adds:

• Edge Enforcer installer enhancements: preflight check and improved installation feedback.
• Enhanced application owner tenant user interface: if you log in as an application owner tenant, you will now get more information about your assigned sites and applications.
• Data flow design pattern: many edge use cases process data sequentially between applications. We have added documentation on how to achieve this.

Edge enforcer installer enhancements

Installing the edge enforcer on the edge hosts can be fully automated since it is one standard install command for all hosts. The hosts will then be onboarded to the control tower with a zero-touch secure provisioning process. A small set of OS requirements is needed for the edge enforcer to work correctly on your target host platform. There are also requirements for network connectivity to reach the Control Tower. We have added a --preflight option to the installer to validate these requirements:

$ curl -s https://api.<environment>.<domain>.avassa.net/install | sudo /bin/sh -s -- --preflight

This will result in something like:

Required Kernel Modules
-----------------------

All required kernel modules available

Recommended Kernel Modules
--------------------------

All recommended kernel modules available

Port Status
-----------
4646	Ok
4668	Ok
4653	Ok
4848	Ok
4849	Ok
4949	Ok
4950	Ok
8137	Ok
51820	Ok

The following port should be open between hosts:
  - UDP/TCP 53 (optional, if you are using the Edge Enforcer DNS Server)
  - UDP/TCP 4668 (Host detection and cluster communication)
  - UDP 51820 (Wireguard, application networking)

Control Tower Connectivity
--------------------------
Checking <https://api.test2.edge.avassa.dev/healthz>... Ok
Checking api.test2.edge.avassa.dev TCP port 443... Ok
Checking registry.test2.edge.avassa.dev TCP port 443... Ok
Checking test2.edge.avassa.dev TCP port 443... Ok
Checking volga.test2.edge.avassa.dev UDP port 443... Ok

Minimal Disk Requirements
-------------------------
Filesystem     Avail
/dev/sda1        18G

Make sure you have at least 500Mb of free disk where you install the Edge Enforcer

Minimal Memory Requirements
---------------------------
Total 2013244 kB of memory... Ok

Distribution Specific for Ubuntu 22.04.3 LTS
--------------------------------------------
Docker not in snap... Ok

A brief explanation of the checks follows; see details in our documentation:

• Kernel modules: the Edge Enforcer utilizes some Kernel Modules, for example cgroups, namespace, nftables etc. This check validates that those are part of your OS.
• Port status: this will check ports the Edge Enforce binds to on the host. It also prints information regarding ports between hosts if you have a site with several hosts.
• Control Tower Connectivity: validates that the Edge Enforcer can reach the Control Tower
• Disk and memory checks will hint that you have enough memory and disk for Edge Enforcer. Note well that your applications are probably the most demanding on host resources.
• Docker in snap: you can choose Docker or Podman (–podman) when installing Edge Enforcer. Docker can, however, not exist as a snap on the host. If this is the case, you need to remove the snap.

In addition to the added preflight check option, the feedback for the progress of the installation has been enhanced.

Application owner tenant user interface enhancements

Before describing the enhanced user interface for application owner tenants, let’s start with an overview of Avassa multi-tenancy.

There are two kinds of tenants: site provider and application owner. A site provider manages the edge infrastructure, sites, and hosts. A site provider can also deploy and manage applications.

A site provider can create several subtenants that represent application owners. The site provider gives the application owner access to a set of sites and, optionally, a resource profile that limits resource usage per site, like CPU and disc. Application owner tenants can overlap because the site provider gives multiple tenants access to the same site, most likely assigning resource profiles. Different application owner tenants have no insights into other tenants. All data and networking are separated and encrypted.

The site provider has a coarse-grained insight into the application owner regarding the deployed applications and the overall state of those applications.

Let us illustrate the above using the Control Tower User Interface.

In the screenshot below, I am the site provider, and see my sites to the left. Sites with a T indicate that I have given a tenant access to that site, called “assigned site.”

As the site provider, I can see that the tenant app-team-1 is running an application foo on that site, and the application is in a good state. However, I can not drill down further into the application.

Let us now create a second application owner tenant:

Note that I selected an existing resource profile to limit resource usage for that tenant. You can read more about resource profiles in our documentation.

The next step is to assign sites to the new application owner tenant:

Note that the Electric Cinema site is shared between the two application owner tenants, but no data leakage between those tenants is possible, with total separation for logs, networking, data, and more.

If I now log in as the application owner tenant app-owner-2 I see only those sites:

And note that I have no insight that the other tenant has an application running on the Electric Cinema site. Let us deploy an application as this tenant.

Of course, from here, you have full access to all details and drill-down to your application.

Let’s turn back to the site provider view of the same site:

The site provider now sees that he has two tenants with an application each. (But no insight into the details of the application.)

OK, what is new then?

🆕 As an application owner, when you select an assigned site, you will now have all accessible information in the user interface. To start with, you will see all the applications you have deployed to the site:

You will also be able to see which secrets you have distributed to this site:

For the site itself, you only see relevant information as an application owner, no details on the hosts:

A summary of the screenshot above:

• System site labels: labels assigned by the Avassa system
• Site provider site labels: labels assigned by the site provider
• Site provider host labels: labels assigned to any of the hosts on the site. As an application owner, you now know that there is a host with the fire-protected label, and you can use that when deploying your application. The edge enforcer will ensure your application gets placed on the correct host.
• Private site labels: labels you have defined as an application owner.

At the bottom of the screen, you see read-only information about the cluster. Note that no information on the hosts is available.

In the same way device labels, (cameras, sensors), and GPU labels can be available to an application owner. The site provider defines the device and/or GPU label rules for the site. In addition, the site provider needs to make these available to the application owner through a resource profile.

Finally, the topics available for the application owner tenant can be searched in the tab “Query Topics”:

Note well again the tenant isolation, an application owner tenant will only see his container logs, application metrics etc. The example above also shows that the application tenant has created a topic “my-app-owner-topic”.

Data flow design pattern

Many edge use cases involve processing collected sensor data in well-defined steps: collect, normalize, refinement, and forward, as an example. This represents what is often referred to as a data flow. As a developer, you want to string your application components together in sequence to perform these steps.

We have added developer documentation on utilizing the Avassa embedded pub/sub bus to achieve a data flow.

The History of the Preflight Checklist

“Following a fatal crash involving a prototype aircraft, the first pre-flight check was created by Boeing in 1935. Prior to takeoff, the pilots failed to disengage the gust locks. When they tried to leave the ground, they were unable to use these essential flight controls. By creating a formal list of steps to take prior to takeoff, the first preflight checklist became part of flight protocol.”

Source: Kingsky Flight Academy