Octopus modules in o_contrib and o_contrib_seven are symlinked on newly added platforms only when the /var/xdrago/daily.sh is run.

Currently, it happens once a day, at 6.45am (as modified by this commit: http://drupalcode.org/project/barracuda.git/commit/191ed7464d258c4fdfc5a...)

So, when you create new platforms, you have to wait the day after before using them (or do the changes by hand and re-verify the platform), otherwise you miss essential modules.

It would be good to add those actions to the creation of the platform (maybe when you execute the "verify platform" action)

Comments

omega8cc’s picture

omega8cc commented
Status: Active » Needs work
Issue tags: +BOA-todo

Nice idea, however it would require some hacking in the Provision core..

omega8cc’s picture

omega8cc commented

Boost cache dirs are created on the fly thanks to provision_boost extension. It works on site Verify when Boost is enabled.

omega8cc’s picture

omega8cc commented
Status: Needs work » Postponed
jim kirkpatrick’s picture

jim kirkpatrick commented
Version: » 6.x-2.x-dev
Issue summary: View changes
Status: Postponed » Active

This is a good enhancement... The issue where we have to build a platform, then either wait a day or manually run daily.sh out of hours is a pain. Alternatively, adding the modules provided by o_contrib to our makefile renders the BOA testing/recommended versions approach in o_contrib redundant/unused for that platform. It's a bit of a gotcha at present...

I realise this needs changes to Provision module, but I wonder if the following could be part of the way forwards:

  1. Break out the o_contrib symlinking and other related features of daily.sh into a separate script that takes a parameter for the location of the [platform root] folder, and the version of the Drupal core core we need (6, 7, 8)
  2. Put this new script (called octopus_link_contrib.sh or similar) both in the /var/xdrago folder (making daily.sh call it) AND symlink it to each /data/disk/[octopus instance]/scripts (or similar

Now at this point we can manually add the o_contrib (and related symlinks) as required when using SSH -- not exactly ideal but a step forwards when compared to having to run the whole, heavy, daily.sh script. E.g.

[logs in a Aegir/Octopus user]
o1@myserver:~$ ./scripts/octopus_link_contrib.sh '~/static/platform' '6'
Adding symlinks to important Octopus-provided modules for Drupal 6 to: /data/disk/o1/static/platform...
Done.

Now this all happens outside Provision/Aegir, which is not ideal either - but the above is cleaner than the current setup... Could we either add an auto-verify task for the platform after it runs, or use Provision to call this script instead... I'm not clear on what Provision is lacking here -- it it some kind of hook that can look for a plugins (CTools style, or actually CTools) and run those scripts? Or something else?

I'll mark this as active to solicit a comment/feedback when you have time, thanks.

omega8cc’s picture

omega8cc commented
Status: Active » Postponed

Thanks for the suggestions, but the status means that we don't work on this yet, so the issue is not "active"

omega8cc’s picture

omega8cc commented
Status: Postponed » Fixed
Issue tags: -BOA-todo

Fixed in:

https://github.com/omega8cc/provision/commit/9fdc54079a4ff6322a588a10ae4...
https://github.com/omega8cc/boa/commit/d4c2107aba74f7f26debce3225a5ac00b...

  • Commit d4c2107 on master by omega8cc: 
    Issue #1217486 by netdream - Add o_contrib symlinks (if missing) on...

  • Commit d4c2107 on master, 6.x-2.x by omega8cc: 
    Issue #1217486 by netdream - Add o_contrib symlinks (if missing) on...
jim kirkpatrick’s picture

jim kirkpatrick commented

Woop!

Status: Fixed » Closed (fixed)

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