I thought it would be a really handy feature if not one of the most important factors for us, when a BOA server is not doing what it is supposed to do, or an upgrade is available, normally we build a fresh debian box, install boa from scratch and manually migrate all of the sites across. I prefer clean installs over upgrades personally (always have) as at least you know where you stand when the install finishes and it's usually in a stable environment, particularly for production.

Upgrades have proven very troublesome and potentially broken certain functions that I've had bad luck with in the past so I avoid doing it other than on the main Barracuda instances where OS updates are available.

So I am requesting a feature or subscript for BOA, much like some of mig5's scripts for automating builds @ rackspace, installing barracuda, then octopus.

A second script would be very nice that would allow you to set the config for one server (the old/broken one) then the second server (your fresh boa instance) then the script would attempt to push every site plus it's db from old server to new.

That would save HOURS of mucking around with boa issues when they exist and is currently the way we deploy workstations in the enterprise eliminating time figuring out what's wrong and getting back to what's right very quickly very easily. It would be priceless to have this and I would be happy to contribute to development, I'm sure others would too if they knew what would come out of it!

Comments

omega8cc’s picture

omega8cc commented
Component: Code » Documentation
Status: Active » Closed (works as designed)

Well, this is why Octopus exists. You should never use Barracuda based hostmaster instance to host sites, only Octopus based, so you can "safely" break them and never need to move to another server/machine if anything seems to be broken seriously. All you need to do if you screwed for some reason your Octopus instance is to create a new one (on the same server!), copy all platforms directories from screwed to new Octopus instance, chown them to match new Octopus instance user and then add all those platforms in the new instance, so Aegir will discover and import all sites automatically, and once all of them are verified, simply delete all its vhosts on the screwed instance and reload Nginx - there is no need to export/import databases etc. It just works.

As for *anything* related to remote servers stuff, it is explained in this discussion: http://drupal.org/node/1305896#comment-5102094

omega8cc’s picture

omega8cc commented

Plus, upgrades for Barracuda itself never caused any issues for us - and we use them on all our hosted and remotely managed Aegir instances. If you are doing it from scratch every time, you are doing it wrong, as it is designed to work and in fact, it works, so expecting another script to support your wrong workflow doesn't make any sense, really.

omega8cc’s picture

omega8cc commented

Also, there are no plans to create or support any kind of "meta" installer for BOA - it also doesn't make any sense in the BOA context/design.

omega8cc’s picture

omega8cc commented

You may be interested in this new stuff: http://drupal.org/node/1407800#comment-5495392

snlnz’s picture

snlnz commented

Thanks for your reply.

That's an informative approach to resolving broken octopus instances, and since the initial post, I've had trouble free BOA operations and in fact I seem to know my way around the system very well now so don't suffer the minor issues which once plagued us.