When he says the Drupal 8 Configuration Management system is only listening to one use case?
One reason no-one listens to Nedjo Rogers on this subject is that what he’s saying is not that simple to understand. But I assure you it’s well worth the effort. He’s saying that the Drupal 8 Configuration Management system is built around a single use case that favors a certain enterprise need, namely that of single site configuration stabilization and propagation to other environments, principally live.
In his initial article on this subject (Bibliography #4, Nedjo Rogers) Nedjo wrote that the fact that “Sites own their configuration, not modules” (as stated in Bibliography #3, Alex Pott) constitutes nothing less than “a seismic shift in Drupal that’s mostly slipped under the radar”. Nedjo first reviews the history of exportable configuration in Drupal, and correctly highlights the fact that there are two main use cases involved:
-
To share and distribute configuration among multiple sites.
-
To move configuration between multiple versions of a single site.
“By and large, the two use cases serve different types of users. Sharing configuration among multiple sites is of greatest benefit to smaller, lower resourced groups, who are happy to get the benefits of expertly developed configuration improvements, whether through individual modules or through Drupal distributions. Moving configuration between different instances of the same site fits the workflow of larger and enterprise users, where configuration changes are carefully planned, managed, and staged….”
“If anything, the multiple site use case was a driving force behind the development and management of configuration exports. The Features module and associated projects – Strongarm, Context, and so on – developed configuration exporting solutions specifically for supporting distributions, in which configuration would be shared and updated among tens or hundreds or thousands of sites.”
“For Drupal 8, however, the entire approach to configuration was rewritten with one use case primarily in mind: staging and deployment. The confiugration system “allows you to deploy a configuration from one environment to another, provided they are the same site.”
If this is the case, then we really need to get to the bottom of this issue. The objective of this article is to briefly summarize the whole debate (see Bibliography), remove any items that are blurring or clouding the issue, and then underline three times those points that really deserve not being kept “off the radar” and which I hope others will delve into so that we can get a clear picture of perspectives and solutions (many of which Nedjo himself, and others, are spearheading already in third party modules; see below). It’s an important question: what’s in store for us in terms of industry-wide best practices for Configuration Management in Drupal 8, taking into account all important use cases? And it’s a question that Nedjo took the trouble to raise in the Drupal Community as far back as January, 2012. But no-one listened.
Background
To get the best possible background and footing regarding how the Drupal 8 Configuration Management system actually works I heartily recommend the presentation given at DrupalCon Latin America just a few weeks ago by Molly Byrnes and Matt Cheney (Bibliography #1). And everything is definitely centered around the huge advantages in the context of the single use case of deploying configuration from dev to live on a single site.
Also see this Drupal 8 Configuration Management doc (Bibliography #10).
This doc is cited by Alex Pott, in his series of two articles, Principles of Configuration Management (Bibliography #2-3). This is a first hand account from a Drupal 8 Core developer on the “why and how” of Configuration Management Initiative work performed over the last four years.
Part One summarizes the info found in Bibliography #10 and then gives some interesting pro-tips. We are told that Configuration should not change unexpectedly. “Put another way, if the all the runtime dependencies of the configuration are satisfied (i.e it works), then regardless of any additional modules being enabled, the configuration should not change.” One “surprise” was created by “a bug in the filter plugin” which clobbered the configuration of filter formats upon installation of any module that provides text formats. “This could cause a site owner to think they need to synchronise configuration even when nothing on the site had changed, and would give anyone reviewing a deployment more to review than necessary.” This is certainly food for thought and discussion. One asks oneself whether it would not have been better to fix the “bug” (only configuration can touch configuration) in the plugin.
The brunt of Part Two of the article, apart from an initial aside admonishing us never to include a dot in dynamic configuration keys (i.e. in a machine name input by a user), is the clarification that “Sites own their configuration, not modules”. By design, sites are protected from the “confusion” and “unpredictable behavior” that would be created by modules attempting to manage the configuration.
This sounds dangerously like saying “fortunately” modules cannot do site building. Cannot provide features, or bundles of configuration?
Perhaps the following is a work-around of some kind:
“A site owns its active configuration, not the module that provides the default configuration. If a module changes a default configuration value from true to false, it should not just go and update the active configuration, since the website might rely on that value being false. Therefore knowing which config entities the module has provided is not actually that useful. If a module changes the structure of its configuration so that existing active configuration will no longer work, it will need to write a hook_update_N function to fix the active configuration.”
The two articles together are certainly an interesting summary and “inside story” intro to Configuration Management in Drupal 8.
Debate
As we have said before, in his first article on the subject, Nedjo Rogers raises serious questions about the restrictions revealed in Alex Pott’s articles, particularly concerning the lack of support for the industry-wide configuration management standard, that of packaging abstracted (non-site-specific) configuration elements for re-use in multiple project instances, as has been prominent in Drupal history in the form of feature bundles and distributions (installation profiles). We truly need open source propagation of reusable sets of Drupal configuration, and to reclaim the power of generically abstracting solutions from single site projects with the aim of re-use, with the creation of install profiles and distributions.
There is also debate about the reasons for there being support for only the single use case of single-site configuration deployment in the first place. In all his articles, and then in a more recent one, the fascinating and breath-of-fresh-air in the Drupal community Will the Revolution be Drupalized (Bibliography #8), Nedjo puts forward the concept that undue influence on the part of big companies is the reason why. This position is hotly rejected by both Alex Pott, who feels this is by design (see Bibliography #6) and is the best solution period; and by Jess (xjm) in Contribution, Influence, and Drupal 8 (Bibliography #9) in which she disputes Nedjo’s conclusions on the subject of organizational influence.
I have my own opinion, and when time permits, well, that’s a whole other article 🙂 (as Alex Pott says). I am writing this article because I want to support Nedjo Rogers’ right to pose this problem, regardless of whether one agrees or not with his conclusions. The fact that these positions are put forward should never be used as a reason for rejecting the very serious debate concerning Drupal 8 configuration management. It would be tragic if the second debate, important and fundamental as it is, obscured the all-important configuration management debate. Let’s not allow this to happen!
Emerging Solutions
In Drupal 8 configuration management: what about small sites and distributions? Nedjo mentions two emerging non-core initiatives that may help:
-
-
“The main use case is: You update a module, and it has either changed default config that it provides, or added new config items. You want to be able to import the new items, view the differences between the site config and the changed config, and possibly “revert” (or it may be an update) to the newly-provided default config.”
-
-
-
“An initial attempt to address the use case of automated import of extension-provided configuration updates”
-
In the second article, Nedjo talks about intensive coordination with Mike Potter, the lead of the Features 8 module, for example, and many others, to work for solutions to this problem.
-
Features 3.x for Drupal 8
Some of the first efforts to provide distribution-related functionality came in the form of sketches towards a Drupal 8 version of the Features module. The sandbox module contains a small collection of methods that can be called from the Drupal command line utility Drush for editing and reverting configuration modules.
Great news: Features 3.x for Drupal 8 is being built collaboratively by Nedjo, Mike Potter, and others on the basis of Nedjo’s work, formerly in Configuration Packager. -
Configuration Development
Configuration Development provides automated import and export of configuration between the active configuration storage and exported modules.
Bibliography
-
Presentation given in February, 2015 at DrupalCon Latin America Drupal 8 CMI on Managed Workflow, (youtube video link), given by Molly Byrnes of Phase 2 and Matt Cheney of Chapter Three. (provided as excellent background on Drupal 8 CMI functionality).
-
Alex Pott (alexpott), Chapter Three, Principles of Configuration Management – Part One, December 9, 2014
-
Alex Pott (alexpott), Chapter Three, Principles of Configuration Management – Part Two, January 9, 2014
-
Nedjo Rogers (nedjo), Chocolate Lily, Tag1 Consulting, Drupal 8 configuration management: what about small sites and distributions? (response to Alex Pott’s articles), January 22, 2015
-
Nedjo Rogers (nedjo), Chocolate Lily, Tag1 Consulting, Drupal 8 and distributions part 2: problems and prospects, January 26, 2015
-
Alex Pott (alexpott), Chapter Three, Drupal 8 and the Enterprise (response to an un-named Nedjo Rogers), February 26, 2015
- Wikipedia article on the computer science term Configuration Management
-
Nedjo Rogers (nedjo), Chocolate Lily, Tag1 Consulting, Will the Revolution be Drupalized? Free Software, Dictatorship, and Saving the World, February 26, 2015
-
Jess (xjm), Acquia, Contribution, Influence, and Drupal 8, Mar 09, 2015
-
Drupal.org Overview of Configuration (vs. other types of information), last updated February 9, 2015
-
Alex Tkachev, Amazee Labs, Drupal 8 Configuration Management – Part 1, December 16, 2014
-
Alex Tkachev, Amazee Labs, Drupal 8 Configuration Management – Part 2, January 21, 2015