January 2025: Feature releases & highlights

Multi-site actions. Network Resource Profiles. Enhanced Python Client.

The January releases deliver the following main additional features:

• Multi-site actions: you can now select a set of sites and perform actions like adding a label to the group
• Network resource profiles: We have extended the resource profiles to cover network access. This means a site provider can control tenants’ inbound and outbound network access at the sites.
• Enhanced Python client: we have enhanced our open-source Python client, especially around the Avassa pub/sub bus API.

Multi-site actions

You can now select a site of sites and perform actions on the group of selected sites. This lets you, for example, search for sites based on names and labels. In one operation, you can then, for example, add labels to this group.

Start by selecting “Multi site actions…”:

Then, perform a search and select sites; in the above example, the user searched for sites with the label “model = model-a” and selected all of them:

You can continue to build a set of sites; for example select some of the sites with the label “model = model-b”:

Now you have a group of sites as shown above: robot-1, robot-4, robot-5, robot-8, robot-2 and robot-6.

Currently, the UI supports three actions on a site of sites:

• Add/remove labels
• Delete sites
• Local unseal: the site can unseal (decrypt) itself without a network connection to the Control Tower. This decreases security but enables sites to restart without connectivity.

The example below shows adding labels:

If you are utilizing our APIs to build automation, it is good to know that features like the above are supported by a “batch API”: https://avassa-api.redoc.ly/#section/Configuration-and-Operational-State/The-v1config-Endpoint

A POST to this endpoint is used to update multiple objects in one transaction, i.e., either all included operations are accepted or none.

Network resource profiles

Avassa has built-in support for multi-tenancy, which lets a site provider create isolated slices of the edge infrastructure. Tenants can get non-overlapping edge sites or controlled access to shared edge sites and hosts. To control resource usage, the site provider can assign resource profiles per tenant or tenant and site. Resource profiles control the usage of resources like memory, CPUs, and GPUs:

A resource profile can be assigned to a tenant as shown below:

With the January releases, we have now added support for controlling inbound and network access for applications at the edge sites. This means the site provider can control if application owner tenants can request outbound or ingress network access to their applications.

A resource profile could contain the following:

  outbound-network-access:
    deny-all: true
  inbound-network-access:
    rules:
      192.0.2.0/24: allow

The outbound network access is prohibited, and the inbound network connections to the application’s ingress address are only allowed from the 192.0.2.0/24 network. Any applications trying to enable outgoing access will fail. Ingress needs to be requested from a pool conforming to the rule above. This is configured in the network section of an application:

The combination of applications requesting network access and resource profiles limiting network access can make trouble-shooting challenging. If you are an application developer and deploy an application to an edge site and request inbound, do you know if your site provider has allowed that for your tenant?

To help understand resource profile issues, we added information to the state of application services showing active resource profiles. See example below:

service-instances:
  - name: pop1-service-1
...
    ingress:
      ips:
        - 192.168.72.102
      inbound-access:
        inherited-policy
          default-action: deny
          rules:
            - 192.168.71.0/24: allow
        application-policy:
          allow-all: true
        combined-policy:
          default-action: deny
          rules:
            - 192.168.71.0/24: allow

Here, we can see that only connections from 192.168.71.0/24 are allowed. As an application owner, you can use this information to ask the site provider to double-check resource profiles.

A new action, debug, can also be requested on a network service. Read more on these advanced topics in the new debugging network section.

Read more:

https://docs.avassa.io/tutorials/resource-management. (This tutorial is updated with details explaining each resource type.)

About Application Networking: https://docs.avassa.io/fundamentals/application-networking

How to configure application networking: https://docs.avassa.io/how-to/network-app

How to create a new resource profile: https://avassa-api.redoc.ly/tag/Hardware-Resource–Profiles#operation/v1_config_system_resource_profiles_post

Enhanced Python Client

You can get a Python client at https://gitlab.com/avassa-public/avassa-client-py. This will get you started using the Avassa APIs from Python. The Web Socket API for the Avassa pub/sub bus has been enhanced in the latest releases, and the Python client is improved in that area. In particular, the new QueryTopicsConsumer class automatically leverages the newly added pagination feature of the Volga query-topics API for more efficient queries and an interface consistent with regular Volga consumers.

Read the (updated) programming tutorial: https://docs.avassa.io/tutorials/volga-applications

(mapcar (lambda (name) (add-label "new-label "17")) (robot-1 robot-4 robot-5 robot-8 robot-2 robot-6))