While December is a month with celebrations we can not resist hammering out features. The big Christmas present is a brand-new User Interface for observing the progress and state of deployments. On the over-arching team of observability, we have also added application-centered alerts in the backend as well as in the user interface. From now on, DNS entry information is available in the application and service state. It is also possible to change pub/sub bus (Volga) topic options at run-time.
- Enhanced deployment user interface
- Application Alerts
- DNS information for applications
- Change Volga topic options
- Site maintenance documentation
Enhanced deployment user interface
Application deployments are at the heart of what the Avassa platform does. Earlier in 2022, we released observability features for the sites and running edge applications. We now wrap the site-application-deployment trinity with a brand new User Interface to inspect the ongoing deployment state.
But first, let’s sort out the semantic difference between an application and a deployment in the Avassa edge platform. A deployment refers to an application specification version and defines the conditions for where it should run; which edge sites. The state of the deployment shows the progress of the deployment across sites, whereas the state of the application shows the health of each application at each site. Consequently, the deployment state has a start and an end; in contrast, the application status is continuous. Think of the deployment as your CI/CD pipeline.
You now get a better overview of the deployment status:
To the left, you see all deployments, the number of matching edge sites, and if they were successfully deployed, (blue check-mark). Selecting a deployment will to the right show all matching sites and corresponding deployment statuses. (Note well, this does not tell if the application status is healthy or not, that is another question answered by the application observability features).
During an ongoing deployment, the view can look like illustrated below. The example shows a version upgrade of an application across the sites. In the deployment, details view you can see that 1 of 5 sites has been upgraded to version 2.0 whereas the others are being deployed.
Any errors are also clearly indicated and propagated to the top. In the example below you can see that the movies deployment succeeded at 3 out of 4 sites. You can drill down to see the details on the failing site.
The visibility into canary and rolling deployments has also been greatly improved. In the example below, we request the deployment to use a single canary site with a manual action to continue after canary deployment. This is useful since the operations team can inspect the application on the selected canary sites before proceeding with a full roll-out. After that, we request a rolling upgrade with 30 seconds interval.
You can see a summary in the deployment list:
It clearly states that 1 out of 4 sites has been successfully deployed and that we are waiting for the canary state.
In the deployment details view you can act to continue after the canary site:
Every 30 seconds a new rolling upgrade will be performed and the status is clearly indicated as shown below.
If you want to inspect the health of the application on a specific site, you can click the site to the left:
This will take you to the application view:
The latest raised alerts are shown top right in the user interface:
You can also see all alerts either by clicking the “View All” link shown above or using the Alerts menu item to the left:
This general functionality has been available in previous releases but what is added during December is:
- Application-related alerts from the topic
system:notificationsare included in the user interface. (Previously, only site-related alerts were shown here). This can for example indicates that a container has reached a disc volume threshold.
- A new alert is added covering the general case that an application changes operational state to
DNS information for applications
The Avassa Edge Enforcer runs a DNS at each site. You can inspect the DNS at a specific site by using the following
$ supctl show --site local-edge-site dns
zones: - name: default domain: edge.local-edge-site.wallan.edge.avassa.dev records: - rr: popcorn-controller-service-1.popcorn-controller 15 IN A 172.18.255.50 - rr: popcorn-controller-service.popcorn-controller 15 IN A 172.18.255.50
But you might want to see the “resulting” DNS entries from your application perspective, i.e. what DNS entries have this particular application added:
$ supctl show --site local-edge-site applications popcorn-controller service-instances popcorn-controller-service-1
name: popcorn-controller-service-1 application-version: "1.0" oper-status: running ready: true host: local-edge-site-001 application-network: ips: - 172.30.0.1/16 **dns-records: - popcorn-controller-service-1.popcorn-controller.internal. 15 IN A 172.30.0.1 - popcorn-controller-service.popcorn-controller.internal. 15 IN A 172.30.0.1** gateway-network: ips: - 172.29.255.2/24 ingress: ips: - 172.18.255.50 **dns-records: - popcorn-controller-service-1.popcorn-controller.edge.local-edge-42.wallan.edge.avassa.dev. 15 IN A 172.18.255.50 - popcorn-controller-service.popcorn-controller.edge.local-edge-42.wallan.edge.avassa.dev. 15 IN A 172.18.255.50** containers: - name: kettle-popper-manager id: 5e1ffc37b8ed oper-status: running ready: true start-time: 2023-01-10T07:42:37.952Z current-restarts: 0 total-restarts: 0 probes: startup: status: success readiness: status: success liveness: status: success
An important feature of the readiness probe, is that a service with failing readiness probe is removed / not added to DNS (in order for it not to be used by clients). If the readiness probe fails, the DNS records for the service will be removed.
Change Volga topic options
Volga is the built-in pub/sub bus of the Avassa platform. In previous releases, topic options like max size could not be changed for existing topics. That can now be done over the API using the change options operation.
Site maintenance documentation
For the November releases, we enhanced the features for the site to work autonomously taking edge events like failures and maintenance actions into account. We have now added a “how-to” on various scenarios to maintain a site. This describes tasks like replacing all hosts on a site or reinstalling a host for a site with a single host. See also another document on how to perform OS upgrades.
The sizing guide for hosts has also been extracted to a separate document.
💡 Let’s hope for a more peaceful 2023!
And did you know that the Prime Factorization of 2023 is
7 * 17^2
And how beautiful is that! 17 is a prime, but not an imaginary prime:
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.