EdgeXR Edge-Cloud Release Notes for 3.0

The EdgeXR Edge-Cloud 3.0 release offers many new features and enhancements. The following release notes cover details about these features and improvements and provide a list of known issues.

Documentation and resources can be found on our Developer Portal where we continuously publish new content and resources to help you realize the potential of our solutions and offers.

New Features on Edge-Cloud

Title

Description

Developers to join Cloudlet Pool

Developers can now become a member of a cloudlet pool based on Operator’s invitation. 

Learn more about Cloudlet Pools here.

Alert Policy

You can now set up alert policies to further monitor your applications and be alerted when applications violate those policies. Alert policies include things like CPU usage, Memory usage, Disk usage, and the number of active connections.

This feature is currently supported for Kubernetes apps only.

Learn more about Alert Policies here.

App Instance alerts

We now generate app instance alerts when the CPU exceeds the defined levels, when the memory exceeds the defined levels, or when the app instance restarts.

Learn more about App Instance Alerts here.

Alert Severity

You can now classify alerts based on severity levels.  The severity levels include info, warning, and error.

Learn more about Alert Severity here.

Monitoring Events and Usage

We have made significant enhancements to the monitoring components. In addition to collecting events and audit events for applications, clusters, and cloudlets, retrieving this data is now performed using the combined events and audits commands. Our search capabilities have been expanded with additional filter and tag options to further refine your search, and you can go from a Live view and switch view to perform a more specific search. Usage logs, which let you view application instances, across client devices, locations, etc., help you understand the application activity occurring within your cloudlets. You can also view usage logs for cluster instances and cloudlet pools.

Learn more about events and usage logs here.

Monitor Client Edge Events

You can now view client application data and usage through the Monitoring console. The data can be filtered based on application instance, location, and the type of network used.  However, no location data, user information, and devices are accessible since EdgeXR does not store that information. Only statistical aggregated data can be viewed.

Learn more about how to use and view edge events here.

Health Checks on VM

We now support application-level health checks on VMs so that when a VM is stopped, a Healthcheck Fail Server alert is sent.

Learn more about health checks here.

Helm Chart support

We now support Helm Chart v3.

See supported application types here.

Accessing GPU drivers

You can now access public GPU drivers owned by the Operator that is associated with your GPU cloudlets.

Support for vGPU


We now support GPU access.

Kubernetes clusters and GPU resource

We now support Kubernetes clusters with GPU.

Learn how to use GPUs on EdgeXR here.

Windows 10 VM image on EdgeXR Platform

Developers can deploy Windows VM on EdgeXR Platform using QCOW 2.

Learn how to do deploy Windows VMs here.

Active connections with AutoScale policy

In addition to CPU, the auto-scale policy can also be based on the number of active connections, memory, and CPU utilization to allow for scaling based on these multiple metrics.

Learn more about Auto Scale here.

Health Check and IAAS Cloudlets

Health Check will now fail if the IAAS cloudlets go down.

K8 deployment with custom namespaces

You can now provide custom namespaces for K8s deployments.

Behavior changes and enhancements

Title

Description

Flavor selection for cluster and app instances

Previously, you can select a cloudlet and flavor based on regions when you create a cluster or application instance. In this release, we have made changes so that only the flavors that support those cloudlets appear as options when a cloudlet or a list of cloudlets are selected. Further, only cloudlets that support the flavor are available in the selection list when a flavor is selected.

Two-Factor authentication

You can now turn on/off two-factor authentication.

Autoscale policy changes

We have now added UI support to configure the active connections in the autoscale policy based on the number of connections. Additionally, you can now scale by memory and CPU usage.

Learn more about Autoscale policies here.

Delete Alert Receivers

Previously when a user was deleted, the alert receiver associated with the user's name could not be deleted. Now, as an OrgAdmin, you can now delete alert receivers after the user has been deleted.

K8s pods with multiple containers

Developers can now select multiple containers using the runcommand and showlogs for application instances that have multiple containers within the pods.

Configurable support for upper limits of UDP packet sizes

You can now deploy upper limit UDP packet sizes by configuring specific UDP ports. Previously, the default UDP packet size limit was 1500, and UDP packets larger than the limit were being dropped. You can now configure specific individual UPD ports for the application to increase support for upper limit size UDP packets.

Rate Limiting

EdgeXR has enforced limitations to the number of requests you can make for API calls within a time window. Once you have reached the rate limiter cap, additional requests sent to the API are blocked. Rate limiting applies to the Master Controller and DME APIs.

The rate limit defaults for DME are as follow:

 

Per IP

Requests per second 10000   / burst size 100

All Requests

Requests per second 25000 /burst size 500

VerifyLocation All Requests

Requests per second 5000 /burst size 50

VerifyLocation Per IP

Requests per second 1000 /burst size 25

Persistent Connection

Request per second 100 /burst size 100

 

The rate limit defaults the Master Controller are as follow:

 

Per IP

Requests per second 1000.    / burst size 100

Per User

Request per second 1000 /burst size 100

All Requests

Requests per second 10000 /burst size 500

User Create All Requests

Requests per second 100 /burst size 5

User Create Per IP

Request per second 2    /burst size 2

Known Issues

Title

Description

App name is not displayed when deleting failed apps

Currently, when deleting a failed application, the name of the failed application does not appear, making it difficult to know which ones failed when performing a bulk deletion. This also applies to deleting failed clusters where the name of the failed cluster is not displayed.

This is currently no Workaround.

Using images from unauthorized repositories

While you can use images from unauthorized repositories to create app instances, EdgeXR will not scan image security.

Kubernetes manifest and image path

Currently, even though you have referenced an image path in the Kubernetes manifest, you are still required to specify the image path again in the Image Path field on the UI.

Incorrect login attempts

Currently, we do not lock out users if multiple login attempts fail. However, there is a one-second penalty delay when users input an invalid username or password, making it difficult for Bots to compromise user credentials.

VM image size limitation

Depending on the underlying infrastructure, there may be size limitations to the supported image size for VMs.

Edge Events: FindCloudlet Event

If a cloudlet with your Application Instance goes into maintenance or offline and then returns to NormalOperation, an Edge Event will not be fired even if that cloudlet has lower latency to the end device.

If an Application Instance fails a health check and then starts passing the Health check, an Edge Event will not be fired even if that cloudlet has a lower latency to the end device.

Health checks may not work with some applications

Our health check makes TCP connections to exposed ports and closes them right away. If this is unexpected from the application side, health-check should be turned off for those application ports.