The greatest need for improving the manageability of Linux systems is to provide a standard programming interface – an API – for system management functions.
The API should be a low-level interface that provides the needed control over managed systems. It should also support a higher level abstraction, making it easy for system administrators to use it for routine tasks.
The API should support scripting and CLI use. Studies at Red Hat have shown that roughly 75% of Linux system administrators use CLI and scripts. They manage remote systems by logging in through SSH and running the CLI and scripts locally.
This API should provide both a remote interface and a local interface. It should support managing remote systems without having to directly login to each system. The API should support multiple language bindings, allowing it to be easily used from the common tools used for system management.
The API should be supported by a formal object model. Many of the idiosyncrasies of managing Linux systems are due to the organic growth of independent subsystems over time – this makes it difficult to design and provide a consistent interface.
Finally, any system management interface should be built on top of existing Linux tools and capabilities. Any attempt to build complete new subsystems from scratch is doomed by the sheer size of the task – and this doesn’t even touch the challenges of getting new tools accepted by the upstream community and users!
From a real-world perspective, note that Linux subsystems like the I/O subsystem contain tremendous amounts of “institutional knowledge” – these systems are complex because they are solving complex problems on a wide range of real world hardware. In theory, it should be straightforward to replace the I/O subsystem with a clean design. In practice, by the time a new I/O subsystem was able to do what the current I/O subsystem can do, it would be roughly as complex and ugly.
Customer feedback indicates that the greatest immediate need is to manage the physical configuration of systems, with emphasis on the ability to configure storage – especially local storage – and networks – on production servers.
A “production server” can be loosely defined as a remote system (you don’t login through a local, physical, keyboard/mouse/monitor), with no graphics (no X-windows or desktop environment installed), with multiple drives and NICs. A production server will often be configured with 4-8 NICs and may have several dozen local drives as well as network storage.
In a Nutshell
The system manageability challenge can be summarized as:
- Provide a standardized remote API to configure, manage and monitor production servers.
- Physical servers
- Virtual machines
- Supporting CLI and scripting.
- Providing language bindings for the main languages used for system management.
- Built on top of existing Linux subsystems.
- That Linux System Administrators can – and will – use.