If you use features to store exported configuration from contributed modules, you have to be very careful when updating those modules, as it's quite easy for features to "break" those modules following an update. This happens when the contributed module makes a change to its configuration schema, but the configuration exported in a feature isn't updated accordingly. A fairly common workflow of running database updates followed by importing features can cause this behavior.

For instance, anyone trying to upgrade Search API from alpha14 to alpha15, storing a search index configuration in a feature, and following this workflow will find that search is completely broken after the upgrade. This is because the search index configuration schema changed as part of the upgrade, but when you import the feature it restores a stale version of the search index config.

It would be easy to argue that this is just a workflow issue, e.g. developers need to be more vigilant when updating contributed modules, but I think it's not an obvious problem and a lot of folks are going to overlook it. It would be better if there were some automated way of preventing this, whether it's in Features or core. Maybe config "schema versions", so that you can't accidentally overwrite a new configuration with an older one? Automated tests that features runs after database updates to detect config schema changes? I'm not really sure. But it's a really painful corner of configuration management that we need to figure out.

Comments

Dane Powell created an issue. See original summary.

mpotter’s picture

mpotter commented
Status: Active » Fixed

Yes, this has always been a tricky issue and isn't new to the D8 version. I think people just didn't encounter it as often in D7 because mostly modules were stable and not making config schema changes. But I've certainly run into those cases in D7 as well.

This is one of the reasons D8 Core doesn't let you "re-import" config from a module without uninstalling the module first. Since Features lets you violate this and re-import config at any time you are correct that this can break a site.

I like the idea of "schema versions" but that is something that would need to be added to Drupal core and not to Features. Each *.yml config file would need to contain the schema version that was used to export it.

Core has this same problem really. If you do a full site export, then update your modules and cause a schema change, and then do a full site config import, it will also break (same as your search api example).

I think normal developer workflow should usually catch this however. At least in my workflow, when I update a module I always do a "features-list" and examine any feature that has a difference/override before I do a feature-revert. Since Features is considered a developer module for use on Dev/Staging/QA, this kind of issue would be detected and then the feature could be properly re-exported with the correct schema before anything happens on production.

So yes, it's another danger of relying on something like "features-revert-all", which is why we initially didn't want to have that.

Going to mark this as answered because I think this issue is beyond the scope of Features and more of a core CM discussion.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

geerlingguy’s picture

geerlingguy commented

Going to mark this as answered because I think this issue is beyond the scope of Features and more of a core CM discussion.

@Dane / @mpotter - Do you know if there's any discussion around this in the core issue queue already? It does seem to be a problem that more people are running into in D8.

danepowell’s picture

danepowell commented

I've tried to capture my thoughts on this and several other closely related problems here: #2869910: [META] Ensuring config export integrity