CLI commands improvement prototype
This week, maas UX is focused on improving the CLI experience in MAAS. We’ve created a simple prototype in commanderJS, starting with 4 most basic commands as a proof of concept of 4 different outputs.
Our goal is to simplify the input structure and provide outputs that are more human readable. This version still needs a lot of refinement and polishing, but this is where we start.
The first command is our initial help page. By typing $maas or $maas --help, a user should receive an output that helps them get started quickly. The initial help command is broken down into subtopics to provide our users with better understanding of their action.
We’ve also introduced the concept of primary object, which in this case is machines. When a user performs an action against a primary object, they shouldn’t need to add a MAAS object as the second argument. Therefore, $maas list and $maas machine list should have the same output.
We reduced the amount of columns to these 6 columns as default, because we are aware that some users might have smaller terminal size and we’d rather not break the viewports. A user should also have an option where they can change their output format to json or yaml as well.
We’ve noticed that the singular and plural object in our current CLI can cause confusion for our users. So in this prototype $maas list would assume a collection output, whereas $maas list [MACHINE_NAME, status=[STATUS], core=[VALUES], etc] would provide a refined version of the output.
We also want to introduce a loading state to the CLI, for instance, $maas commission [MACHINE_NAME] will show a spinner while it is processing and shows a table output with a new status when it is completed.
Finally, for certain commands like deploy, where a user needs to parse a lot of arguments, we will create a more interactive experience in the CLI to help our users parse the right arguments.
Once there is error, we will try to show the error from our event log for normal mode and bring out the file system error logs on --verbose or --debug modes.
SR-IOV NUMA
Our NUMA node design is finally completed this week. After 9 design iterations and feedback collections, we’ve come to the conclusion for our designs. There are 2 important views for the NUMA aware VMs - the aggregated view and the NUMA node view.
Aggregated view:
In the aggregated view, we show the summary of our resources in one place. The resources card is broken down into RAM (with hugepages), CPU cores, virtual functions, and total VMs that are connected to the instance.
By NUMA node view:
The NUMA node view breaks down the aggregated view by NUMA node. Each NUMA node displays how much a broken down view of what is allocated and free. Besides, if hugepage memory is set, it can also show how much space in the virtual memory is allocated for it.
Your feedback is our gift, feel free to add comments, suggestions, or any cool feedbacks you’d like to share with us below!