March 2024: Feature releases & highlights

Application upgrade windows, UI support for Edge Enforcer updates, and resource profiles

The March releases contain these major features:

• Application upgrade windows: You can now set time windows, per site, that will control application upgrades.
• Enhanced user interface for Edge Enforcer updates: There is a feature in Avassa to control when the Avassa Edge Enforcer is updated, and we have now added user interface support for that.
• User interface to show resource profiles: Avassa enables control over resource usage, such as CPU and memory. We have now added User Interface support to see configured resource profiles per site
• Developer tutorials: We’ve added two new developer tutorials, to guide from the first Python application to deployment at the edges.

Application Upgrade Windows

The heart of the Avassa platform is deploying applications to remote edge sites. When you trigger an update, the order is sent to all sites to start the update. The platform will update the applications for disconnected sites whenever the site is available again.

You can use the delayed shutdown feature to minimize the impact of application upgrades. This feature starts a new service instance but lets the old run for a while.

🆕 But imagine you would like to control when the upgrades occur per site. For that purpose, we have introduced application upgrade windows. When you trigger a deployment to a site with associated upgrade windows, the upgrade will put the new application (version) in a site-local queue if the time is outside the allowed time frame.

Let’s say you have associated an upgrade window to a site saying:

• days-of-week: Saturday, Sunday
• start-time: 00:00
• duration: 2h

Then, you trigger a deployment on Friday at 3 PM. The upgrade will be put in the site-specific application queue and automatically be executed at 00:00 on Saturday. However, all artifacts, such as images, secrets, etc., are downloaded immediately to the site so the scheduler can take direct action at the planned time.

The newly introduced upgrade windows also support multi-tenancy. Imagine you, as a site provider, only allow upgrades as above. But you have also created application owner subtenants. They can define their upgrade windows, but these are only active within any inherited windows from the site provider. Let us say that the application owner subtenant application team defines an upgrade window like this:

• days-of-week: Saturday, Sunday
• start-time: 01:00
• duration: 5h

The actual window for that application owner will be 01:00 – 02:00 on Saturday and Sunday.

Of course, if there are no inherited upgrade windows from the site provider, the application owner is in full control.

Below is a scenario to illustrate upgrade windows.

As a site provider, create an upgrade window (part of system profiles)

$ supctl create system site-profiles <<EOF
name: weekend-upgrade-window
    application-upgrade-windows:
      - days-of-week: Saturday, Sunday
        start-time: 00:00
        timezone: site-local
        duration: 2h
EOF

And associate that with a site:

In the site applications tab, you will now see information related to upgrade windows:

Above, you can see that there is an upgrade window associated with the site, and no upgrades are waiting in the queue

And if you now deploy an updated application (from 1.0 to 2.0) to that site, the following will happen. The deployment will stay in the deploying state until the upgrade window opens.

The application queue on the site will have version 2.0 queued:

You can also inspect the queue using the command line:

$ supctl show --site electric-cinema application-queue
applications:
  - name: popcorn-controller
    time: 2024-04-02T07:30:58.676Z
    application-deployment: poppers
    version: "2.0"

The example above also showed an essential feature around windows. You can set the time in UTC or local time. Imagine you have sites across the globe. If you use site-local, you can assign the same window to all sites, and the local time will ensure that it happens according to the respective site’s time zones.

Let us build more upon the above scenario, now we have yet another update from 2.0 to 3.0 that we deploy.

Now you have both versions 2 and 3 waiting in the queue. When the upgrade window opens, the application will be upgraded two times. If you can go directly to version 3, you might want to remove version 2 from the queue:

So now only version 3 is waiting in the queue:

It might be a critical update you want to force even though you are not within the upgrade window. There is a force update function:

Which will upgrade to version 3 immediately:

The flexibility does not stop here. You can also temporary block upgrades; this will override any upgrade windows:

We will end this scenario by illustrating an application owner scenario. As the application owner, create your own upgrade window:

$ supctl do login [joe@app-team.com](<mailto:joe@app-team.com>)
password:
Login successful

$ supctl create site-profiles <<EOF
name: app-weekend-upgrade-window
    application-upgrade-windows:
      - days-of-week: Saturday, Sunday
        start-time: 01:00
        timezone: site-local
        duration: 2h
EOF

Then, you can assign that window to a site;

