In many IT shops, there is a separation of storage and server management, sometimes by conscious design, politics, or happenstance. In our first school of thought, we use Puppet as a tool for the storage group to manage the storage systems and provision storage on those systems. The Puppet “device” construct allows a manifest to define the storage environment, and that definition is then pushed to the storage systems. The storage definition manifest(s) can be revision controlled and audited and by definition represent the environment at that point in time. Unfortunately, the Puppet device construct is fundamentally asynchronous to the remainder of the environment (servers).
A better way to manage an environment is holistically from an application or server perspective, which leads to our second school of thought. Here the storage, server, operating system, network, database, applications, and anything else necessary are configured as one manifest(s) chain. In this case, the framework that applies the manifest to the server also reaches out to the storage infrastructure to provision what it needs as part of the process of building the full stack.
As an example, consider the requirements for provisioning a database server: Why should there be a process executed by the storage admin and then some kind of a handoff to the server process? In a single process, the server database provisioning process can reach out to the storage, allocate what is needed, mount that storage, configure the logical volumes, create the filesystem, and mount the storage for the database. All of this can be completed in one configuration. It is assumed that the manifest would be continued and include the database installation, configuration, and any applications. One process gets the whole stack stood up. The one process can still be audited and revision controlled with tools like Git, but that will eliminate the clumsy steps between various groups that generally leads to longer provisioning times and greater likelihood of errors.