Contrib.social

Proposal: Configuration Management 2.0 initiative

Open on Drupal.org →
Created on 30 March 2018, about 6 years ago
Updated 1 March 2024, 4 months ago

Problem/Motivation

Angie Byron, along with some of her co-workers at Acquia, was tasked by Dries to perform a series of interviews along with other research to try and determine what the main blockers are for Drupal 8 adoption, as well as what factors are leading to Drupal 8 being hard to use. (These findings will be part of the Driesnote at Nashville.)

They've talked to over 50 people at this point, from site builders, to developers, to support and sales people, to trainers, both enterprise-level and small-medium business level, from various points on the globe including North America, Europe, and India. From this research, they feel they've gleaned a solid set of common pain points and have some suggested next steps.

One of the common complaints was around Drupal's configuration management system. While the built-in config system is a HUGE step forward, now that the community has a couple of years of building Drupal 8 sites behind them, various limitations have surfaced: various common workflows are not natively supported; core's config APIs have missing functionality. While many of these problems have contrib workarounds, often these solutions can conflict with one another, and there's no one set of best practices that works for all.

These conclusions validate analysis by Drupal community members in 2015 about barriers posed by the original CMI focus on staging configuration on a single site (which was necessary in order to account for data consistency concerns, and to get Drupal 8 actually shipped in the first place). See also the 2012 discussion Configuration Management initiative and Drupal distributions.

An important consideration in developing this roadmap and resolving the below issues is ensuring that we can continue to manage dependencies and not break any sites; a paramount concern is care and consideration of data consistency. Problems when configuration leads to database change could curtail the solutions we can reasonably employ in core to solve these problems.

Proposed resolution

Candidate issues for the initiative are identified with using the tag CMI 2.0 candidate → .

The following table summarizes comments from this issue, and is followed by the original summary.

Overarching aim: that, in core, the use case of sharing reusable packages of configuration among multiple sites is on (at least!) a fully equal footing with that of staging configuration on a single site.