The resulting view for the application owner will now be:

And if you combine these two windows the resulting time frame will be 01:00 – 02:00.

Read more in our documentation on upgrade windows.

Edge Enforcer updates

The above described the new feature to control upgrade windows for deploying applications. There is another window controlling when the Avassa Edge Enforcer, “supd” is allowed to be updated. This feature has been available for a while but is worth mentioning in this context. We have also enhanced the User interface to show Edge Enforcer maintenance windows.

Avassa typically updates the Edge Enforcer with a weekly cadence. All edge sites are automatically updated. During the update, there will be a small window ( < 1 minute) where API endpoints are not responding since the old version is stopped and the new one is starting. This has no impact on the running of deployed applications.

Upgrades can be controlled using maintenance-windows. That is another section of the site profiles called maintenance-windows (in contrast to application-upgrade-windows).

The below example shows a site profile where applications can be upgraded nightly on weekdays and the Edge Enforcer one hour earlier:

 $ supctl create system site-profiles <<EOF
    name: week-day-update
    application-upgrade-windows:
      - days-of-week: Monday, Tuesday, Wednesday, Thursday, Friday
        start-time: 04:00
        timezone: site-local
        duration: 1h
    maintenance-windows:
      - days-of-week: Monday, Tuesday, Wednesday, Thursday, Friday
        start-time: 03:00
        timezone: site-local
        duration: 1h
EOF

If you check the details section of your site, you will see information on supd and any potential maintenance windows:

A Quick Note on Site-Profiles

Above we have shown how to control application upgrades and Edge Enforcer updates. These are controlled through the site profiles. A site profile has “two legs”

• maintenance-windows: controlling the Edge Enforcer updates
• application-upgrade-windows: application upgrades

User Interface to Show Resource Profiles

The Avassa platform supports fine-grained resource control. You can control the usage of resources like CPU, disk, memory, volumes, GPU, and more. Control can be associated with the system as a whole, sites, or hosts.

We have now added functionality to see assigned resource profiles in the Web UI.

First, let us create a resource profile using the command line:

$ supctl create system resource-profiles <<EOF
name: large
memory:
  memory-limit: 8GiB
  container-memory-default: 4GiB
cpus:
  cpus-limit: 4.0
  container-cpus-default: 2.0
  cpu-shares-limit: 2048
  container-cpu-shares-default: 2048
container-storage:
  container-layer-storage-limit: 500MiB
  container-layer-size-default: 100MiB
device-labels:
  - name: camera
gpu-labels:
  - name: nvidia
system-volumes:
  - name: host-volumes
EOF

Then, you can assign that profile to a site:

Now, viewing the site, there is a new tab, “Profiles,”which shows assigned profiles.

Developer Tutorial

The Avassa system starts with a containerized application “as input.” It is developed, tested, and finally described in a YAML application specification and then ready to go. Your CI/CD pipeline normally adds the new or updated application to the Avassa system. But what about the application development? Is there any guidance and best practices available? Yes

We have added two tutorials on the development process itself:

• Developing and deploying a Python Application
• Developing and deploying a Python Application – Dev/Test

The first tutorial shows how to

1. build a Docker image from a Python application
2. publish the image to a registry
3. testing the application locally
4. deploying it to the edge

The second tutorial shows a slightly more advanced application using some Avassa API calls. Using that as a base, the tutorial explains how to test the application against the Edge Enforcer running on the same machine or the network.

💡 I will also take this opportunity to point to our solution for Edge AI. With Avassa, you can life-cycle your trained models at the edge. In many circumstances, the “Deploy” phase is forgotten in AI. Once you have trained your models, how do you get them to run at the edges, monitor them, and upgrade them? Containers are the perfect form factor to tackle those challenges.

To wrap things up, can you even mention maintenance without quoting something from “Zen and the Art of Motorcycle Maintenance?” NO

“Quality…you know what it is, yet you don’t know what it is. But that’s self-contradictory. But some things are better than others, that is, they have more quality. But when you try to say what the quality is, apart from the things that have it, it all goes poof! There’s nothing to talk about. But if you can’t say what Quality is, how do you know what it is, or how do you know that it even exists? If no one knows what it is, then for all practical purposes it doesn’t exist at all. But for all practical purposes it really does exist.”

Robert M. Pirsig, Zen and the Art of Motorcycle Maintenance