plans

Last week, before DrupalCamp Colorado, Greg "heyrocker" Dunlap, David Strauss, Larry "Crell" Garfield, and Karoly "chx" Negyesi met to hash out architectural details and whip up some prototype code for the Drupal 8 Configuration Management initiative.

What problems are we trying to solve?

• Currently there is no good way to move Drupal configuration information between environments because this data is scattered throughout the database in a variety of formats, oftentimes intermingled with content.
• This also makes it impossible to version control this information, to store history, and to be able to rollback changes.
• Every module stores their configuration data in a different format, there is no standardization at all, even within core.
• There is also no standard API for saving this information (aside from the simple case of the variables table) so developer often roll their own solutions.
• The entire contents of the variables table is loaded on each page request, even for rarely-accessed data, leading to memory bloat.
• It is cumbersome to manage information that is different between server environments for the same project (database information, api keys, etc.)

We specifically are NOT (yet) trying to solve the problem of contextual configuration; only the underlying API that handles getting/setting this configuration data and shuffling it around to different sites.

The code that was developed at the sprint as a prototype is available at http://drupal.org/sandbox/heyrocker/1145636 for your reviewing pleasure. The main things to look at are the includes/config.inc and modules/config/config.test files.

What follows is a summary of the results. Your feedback is welcomed!

This document is a proposal for a high-level gameplan for the configuration management initiative.

This is a proposed game plan for managing configuration information in Drupal 8. This is focused on config data - the kind of thing that is currently being managed by the variables system as well as more complicated items like Blocks or Views.

One of the key aspects of solving the configuration management conundrum is identifying how to uniquely identify data between servers. To this end I propose implementing UUIDs in core for the identification of content, and to provide an API through which UUIDs can be generated and added use by contrib modules. While we are still talking through many big picture architectural issues, I think that it is possible to get moving on this and several other tasks to get the real work started. So here is my proposed game plan for this, created after some discussion with Dave Hall (skwashd) who has put a lot of work recently into porting the UUID module to D7.