March 2023: Feature releases & highlights

The March releases (23.3.0-23.3.5) contain the following main features:

  • Port mapping: you can now let all services share the host IP and map ports to the individual services. This saves IP addresses on the site.
  • Reschedule applications on a site: When performing maintenance activities on a site, you might get to a situation where some hosts are not running applications. You can now perform a reschedule action on a site and spread the services across all hosts.
  • Graphs for application metrics are now available in the Control Tower UI, so you can easily get current and historical metrics for your application.
  • Enhanced Application Web UI forms: We have added Web UI forms support to configure site IP and application ingress IP.
  • Enhanced labels and resource profiles support in the UI: site providers can now create labels that application owner tenants do not inherit, and application owners can now see all labels propagated from hosts, GPUs, and devices. The site provider can also define resource profiles that specify which resources a tenant can use, such as a GPU.

Port mapping

An Avassa application is split into services which in turn has several containers. By default, services can not be reached from the outside. But you can configure ingress IP addresses for each service. The IP addresses can come from an IP address pool or DHCP at the site. However, a site’s supply of IP addresses may be limited. In such a case, sharing the host’s IP address with the services running on this host may be desirable, forwarding a set of ports into one or several services.

πŸ†• We have now added a feature to forward traffic on configured ports. To enable this ingress mode, use the following site configuration:

name: my-edge-site
type: edge
ingress-allocation-method: port-forward

In port-forward ingress mode, the primary IP address for the selected interface is used as ingress. This address may be shared by multiple services running on the same host as long as they request disjoint sets of ports to be forwarded.

In the application, you can now say:

name: my-http-app
services:
  - name: http-service
    network:
      ingress-ip-per-instance:
        protocols:
          - name: tcp
            port-ranges: "80"

This way, you are not consuming more IP addresses on the site.

Reschedule applications on a site

Before moving into the new reschedule feature, let’s recap Avassa’s site maintenance tools.

The infrastructure on an edge site needs maintenance: hosts may need to be replaced, hosts can be added for more computing resources, the OS might need to be upgraded, and more. All of these activities have an impact on running applications. Therefore the IT team needs tools to perform infrastructure changes while minimizing edge application impact.

Since a while back, Avassa has provided tools to set a host in maintenance-mode blocked and drain hosts. A host in blocked maintenance-mode will stop the local scheduler on the site from adding new applications to that host; drain will move application services from that host to other hosts on the site.

Imagine a scenario where you want to replace all hosts on a site. You could do this in the following way:

  1. add the new hosts
  2. set the old hosts to maintenance-mode blocked. This is important in the next step since we do not want services to be moved to hosts that are to be replaced
  3. drain the old hosts; this will reschedule the applications to the new hosts

Another scenario might be to perform an OS upgrade host by host. You drain one host, upgrade it, drain the second host upgrade it, and so forth. In that case, you will have a host with no running applications at the end. Extending a site with a new host would also lead to the same situation.

πŸ†• To utilize all hosts on a site, we have now added a reschedule operation.

This will rerun the scheduler and spread the applications on all hosts within the site according to the existing matching criteria (application requirements, resource profiles, etc.). It uses a defensive heuristic to keep running applications without moving them.

A reschedule operation might look like the following:

$ supctl do --site sthml system cluster reschedule
rescheduled-service-instances:
  - name: telco.alpine.fifth-srv-4
    from-host: h05
    to-host: h07
  - name: telco.alpine.fifth-srv-3
    from-host: h04
    to-host: h06
  - name: telco.alpine.fifth-srv-2
    from-host: h03
    to-host: h07
  - name: telco.alpine.first-srv-1
    from-host: h06
    to-host: h07

You can read our documentation on how to perform site maintenance.

Application metrics graphs

The Avassa system has a built-in edge native pub/sub bus. The Avassa platform uses that bus, but application developers can publish and subscribe to application-specific topics as well.

The Edge Enforcer constantly monitors the applications on the edge sites and publishes application metrics on specific topics. You will get metrics per container, per service, and per application. You can read more on application metrics in our Fundamentals section.

πŸ†• While these have been available to fetch over APIs, we have now added metrics views in the Control Tower Web UI.

Per container metrics

For each container in an application on a site, you will see the current memory, CPU, and container layer disk usage. You can then drill down and see a graph over time. Note well that the built-in pub/sub bus collects and store metrics every 30 seconds, which makes historical views available (also over APIs)

