Drupalcon Chicago - Core conversations - Content vs Configuration

Drupalcon Chicago had a track for 'Core conversations' that were discussion focused and about the future of Drupal core.

On the first day there were two sessions essentially about managing content and configuration in Drupal. They focused on the differences, similarity and possible solutions for moving content and configuration around and between sites.

Greg Dunlap started a discussion about configuration management, he suggested that we shouldn't try to define a line between content and configuration. He said that actually the problems of being able to stage content, and being able to move configuration around were essentially the same, and could be handled with similar tools. This sparked a debate about the existence of the line between content and configuration, and where that line was. Many people believed that there is a line, and others not, there was some agreement that actually there is a line, but that the line is in a different place for every site. This makes a lot of sense, for some sites certain nodes or taxonomy terms are actually configuration and integral for the functioning of the site, and for others all nodes are strictly content. Greg made the point that while a lot of people argue for making the line between content and configuration more distinct, in terms of patches and code the line appears to be blurring more and more.

Greg explained that he'd like to see 'Reliably unique identifiers' (UUID) being added to core so that pieces of content and configuration could be identified regardless of the sites or servers they are on. These should be added alongside the current primary keys in Drupal, so that we don't actually have to change a lot of code.

Later, there was another core conversation that focused more on two possible implementations of managing configuration. One approach outlined was to store all the configuration changes in a log, this could then be replayed onto other sites, so that in theory they would be kept in sync. This would basically mean that you could set something up on your dev site, and then when you were happy you could push all the changes to the config that got you there onto another site. Also in this approach settings would be more defined with a 'Settings API', which would allow settings to define dependencies and groups, in that way we could group together all settings related to your 'blog' for example. The logging element will definitely be needed for the future of Drupal core, but the approach of moving settings around by replaying a log sounds very brittle. David Strauss outlined a different approach based on BCFG and Jenkins that would see all of Drupal's config stored in JSON files in the site specific directory and cached in memory for accessing. Moving configuration changes around would then become a job for a VCS moving the json files around. This is a promising approach, but doesn't really address the separation of content and configuration, what should be saved to disk and what shouldn't? The files would define the final state of the system and Drupal would perform whatever changes were needed to bring the system to match the config files.

Some of this is very likely to get into Drupal 8. I'm excited.