Project Springfield

A smart and automated storage.

What is Project Springfield?

Project Springfield’s purpose is to coordinate the development of management APIs for each component in the storage stack: for automation, health and status monitoring, as well as sane and easy configuration. It is a scalable solution, working from a single node to large deployments with a mix of base metal, containers and VMs.

The goal is to provide the APIs needed to improve many of the existing management tools, and foster the development of new tools, for managing storage. The scope includes bare metal, containers, and VMs, at local, data center, and enterprise-level deployments. As such, Springfield should be viewed as an umbrella project, encompassing a number of sub- projects. There is not expected to be a separate binary or a library with the name “Springfield.”

Springfield was presented for the first time at Vault 2017 in a birds of a feather session.

Springfield builds upon and enhances the existing work of those projects:

OK, but what does it do?

Let’s back up for a minute and define storage management. Storage management refers to a fairly large set of functions – all of which are, of course, related to storage. Here’s a high-level list of what it entails:

The management of storage network switches is not planned, due to the lack of open source multi-vendor industry standards in this area.

Project Comparisons

Language Interfaces

  C Python DBus gobject


  controller based storage directly-acessed storage iscsi initiator notification plugins modeling high-level API


A diagram of interactions between the projects. A visual representation of the interactions between the projects, with known users of Springfield projects and the backends Springfield provides.

What project should I use?

Which project fits my requirements? Following are some examples of potential scenarios and guidance as to which of the Springfield projects is best suited for the application.

  1. I have a python script that does some lvm management including queries and stack modifications. What should I use?

    Libblockdev or blivet. Libblockdev is more direct, almost like directly replacing the lvm commands 1:1, but saving you the code for executing programs and parsing output. Blivet provides a more complete view of the system’s storage and provides a bit more leverage, but with more overhead. Lastly, lvm provides its own DBus interface for management.

  2. I have a C app that does some lvm management including queries and stack modifications and must run from the initramfs. What should I use?

    Libblockdev. Blivet is a python module and there is no python runtime in the initramfs.

  3. I have a storage management application that needs to manage local storage and receive notifications when things change on the stack. What should I use?

    Udisks. Udisks send signals via DBus whenever a new device is added or removed and can also handle most local storage management tasks.

  4. I have a storage management application that needs to manage external storage arrays or local RAID HBA or SCSI enclosure. What should I use?


So, you’d like to contribute?

Thank you for your interest! Any of the joined projects will appreciate your help, just contact them (links for your convenience: udisks, libblockdev, blivet, libstoragemgmt).

Or, if you have an idea or suggestion or if you know about another project that would benefit from this joined effort, feel free to tell us. The more people cooperating, the better the result. In that case, you can write us at The mailing list archive is at and you can subscribe here.