Extend the core configuration management system to handle some additional, well-trodden use cases:

  1. Allow installing a new site using existing configuration, e,g. for cloning new development environments.
  2. Allow distributions to own and update configuration; sites that use those distributions should be able to override provided configuration.
  3. Allow users to manage configuration contextually, such as per-environment (e.g. dev/stage/live), per multisite, etc.
    • Configuration split → & Config Filter → modules in contrib do this today; explore moving this functionality into core, with improved UX and DX.
    • Also explore non-configuration APIs, e.g. Services per-environment
  4. Establish a documented process for managing and deploying configuration updates that accounts for contextual configuration
  5. Provide a UI for packaging configuration (e.g. content types, roles, permissions) into modules easily, so that they may be shared among other sites. (Should this be Features module in Contrib?)
  6. Provide secure configuration storage for sensitive configuration items (e.g., API keys) that is easily swappable with services such as Lockr.io. (Like https://www.drupal.org/project/key → but generalized for any config item, not just keys.)
  7. Make configuration management errors more informative and instructive on next steps. E.g., Missing dependencies, Mis-matched UUIDs
  8. Collaborate with #2956879: Proposal: Create and promote new "Quick-start guide" pages → to create an "official" quick-start configuration management guide, covering common use cases. Related Documentation issue: #1831818: Document git config import workflow →
  9. Site user should be able to exempt (via the UI) specific configuration keys from being reverted when config is imported. ( Config_ignore → does this now, but not via a UX that is site maintainer friendly.)

Remaining tasks

  • Open issue in ideas queue for public discussion period <= we are here! :)
  • Identify coordinators(s) for this initiative, ideally with dedicated time.
  • Get product + framework management sign-off on idea
  • (After that) Develop more detailed implementation plans, including biksehedding the implementation details (in other words, please don't delve into "solution A vs. solution B" details here... ;))

Next steps to clarify proposed work could include:

  • Identify and tag "CMI 2.0 candidate" other existing issues that are also appropriate for the initiative.
  • Add more "CMI 2.0 candidate" issues for what isn't yet captured.
  • Go through the issues with "CMI 2.0 candidate" tag and fill in details of how they relate to each other--for instance, what prior issues they require.
  • Consider creating overarching issues and assigning existing "CMI 2.0 candidate" issues as children.
  • Review, edit, and improve "CMI 2.0 candidate" issues.

User interface changes

New/expanded configuration management UIs for handling the use cases above. If defined by contrib, the existing contrib modules' UIs need to be reviewed and brought up to par with a new-to-Drupal site maintainer persona in mind.

API changes

Yes? :P API additions, at any rate.

Data model changes

Unknown.

🌱 Plan
Status

Closed: outdated

Component

Proposed Plan

Created by

🇨🇦Canada webchick Vancouver 🇨🇦

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • Comment 4 months ago →
    🇦🇺Australia thursday_bw

    Updating to reflect that the Configuration installer → has been deprecated in favor of Installing Drupal from configuration (only certain profiles) →

  • Comment 4 months ago →
    🇨🇦Canada colan Toronto 🇨🇦

    It sounds like Config Enforce → could fit in here somewhere, at least as an example what's solving problems in the wild.

  • Comment 4 months ago →
    🇬🇧United Kingdom catch
  • Comment 4 months ago →
    🇺🇸United States neclimdul Houston, TX

    I'm not sure. Looking through the summary, it seems like this was about taking a fresh look at config and taking the underlying API to the next level. The initiative you linked seems to be about providing better starter configuration/profiles/recipes. I could see how updating the config API could help that but those sound like different things and the issues tagged to CMI 2.0 don't seem particularly tied to that initiatives goals.

  • Comment 4 months ago →
    🇨🇦Canada SKAUGHT

    #35
    I would agree with the overall goal that Recipes are currently progressing how config works in drupal core, providing tools 'more like' Features in Drupal7 ecosystem.

    This issue certainly does track the way contrib has responed since this issue. Recipes are in my own overview are picking up with this need.

    To mention the 'want's of this issue that I would ask around that recipes isn't handling (that i know of!). is ENV based config (config_splits) dev/uat/prod codes. Otherwise the goal of having better code side tools and UI's are part of the Recipes outlines..

    #34
    Yes, this plan 'is stale' at this time. It has great information about how to handle these types of things in d8/d9 sites/lifespan in

  • Comment 4 months ago →
    solideogloria

    Yes, I agree that ENV based config should be easier. Currently, it makes more sense to use settings.php to override config, because then I don't have to manage multiple partial configs.

  • Comment 4 months ago →
    🇨🇦Canada SKAUGHT

    Getting Involved

    We are available in the #distributions-and-recipes channel on Drupal Slack. Our meetings leverage the Slack meeting format → and happen once every two weeks on Tuesday at 1600 UTC (Noon EST). All are welcome.

    Our contrib project is at https://www.drupal.org/project/distributions_recipes → in the 10.0.x branch. We are using that issue queue to record meeting notes and child issues for each bi-weekly meeting.

  • Comment 4 months ago →
    🇨🇦Canada SKAUGHT

    #37
    Perhaps it's possible under the idea that the project would have A Recipe that you enable in that env -- as this depends on Hosting, deploys setups in that hosting. the workflow that team/project uses... etc.

  • Comment 4 months ago →
    🇺🇸United States neclimdul Houston, TX

    "I would agree with the overall goal that Recipes are currently progressing how config works in drupal core, providing tools 'more like' Features in Drupal7 ecosystem."

    Not sure what that means. For my use cases there are better versions of everything in the D8+ ecosystem so I'm just not the target audience.

    "To mention the 'want's of this issue that I would ask around that recipes isn't handling (that i know of!). is ENV based config (config_splits using its 'partial configs') dev/uat/prod codes. Otherwise the goal of having better code side tools and UI's are part of the Recipes outlines.."

    "Yes, I agree that ENV based config should be easier. Currently, it makes more sense to use settings.php to override config, because then I don't have to manage multiple partial configs."

    I use environment driven config _very_ heavily and its pretty straightforward today. Keys module is great if a little rough in the UI. Its designed for "secrets" but the model is allowing the mapping from stores to any config value so mapping from environment to any config value is easy and very powerful and has so far met every need I've had for varying settings per environment with the exception of things like enabling development features locally which still make since to manage with splits.

  • Comment 4 months ago →
    🇧🇪Belgium Wim Leers Ghent 🇧🇪🇪🇺

    @neclimdul: Sounds like you adding docs on d.o or a blog post about your approach would help quite a few people be as successful as you with it? ("pretty straightforward today" is the Drupal equivalent of "OMG it is so elegant", right? 😜)

  • Comment 4 months ago →
    🇬🇧United Kingdom catch

    I'm sure there are config issues/features that won't be covered by recipes, but do they need their own special initiative? Nothing stops people working on them.

  • Status changed to Closed: outdated 4 months ago
  • Comment 4 months ago →
    🇬🇧United Kingdom jonathanshaw Stroud, UK

    Use case: as a site administrator, I can install a new site using existing configuration so that I can for example clone new development environments

    Solved in core.

    Use case: As a site administrator I can review and safely import available configuration updates from installed modules, themes, and the install profile without overriding customizations I've made on the site

    Solved by widely used contrib Configuration Update Manager

    Use case: As a module developer or site administrator, I can produce a package of configuration that meets a distinct use case

    Targeted by Recipes initiative.

    I agree with @catch. This issue is a proposal for an initiative. It has not gained traction, and is now outdated. It clutters the issue queue and to focus attention better we should close it as outdated.

    Many issues still exist in this area, but as an initiative proposal this should be closed. If there's a new initiative other than recipes that is needed, it would do better to start from scratch as a new more focused proposal.

    If there's

contrib.social Blog FAQ Discussions
Production build 0.69.0 2024