Per service metrics

Services can mount ephemeral and persistent volumes; therefore, storage usage is aggregated at the service level. Selecting a service, you get the current value in the services table and historical data plotted below.

Per application metrics

One application is defined as one or several services. Services for the same application can be scheduled across different hosts. Therefore the metrics use a max aggregation algorithm for CPU and disk, but the total memory for the application is shown. You also get the application network intensity, inbound and outbound.

Forms support for application networks.

πŸ†• You can use a forms interface to specify ingress networking when configuring a site. This configuration was previously only available through the YAML widget.

The example below shows a site with an ingress pool configuration.

And in the application, you can use forms the configure the Ingress IP for the services. In the example below, we configure TCP port 8080 to be accessible for all incoming source addresses, and the service shall be able to perform outbound calls.

Enhanced label and resource profiles support in the User Interface

Site labels provide the means for targeted deployments of applications. As a site provider, you have two options when creating site labels:

  1. labels that are inherited by any application owners, you create
  2. labels that are only visible to you, “private labels.”

As an application owner, when you create labels, these are only visible to you.

We have now added UI support for site provider private labels and the possibility for application owners to create their own labels.

In the screenshot below, the site provider is adding a site label “green” to the site “RΓΆda Kvarn” and “Bergakungen”

(Yes, you can have labels with just a key)

Assume that the site provider has assigned the sites to the application owner β€œApplifer.” When “Applifer” logs in, he sees the green label.

But imagine the use case where I am a site provider and would like to define labels that I can use for deploying applications where the labels are unavailable for the tenants.

πŸ†• You can create site provider tenant-specific labels using the Add private labels button.

This is a good time to explain how this works in the backend over APIs and the Avassa command line.

If you are a site provider, you can configure labels that are inherited on the system sites object:

$ supctl show system sites gothenburg-bergakungen --fields labels
labels:
  system/type: edge
  system/name: gothenburg-bergakungen
  green: ""

But to configure private labels, you create assigned-sites with the corresponding labels:

$ supctl show assigned-sites helsingborg-roda-kvarn --fields labels
labels:
  system/type: edge
  system/name: helsingborg-roda-kvarn
  my-private-label: "42"
  green: ""

Note well the symmetry with assigning sites to application owner tenants. They get assigned site objects which they can use for their specific configuration in the same way as shown above.

πŸ†• The header for the site shows the different labels in different colors:

  • Black: system assigned
  • Dark blue: my private labels
  • Light blue: inherited by tenants

πŸ†• As an application owner, you can now create your own labels.

πŸ†• We have also added a view in the Control Tower UI so that the site provider can see the private configuration in assigned sites:

The above described enhanced label support for configured labels. There is another category of labels that are generated by the system based on discovered capabilities.

Earlier Avassa releases this spring introduced advanced support for detecting GPUs and devices like cameras. As an application developer, you can specify in your application specification that your container needs a GPU or specific device. The Edge Enforcer running on the site will schedule your container to the correct host; you do not have to know which host that is connected to a camera, for example.

πŸ†• We have added visibility for labels based on discovered site capabilities in the site view available for an application owner:

The application owner view above shows an important abstraction. Application owners do not deal with physical hosts. They get labels as a contract towards the site, and in the backend, the edge enforcer will match physical hosts when scheduling the applications.

Resource profiles

When working with devices and GPUs like the above, the site provider can control which application owners can see which resources.

πŸ†• The UI now supports defining resource profiles, as shown below.

(In earlier versions, this was only available over the Avassa command line tool or APIs)

πŸ†• And when you create or edit the tenant, you can assign the resource profile:


Phew, this has been a busy month for the front-end team. In summary, we have enabled the heavy backend features for multi-tenancy, GPU/device discovery, and application metrics in the User Interface.

And the ability to reschedule applications on a site to cover site maintenance activities.

“I want to stand as close tot he edge as I can without going over. Out on the edge you see all the kinds of things you can’t see from the center”

Kurt Vonnegut

This was the first article you read today that did not mention ChatGPT, and so it goes….

Try it yourself

Book a demo

Deploy container application across a distributed edge cloud in minutes. Book a demo today to have a closer look at the Avassa platform!

LET’S KEEP IN TOUCH

Sign up for our newsletter

We’ll send you occasional emails to keep you posted on updates, feature releases, and event invites, and you can opt out at any time.