Ubuntu 22.04 – Base OS Image
This feature is currently available in closed beta testing.
Ubuntu 22.04 is the node operating system release candidate for an upcoming self-service maintenance event that will deliver performance and reliability improvements to cluster nodes.
MedStack has completed comprehensive testing of nodes running Ubuntu 22.04 in clusters. During this closed beta testing, we are inviting users to perform acceptance testing of Ubuntu 22.04 in their staging and development environments.
Recognizing most application environments have nuances in their configuration, networking communication, and workloads, it's imperative to bring this release candidate to our customers in advance of the pending self-service maintenance activity and forced maintenance date.
While a formal maintenance date has not yet been scheduled, we anticipate the forced maintenance date for upgrading all nodes to Ubuntu will be before June 2024.
Setting Up for Testing
There are two methods by which an Ubuntu node is deployed:
- Create a new node with Ubuntu 22.04 as the base OS image
- Change the OS on an existing node to Ubuntu 22.04
1. Create a New Node
- In a cluster, click "Create Node"
- Select the size of a node
- Select the base OS image to "Ubuntu 22.04 - In Preview"
You can confirm the node size and OS in the nodes table on the cluster overview page.
2. Change OS on Existing Node
-
In a cluster, click the "Actions" dropdown button for a node and select "Change Base OS Image"
-
Select "Ubuntu 22.04 - In Preview" and click "Change"
Switching between Debian and Ubuntu
Using the "Change Base OS Image" workflow, you can switch between Debian and Ubuntu operating systems on the selected node for testing purposes.
You can confirm the node size and OS in the nodes table on the cluster overview page.
Testing Considerations
If you encounter issues or failures with Ubuntu
Rather than attempting to restore behaviour by reimaging a node back to Debian, please contact MedStack support to report any issues or failures with Ubuntu. Our team is better equipped to perform an investigation root cause analysis on resources that are left in an undesired state.
MedStack recommends performing the following test scenarios as minimum acceptance criteria.
| Category | Test Scenario | Intended Outcome |
|---|---|---|
| Interoperability | Change only the Manager node to Ubuntu while the rest of the cluster nodes are running Debian. | All cluster nodes are temporarily "NOT AVAILABLE" and then resume normal operation once the Manager has reimaged and Docker has instantiated again. Application availability and Docker volume data should exist as normal. |
| Interoperability | Change only one Worker node to Ubuntu while the rest of the cluster nodes are running Debian. | The one node is temporarily "NOT AVAILABLE" while its reimaging and then receives and starts the normal container task load. Application availability and Docker volume data should exist as normal. |
| Interoperability | Change the Manager node to Ubuntu while the Worker nodes are running a combination of Debian and Ubuntu OSs. | Once the nodes have reimaged, they should receive and start their normal container task loads. Application availability and Docker volume data should exist as normal. |
| Reliability | Change all existing Debian nodes in a cluster to Ubuntu. | Once the nodes have reimaged, they should receive and start their normal container task loads. Application availability and Docker volume data should exist as normal. |
| Reliability | Deploy a new cluster with only new nodes running Ubuntu. Deploy an application workload. | Application availability and Docker volume data should behave the same as other environments with the same configuration and data. |
| Reliability | When a "node down" event is detected on a node running Ubuntu, submit a support request for a root cause analysis. | Node down events are no longer be caused by unattended ZFS kernel upgrades. |
| Integrity | On a node running Ubuntu, run a container that reads and write data to a Docker volume. | The volume data is able to be written and read by the container. |
| Integrity | Submit a support request to restore volume data that exists on an Ubuntu node to the same node. After the request has been processed, ensure a container mounting the restored volume is running on the node. | The restored volume data is able to be read by the container. |
| Interoperability | Submit a support request to restore volume data that exists on a Debian node to an Ubuntu node. After the request has been processed, ensure a container mounting the restored volume is running on the Ubuntu node. | The restored volume data is able to be read by the container. |
| Interoperability | Submit a support request to restore volume data that exists on an Ubuntu node to a Debian node. After the request has been processed, ensure a container mounting the restored volume is running on the Debian node. | The restored volume data is able to be read by the container. |
Updated 9 months ago