React migration
The journey for our reactJS migration is still going strong. This iteration, we have been wrapping the QA work for the test tab, storage tab, and machine workload annotations. In the next release, we will be introducing the status bar at the bottom of the page.
The purpose of this status bar is to inform our users when was the last time a machine was commissioned. The timestamp information can be helpful in several ways. For instance, if you plug in a new PCI device or USB device, you will need to recommission the machine to view this information. We use relative time to communicate this information because people usually associate time with duration. When an exact timestamp is provided, our users will try to estimate their calculations to define how far it has been from today. This will reduce 1 cognitive step for our users.
MAAS as LXD tenants
Apart from moving away from our legacy code base, we are also working on another feature called MAAS as LXD tenants. In this project, the purpose is to connect MAAS with a LXD server from a project level, where a user can create a new project, compose VMs, or delete VMs without interfering with the set up in LXD.
The new KVM page will separate the table into LXD and Virsh because down the road, we will be deprecating Virsh. The LXD table will be connected via LXD addresses that allows us to see a 1-to-many relationship between the server and the connected projects.
After authenticating with the LXD server, you have an option to create a new project or select the existing project.
If a user selects an existing project, MAAS will recommission all VMs under that project.
Once you have selected a project or created a new one, you will arrive at the project tab, where you can view all VMs and look at your resources graph as a reference. Based on our research, we found that the aggregate view of the storage graph was not useful because it is more important to know the breakdown of the storage pool. So in this example, we’ve broken down the information of the storage pool. We’ve also moved all call to actions to a closer proximity to the table so that the interaction point is more intuitive. In a case where you scale your projects to support several VMs, the search and pagination will help you navigate to the right VM in a quicker manner. The table would show both the IPv4 and IPv6, as well as whether the core is pinned or not.
When composing a machine, you may also pin your cores in the UI, by providing the core numbers separated by a comma or providing a range of numbers. Our help text will also help you see which cores are currently available out of all cores. If hugepages is setup as part of the LXD server configuration, you may also enable that in the project, when you compose a new VM.
Finally, our resources page would break down overall information about how much RAM and Cores are allocated for the current project VS all other projects combined, as well as what is free. We hope this would provide a meaningful snapshot of the overall resources.
Instance tab
We are still exploring different use cases for the instance tab in our UI. If anyone views information from the instances tab (under machine summary), we would like to hear you out! Tell us about how you are currently using the instances tab:
- What information in there that is useful and what do you use it for?
- Why is this tab important to you?
- What kind of actions are you trying to perform using information on this tab?
Tell us about the instance tab in the comments section. Your feedback is a gift! Let’s improve MAAS together 