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 the Master Controller are as follow:
|
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. |