We have a rather weird hack in the /data/conf/global.inc file which disables Redis cache completely for all requests with $_SERVER['HTTP_USER_AGENT'] not set/empty, which is typical for all PHP-CLI based requests:

if (!isset($_SERVER['HTTP_USER_AGENT'])) {
  $use_redis = FALSE;
  $use_cache = FALSE;
}

The problem is that while it fixes critical issue with provisioning new Drupal 7 based sites in Aegir, it should be disabled *only and only* for new D7 sites provisioning, as otherwise it basically breaks all cache clear actions - including those performed on site cron (which is run with drush by default) and also those issued on command line directly with drush cc all.

This is a major cache logic fail and already a release blocker.

We have to find a way to disable Redis only on D7 site provisioning, since it is the only task which fails when Redis is active, while all other tasks work just fine.

Comments

jim kirkpatrick’s picture

jim kirkpatrick commented

Perhaps a control file in the sites/[sitename] directory along the lines of the .../cache/NO.txt control? e.g. sites/[sitename]/PROVISION.txt

I don't have any concept of how much caching logic this would alter but the principle is tried and tested.

omega8cc’s picture

omega8cc commented

Turning Redis completely OFF is easy, but it is rather useless possibility. It should be smart when ON and just work.

omega8cc’s picture

omega8cc commented

And no, no control file can help, as we need that switch built-in the Provision itself.

aanjaneyam’s picture

aanjaneyam commented

any breakthrough in this bug?

omega8cc’s picture

omega8cc commented

Not yet, we were too busy with all that pre|during|post-Sandy mess in NYC.

jim kirkpatrick’s picture

jim kirkpatrick commented

Firstly, I hope you and everyone your way is ok and things aren't too f***ked up by Sandy.

Just throwing a few ideas around, maybe these are helpful/inspiring, or maybe they're junk ;-)

  1. Checking IP address is local (assumes Provision request needing this switch this come from 'our' machine)
  2. Patching Provision to set a 'special' user agent string to test for (not much better than existing, but a little smarter)
  3. Setting a control file in a Provision hook for the D7 site being provisioned (a variant you ruled that out in #1-#3)
  4. Placing/checking a value in Redis to use as a switch (smells bad)
  5. Disabling Redis for all sites until they've been verified (no idea how much work/if possible)
  6. Changing the D7 install profiles/make files to set flags

I'll leave it there but sounds like patches/extensions to Provision (or related modules) are needed in one way or another. I'm a Drupal dev and would be happy to work on that side of things... Let me know if I can help out.

obrienmd’s picture

obrienmd commented

re #6, my opinions FWIW:

Checking IP address is local (assumes Provision request needing this switch this come from 'our' machine)

Seems like a bad idea, there may be many other local http requests from a Drupal instance.

Patching Provision to set a 'special' user agent string to test for (not much better than existing, but a little smarter)

I like this idea, but seems like it might be time-intensive depending on the Provision patching required.

Setting a control file in a Provision hook for the D7 site being provisioned (a variant you ruled that out in #1-#3)

I like this idea, don't know how feasible it is.

Placing/checking a value in Redis to use as a switch (smells bad)

Agree on smell :)

Disabling Redis for all sites until they've been verified (no idea how much work/if possible)

Not sure if we have access to this when global.inc is included. Also, in general, I fear how general this is.

Changing the D7 install profiles/make files to set flags

Could be a maintainability nightmare.

omega8cc’s picture

omega8cc commented
Status: Needs work » Fixed

Thanks for all suggestions!

Here is the magical fix :) http://drupalcode.org/project/barracuda.git/commit/f8489f2

obrienmd’s picture

obrienmd commented

If a request is not via drush, the first function_exists will fail, right?

omega8cc’s picture

omega8cc commented

Correct. So it disables Redis on the fly only when it is drush based provision-install command running. Exactly what we need to avoid failed D7 sites provisioning, but also to allow Redis to be active in all other tasks or on command line directly.

obrienmd’s picture

obrienmd commented

Awesome, thanks for the clarification!

tribe_of_dan’s picture

tribe_of_dan commented
Status: Fixed » Needs work

Fantastic! Thanks @omega8cc it must have been a busy few days for you all.

Is there anything preventing 2.0.4 release now? Sorry about the status change, I don't know why it did that...

jim kirkpatrick’s picture

jim kirkpatrick commented
Status: Needs work » Fixed

Fixing the status.

Status: Fixed » Closed (fixed)

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

Anonymous’s picture

(not verified) commented
Issue summary: View changes

Typo fixed.