Hi, i've been testing "Configuration management" module. The idea behind it is wonderful and looks to me more interesting than "Features".

The problem is that if's been impossible to test it between two sandboxes. I've just tried to syncronize two sandboxes between them but trying to syncronize about 16 content types and 30 fields, 8 taxonomies, well, it's dificult to say how many resources, but a total of 478 files has not been possible since it has reached the 300 seconds of maximum execution time for PHP. Is it normal?

I have to admit that not having tutorials it's dificult to know which is the best strategy for such syncronization. I miss a video tutorial, since I believe that it only requires 6 or 8 minutes to explain a good starting strategy. Importing tar files doesn't work, and sycronizing it's too long. I don't see how to create a syncronization path for fields that are not on server B (let's say final staging server). Any idea?

All in all thanks for this super-interesting module and keep the good work :-)

Comments

dagmar’s picture

Yes, I know this is a problem. The solution would be use a batch process, #1820756: Use Batch API to import and export configurations.

Sadly is a hard thing to implement, but patches are really appreciated.

jorditr’s picture

So, the only solutions is increasing the maximum execution time? The scenario I'm exposing is no so big, and it looks to require a lot of time to execute. Which is the average time of syncronization that others are experiencing?

jorditr’s picture

Well, just in order to document it I've increased PHPs maximum execution time to 3600 seconds (1 hour) and started to test passing configurations from a sandbox site to a beta site, both running with 256 Mbs of RAM. My configuration is on a Microsoft Server and the database engine is MsSQL Server:

  • on a first attempt I've syncronized 453 files taken 8'47"
  • on a second attempt I've incresed the number of syncronizations incluiding Views and Context, which implied 647 files taken 9'54"
  • on a third attempt I've included some menus, permissions and variables, which implied syncronizing 928 files, at 14'15" the server broke, I have no real idea of how much of the syncronization effort was afforded
  • on a forth attempt I've just tried to syncronize the content types taken, 10'11" and aparently finnishing properly

Finally, my conclusion is that this procedure and the module are not operational, or that it's not working on Microsoft servers. Syncronizing looks to be a huge resources task that is it not possible to overtake completely.

I'm not sure which strategy should I follow, but my today's forth attempt which looks more an "upgrade" than a complete syncronization, has completed without being sure about how much work has been completed, since the same content types that were marked as "overriden" before the content types "Import datastore to activestore" procedure were marked as "overriden" after 10'11" of the server hard work. Now I can't guess under which circumstances my the module work or if it just conceived to pass 10 or 20 variables and a content type between two servers. Being the documentation so short I can't guess if I'm doing it right or wrong, despite my long Drupal experience, and my conclusions are not being clear enough to be able to contribute to increase the documentation, at least.

Any help or insight would be appreciated :-)

bisonbleu’s picture

Category: Support request » Bug report
Issue summary: View changes

I second this request.

I'm running a few installations on Pantheon and I keep getting timeout errors when I try to synchronize configurations:

Maximum execution time of 120 seconds exceeded includes/database/database.inc:2171

For that reason, I think it makes sense to change this issue's category to Bug report.

Fortunately, Migrating configurations between environments, the other method, works quite nicely. Although the following message seems to discourage its usage.

Importing configurations will write your configurations directly to the activestore. DO NOT USE THIS ON A PRODUCTION SITE!

Would it make sense to change it to: DO NOT USE THIS ON A PRODUCTION SITE WITHOUT FIRST BACKING UP YOUR DATABASE!

scott.whittaker’s picture

just dropping a note here that for one of my sites it takes around 25 minutes to complete a sync with no indication that anything is happening until the end. It's a somewhat large site but not so large that it requires special hosting.

jorditr’s picture

It's obvious that the module was abandoned many years ago. The idea is great, and one of the key points behind Drupal 8, but maybe it was a huge task to complete that module without more support.