Hi,

Barracuda provides a great way to get a sever set up to serve high performance Drupal site effectively. However, it's designed primarily to be an Aegir master, right? What about using Barracuda to set up remote Aegir slaves? Essentially this would be a cut down version of Barracuda, or rather, Barracuda without Aegir. Can Aegir be made an optional component as part of the installation process?

So much work has gone into the performance aspect of Barracuda, but would you really want to use an Aegir master server for production sites? I would have thought it would be more likely that you would want a dedicated Barracuda/Aegir master which would be used as a dev/staging server, and one or more remote Barracuda slaves - which would just have the stuff necessary to serve the live Drupal sites...

Comments

omega8cc’s picture

omega8cc commented
Category: support » feature
Status: Active » Closed (won't fix)

There were some discussions about it already and we even added it to the TODO: http://drupalcode.org/project/barracuda.git/blob/HEAD:/TODO.txt#l14

However, all this remote heads logic in Aegir is really broken stuff, with many bugs and we never considered it production-ready.

Furthermore, there seems to be a consensus now that that this part of Aegir needs to be totally rewritten to get it really working, and it will introduce the mesh model, as explained in the Aegir roadmap: http://community.aegirproject.org/roadmap/2.0#From_a_hub-spoke_to_a_mesh.... See also http://community.aegirproject.org/discuss/back-vacation.

This means that all of this will change dramatically and we really don't want to support current broken model, only to be forced to support migration from hub/spokes to the mesh model.

Because of this, we don't plan to introduce any support for remote heads in the current model.

Of course you can still use Barracuda to create remote heads and configure them manually, as having Aegir installed also on the remote head doesn't hurt.

Also, our main (and only, so far) target audience is a one-server installs. This is why Octopus exists, by the way. Don't confuse BOA design idea with Aegir multiserver stuff.

mrfelton’s picture

mrfelton commented

Thanks for that information. I've actually ben using the remote heads feature of Aegir with great success for some time now. There were definitely some major problems early on, but most if not all seem to have been resolved now. I understand there may be a more fundamental problem with the design though, and so understand your decision to not suport this for the time being.

I'm quite happy to use Barracuda to provision a remote head, manually disable the Aegir virtual host, and make any other alterations necessary to get it working nicely as a remote head. It seems like a better option than provisioning a remote head from scratch, and ending up with things configured very different to the dev server. I'd rather have as much consistency as possible between the Aegir master and our production remote heads.

I was aware about the plan to move from a spoke/hub model to a mesh model, but this has been a discussion point for quite some time, and I wonder how long it may be before this is a reality.

I'm interested in your comment "Also, our main (and only, so far) target audience is a one-server installs. This is why Octopus exists, by the way. Don't confuse BOA design idea with Aegir multiserver stuff."

What's the reason you have been/are focusing on one-server installs? Would you say that I'm wrong in saying that it makes most sense to have Aegir running on a dedicated Aegir server, with production servers elsewhere?

And yeah, I'm aware of the difference between the BOA design with the Aegir multiserver stuff. We don't actually use Octopus at all at the moment, and simply use Barracuda's Aegir master to host all of our own platforms, but generally we have one Barracuda server devoted to one client, so we don't have the need for the more fine grained access controls that Octopus can offer.

mrfelton’s picture

mrfelton commented
Status: Closed (won't fix) » Postponed

Shouldn't this be marked as postponed rather than won't fix - since it is still on the agenda, just not right now? It might help others to find information on this topic more easily. I know it can be tempting to mark stuff as closed to keep a nice empty issue queue though, and of course, you're free to run your issue queue any way you please!... just a suggestion!

omega8cc’s picture

omega8cc commented
Status: Postponed » Closed (won't fix)

Thanks for your comments, however since the original request was not about remote heads support in general, but about an option to skip Aegir install when installing Barracuda, the correct status is not 'postponed' but closed (won't fix).

Also note that in your original request you do seem to confuse the Master/Satellite concept in BOA with Master/Slave concept for remote heads in Aegir - you wrote: "However, it's designed primarily to be an Aegir master, right?", and the answer is: no, it is completely different concept and in fact we discourage using the Aegir Master Instance created by Barracuda for anything, and instead encourage people to use Octopus instances.

We are focused on the one-server installs because this is how it works for 99% of BOA users. Plus, the remote stuff is not production ready in our opinion. Plus, it was our design decision to focus on the easy to use stack 'for masses' and not on custom setups involving remote heads or clusters.

BOA is a "consumer" level project, not "corporate" level, so it is beyond the scope of the project to support remote (slave) heads or clusters.

Note also that the upcoming "mesh" model will be in fact easily supported by standard BOA instances, maybe with some minor tweaks only, as BOA is in fact a kind of another "mesh" model already, just working on the same machine or VM so far.

mrfelton’s picture

mrfelton commented

When I said " it's designed primarily to be an Aegir master" - I simply meant that it's designed to power production sites on the same server as Aegir itself. I would consider this as an Aegir master server (it would be the controlling body for any remote heads that were attached to it) - there just aren't any remote slaves to this master. Before posting this I had thought that there may be a way to use Barracuda as an Aegir master, with other Barracuda instances connected as Argir slave servers. Now I know that's not the case, it doesn't really make sense to refer to it as an Aegir master - not unless I connect some remote heads to it myself anyway.

Why do you discourage people from using the Aegir Master Instance created by Barracuda, and instead suggest that they user the Octopus instances? If you only have a selection of sites all for the same client, doesn't this just add another Layer of complexity? What does using an Octopus instance offer over and above the access controls that you get by the segregation of sites from one Octupus instance to another?

omega8cc’s picture

omega8cc commented

Just to make it clear: we do intend to support remote *database servers* already, so you could scale up the BOA instances in this regard, as it can work out of the box without using remote web server heads, which are the broken stuff in the Aegir hub/spoke model. There is an issue about it in the queue: #1221004: Support for remote database server.

omega8cc’s picture

omega8cc commented

Well, you *can* use Barracuda as an Aegir master, with other Barracuda instances connected as Aegir slave servers, if you wish. It will work, as there is nothing special preventing you from doing this as you can do with any standalone, manual Aegir + heads installs.

But we don't plan to support it out of the box, for reasons listed above.

omega8cc’s picture

omega8cc commented

Regarding Octopus over Barracuda recommendation - It is quite simple - Octopus gives you nicely preconfigured Aegir instances, with improved UX, even if you will skip all its platforms available to install, while Aegir Master Instance gives you just standard vanilla Aegir and you need to read the docs at c.a.o to even start using it.

It is all about user experience.

Also, as this is intended for "consumer level" users, it needs (and is) to be safe to break Octopus instance and move all its platforms and sites to another Octopus instance on the same server in a matter of a few minutes, while when you will break your Aegir Master Instance, you have serious problem (and unknown downtime ahead) until you will fix it, or worse yet - start from scratch on another server, then import sites etc etc.

There are many good reasons why Octopus exists and we plan to release some nice presentation outlining all its benefits in the near future.

mrfelton’s picture

mrfelton commented

Again, thanks for the details response(s). I hadn't even installed Octopus as I figured we didn't need it, so had no idea that it had a different interface! It does make perfect sense though what you say about breaking Octopus instance vs breaking the Aegir Master Instance.

There are are some really good posts on your website as well as in the BOA drupal group about many aspects of BOA, but I haven't seen anything that goes into the details of Octopus specifically, so a presentation or write up outlining this would be awesome.

niccolox’s picture

niccolox commented
Version: » 6.x-2.0-rc9

2 years late

Is this issue worth reconsidering?

snlnz’s picture

snlnz commented

I think this would be a good idea to see a barracuda script that doesn't install Aegir by default for non multi site / production sites and various other configurations that don't include Aegir such as non Drupal sites for example.

It could be built off to host high performance single site operations where Aegir doesn't make sense.

Some options that would be nice to see as options at install time might be:
1. Web server choice of Apache or Nginx
2. Various PHP Versions
3. MySQL servers such as Percona/Mariadb as an example
4. Nginx Speed Booster or Varnish pre configured on Apache
5. Redis

It would be handy to have an optional site manager like Virtualmin or a custom site manager with less overhead for hosting non drupal sites / custom php apps etc.
Those that wish to opt in could just install Aegir, but it would be good to see what others think might be useful as an alternative.

Hope others would find this helpful?

omega8cc’s picture

omega8cc commented

There are many scripts on the net you could use to install just bare bones, but high-performance system. BOA is *not* going to turn into this direction. We may support Aegir remote servers at some point, when it will be considered production ready feature, though. And Apache or Varnish? This must be a joke! ;)

attiks’s picture

attiks commented

#11 With the current script you can do most of your list already, except for apache and varnish, but like said in #12, why would you want it.

We use a separate directory for our non-drupal sites (like piwik for instance) and add the nginx config file in an extra include directory. Works like a charm.

If you don't want to use aegir, you could remove the nginx file.

Off-topic: there are (were) plans to add support to aegir for non-drupal sites as well, but no idea what's the status is.

niccolox’s picture

niccolox commented

We use a separate directory for our non-drupal sites (like piwik for instance) and add the nginx config file in an extra include directory. Works like a charm.

I was wondering about using Webmin to make this a little easier, haven't explored that. Was looking at the CSF Webmin module and thinking about Virtualmin + Aegir BOA etc

Apache httpd is a living fossil, Hadoop is the new Apache httpd