| [10:00:51] | * Yaazkal has joined #aegir |
| [10:02:39] | * gusaus has joined #aegir |
| [10:10:54] | * freiheit has quit (Quit: Leaving.) |
| [11:50:00] | * realityloop has quit (Ping timeout: 268 seconds) |
| [11:56:10] | * mstenta has quit (Quit: Leaving.) |
| [12:04:35] | * realityloop has joined #aegir |
| [12:43:46] | * msound has joined #aegir |
| [12:51:55] | * gusaus has quit (Quit: gusaus) |
| [13:23:16] | * msound has quit (Quit: This computer has gone to sleep) |
| [13:24:02] | * msound has joined #aegir |
| [13:29:12] | * shaneonabike has quit (Quit: Leaving.) |
| [13:30:31] | * sierkje has quit (Ping timeout: 268 seconds) |
| [13:32:57] | * Egyptian[Home] has quit (Ping timeout: 255 seconds) |
| [13:42:10] | * msound has quit (Quit: This computer has gone to sleep) |
| [13:42:52] | * msound has joined #aegir |
| [13:55:25] | * msound has quit (Quit: This computer has gone to sleep) |
| [14:52:34] | * sierkje has joined #aegir |
| [15:01:50] | * ivanjaros has joined #aegir |
| [15:02:29] | * gusaus has joined #aegir |
| [16:06:35] | * David_Hernandez has joined #aegir |
| [16:17:05] | * ivanjaros has quit (Quit: https://drupal.org/user/135190) |
| [16:26:16] | * Yaazkal has quit () |
| [16:31:05] | * boshtian has joined #aegir |
| [16:55:44] | * ivanjaros has joined #aegir |
| [17:36:46] | * sierkje has quit (Ping timeout: 250 seconds) |
| [17:41:28] | * sierkje has joined #aegir |
| [17:50:47] | * sierkje has quit (Read error: Connection reset by peer) |
| [17:54:50] | * rominronin has joined #aegir |
| [17:54:54] | <rominronin> | hi |
| [17:54:54] | <hefring> | yo |
| [17:55:57] | <rominronin> | I’d like to investigate Aegir’s compatibility/suitability for multi-site drupal installations. Any pointers? |
| [17:58:39] | * rominronin has quit (Quit: rominronin) |
| [18:00:48] | * rominronin has joined #aegir |
| [18:04:56] | * e-anima has joined #aegir |
| [18:27:29] | * gandhiano has joined #aegir |
| [18:50:31] | * ratioweb has joined #aegir |
| [19:15:42] | * fufroma has joined #aegir |
| [19:17:48] | * fufroma_ has quit (Ping timeout: 250 seconds) |
| [19:18:57] | * gusaus has quit (Quit: gusaus) |
| [20:13:42] | * Egyptian[Home] has joined #aegir |
| [20:22:51] | * mstenta has joined #aegir |
| [20:28:40] | * johnstorey has joined #aegir |
| [20:32:22] | * johnstorey has left #aegir () |
| [20:38:46] | * gandhiano has quit (Ping timeout: 240 seconds) |
| [21:09:31] | * Egyptian[Home] has quit (Ping timeout: 265 seconds) |
| [21:10:11] | * David_Hernandez has quit (Quit: :wq!) |
| [21:12:13] | * mstenta has quit (Quit: Leaving.) |
| [21:42:11] | * vantage|work has joined #aegir |
| [22:04:37] | * msound has joined #aegir |
| [22:17:44] | * zombiebeard has joined #aegir |
| [22:18:17] | * shaneonabike has joined #aegir |
| [22:36:06] | * boshtian has quit (Ping timeout: 255 seconds) |
| [22:42:16] | * boshtian has joined #aegir |
| [22:42:56] | <ergonlogic> | rominronin: Aegir is built entirely around Drupal's multi-site. In fact, it doesn't currently support installation into the 'default' site |
| [22:59:17] | * zz_drakythe is now known as drakythe |
| [23:09:48] | * ivanjaros has quit (Quit: https://drupal.org/user/135190) |
| [23:16:44] | * msound has quit (Quit: This computer has gone to sleep) |
| [23:51:03] | * ivanjaros has joined #aegir |
| [00:17:52] | * rominronin has quit (Quit: rominronin) |
| [00:25:46] | * msound has joined #aegir |
| [00:39:12] | * David_Hernandez has joined #aegir |
| [00:40:19] | * thunderWilly has joined #aegir |
| [00:40:59] | * e-anima has quit (Ping timeout: 264 seconds) |
| [01:34:44] | * vantage|work has quit (Quit: ChatZilla 0.9.92 [Firefox 41.0.1/20150929144111]) |
| [01:43:49] | * David_Hernandez has quit (Quit: Saliendo) |
| [01:52:10] | * ratioweb has quit (Ping timeout: 240 seconds) |
| [01:55:17] | <rlnorthcutt> | @rominronin you might check out Omega8’s “BOA” project which allows you to easily setup a production ready Aegir environment on a vanilla server, and keep it maintained |
| [01:55:27] | * Aaron-S has joined #aegir |
| [01:55:35] | <rlnorthcutt> | the DevShop variant of Aegir is also worth investigating |
| [01:57:31] | * freiheit has joined #aegir |
| [02:12:10] | * boshtian has quit (Quit: boshtian) |
| [02:13:57] | * pyrat has quit (Quit: ZNC - http://znc.in) |
| [02:16:55] | * johnstorey has joined #aegir |
| [02:18:17] | * manningx has joined #aegir |
| [02:35:11] | * johnstorey has quit (Quit: joining all red shirts in their final fate) |
| [03:01:50] | <Aaron-S> | ergonlogic: we have a setup with aegir currently - load balancer -> 4 varnish tiers -> drupal install server01 |
| [03:02:04] | <Aaron-S> | wondering how we can have same setup with server02 |
| [03:02:17] | <Aaron-S> | so if 01 falls down we have it up looking at 02 |
| [03:39:02] | * gusaus has joined #aegir |
| [03:40:35] | * gusaus has quit (Changing host) |
| [03:40:35] | * gusaus has joined #aegir |
| [04:02:57] | * Peuc2 has joined #aegir |
| [04:16:02] | * msound has quit (Quit: This computer has gone to sleep) |
| [04:52:33] | * e-anima has joined #aegir |
| [04:52:36] | * thunderWilly has quit (Ping timeout: 264 seconds) |
| [05:18:23] | <ergonlogic> | Aaron-S: Either the web cluster or webpack modules can work in this scenario |
| [05:19:40] | <ergonlogic> | Varnish needs to be configured with multiple backends |
| [05:19:59] | <ergonlogic> | each backend pointing to a remote server in the cluster/pack |
| [05:20:44] | <ergonlogic> | the main difference between the cluster and pack implementation comes down to how we sync codebases and files between the servers |
| [05:21:40] | <ergonlogic> | in the webpack module, we use NFS to mount the platforms directory across all servers in the pack, thus giving both a shared codebase, and common file repository |
| [05:22:09] | <ergonlogic> | in the cluster module, we rsync the platforms and site code out to the remote servers |
| [05:22:31] | <ergonlogic> | the site's files have to be handled separately, such as via S3 |
| [05:23:49] | <ergonlogic> | the latter becomes a requirement if you want your HA system to have web servers in geographically disparate datacenters |
| [05:24:17] | <ergonlogic> | since NFS and derivatives don't handle sync'ing across WAN links very well |
| [05:30:05] | * gandhiano has joined #aegir |
| [05:37:50] | * Peuc2 has quit (Quit: Konversation terminated!) |
| [05:38:02] | * Peuc2 has joined #aegir |
| [05:51:51] | <viashimo> | has anyone ever seen an aegir 1.x queue thousands of backup instances for each site? |
| [05:52:06] | <viashimo> | backup tasks* |
| [05:54:28] | <gboudrias> | ergonlogic: I've been looking into this recently, is there any development regarding Aegir intercommunication? (Was that what we called "smart nodes"?) |
| [05:55:26] | <ergonlogic> | viashimo: I've never seen that |
| [05:55:51] | <ergonlogic> | gboudrias: into what, exactly? |
| [05:56:15] | <ergonlogic> | "smart nodes" refers to having things like drush/provision installed on the remote |
| [05:56:38] | <ergonlogic> | along with aliases stored locally, etc. |
| [05:56:39] | <ergonlogic> | iirc |
| [05:56:57] | <ergonlogic> | it was never fleshed out in a lot of detail, as far as I recall |
| [05:57:57] | <gboudrias> | Yeah pretty much that. I'm trying to make isolated servers (so as to allow the client SSH access) on which we can deploy sites/platforms from the remote Aegir's interface. |
| [05:58:43] | <gboudrias> | Multiserver almost does it but not quite |
| [05:59:31] | <ergonlogic> | what's missing? |
| [06:00:22] | <gboudrias> | It needs to not be touching the site, since the rsync will erase any local modifications |
| [06:00:53] | <ergonlogic> | 'it'? |
| [06:01:07] | <gboudrias> | Well, the Aegir server |
| [06:01:55] | <gboudrias> | I'm thinking on mounting the site's folder on NFS on both servers, which would work, but that feels more like a workaround |
| [06:02:07] | <ergonlogic> | remotes are canonical for some stuff |
| [06:02:45] | <ergonlogic> | where would the files actually reside then? |
| [06:03:00] | <gboudrias> | Anywhere, remote NFS server presumably |
| [06:03:23] | <ergonlogic> | webpack works by mounting the files from the master onto the slave, iirc |
| [06:04:15] | <gboudrias> | It sort of needs to be the exact opposite acually. The remote server (the apache server) should be canonical. In our use case anyway. |
| [06:04:39] | <ergonlogic> | well, if it's shared via nfs it doesn't really matter |
| [06:05:02] | <gboudrias> | right |
| [06:05:15] | <ergonlogic> | so maybe try single node webpacks |
| [06:05:22] | <gboudrias> | Alright thanks |
| [06:06:38] | <gboudrias> | (I hadn't realized you can have a single node) |
| [06:09:11] | <ergonlogic> | I don't know that you can |
| [06:09:17] | <ergonlogic> | but it's worth a shot :) |
| [06:09:32] | <ergonlogic> | Provision_Service_http::fetch() is where that sync is happening |
| [06:09:53] | <ergonlogic> | and provision_drupal_push_site() |
| [06:10:44] | <ergonlogic> | I'm not exactly sure what is considered canonical where |
| [06:11:18] | <ergonlogic> | but perhaps a new sub-service of http could be added that ensures that the remote is canonical |
| [06:12:05] | <Aaron-S> | ergonlogic: per earlier - file syncing is not the problem - what do we do with the databases for each site since aegir spins them up on a defined server - master/master replication doesn't work for us |
| [06:13:01] | <ergonlogic> | replication should be handled transparently to Aegir |
| [06:13:20] | <ergonlogic> | at the mysql level |
| [06:14:42] | <ergonlogic> | on an AWS deployment, for example, I have an RDS instance that is handling it's own master/slave replication and fail-over |
| [06:15:01] | <ergonlogic> | that instance is simply a db server, as far as Aegir is concerned |
| [06:15:13] | <Aaron-S> | how does that work? we want site A to be on server1 and the content edited there - replicated over to same-site A in server2 with it's own db |
| [06:15:48] | <ergonlogic> | that seems contradictory |
| [06:16:03] | <ergonlogic> | if there sites have 2 dbs, they're 2 sites |
| [06:16:07] | <Aaron-S> | we have 100+ sites |
| [06:16:19] | <Aaron-S> | each spun up by aegir |
| [06:16:23] | <Aaron-S> | with the same codebase |
| [06:16:27] | <Aaron-S> | for ease of updates |
| [06:16:48] | <ergonlogic> | ok.. |
| [06:16:52] | <Aaron-S> | our eh hem...bosses |
| [06:17:08] | <Aaron-S> | want a duplicate of everything in case the server falls over |
| [06:17:19] | <Aaron-S> | but they want it load balanced and live |
| [06:17:24] | <Aaron-S> | not just a hot backup |
| [06:17:48] | <ergonlogic> | then you need to configure the mysql master/master replication yourself |
| [06:17:55] | <Aaron-S> | that is what i thought |
| [06:18:08] | <Aaron-S> | not in my work group, and they can't seem to work it ha |
| [06:18:25] | <Aaron-S> | they insisted aegir supported that |
| [06:18:28] | <Aaron-S> | i said, it doesnt |
| [06:18:29] | <ergonlogic> | I mean, you can just put the mysql on a separate server, and the web nodes will fail-over just fine |
| [06:18:54] | <Aaron-S> | our problem was, something someone ran crashed php on the server |
| [06:19:01] | * shaneonabike has quit (Quit: Leaving.) |
| [06:19:04] | <Aaron-S> | so all non-cached content went down |
| [06:19:33] | <ergonlogic> | ok |
| [06:19:40] | <Aaron-S> | so they want to avoid that |
| [06:20:10] | <ergonlogic> | I'm not sure HA is really going to help there |
| [06:20:23] | <Aaron-S> | I said that we can replicate everything onto another server, and use feeds to pull the content from 1->2 |
| [06:20:25] | <ergonlogic> | maybe better testing/staging |
| [06:20:39] | <Aaron-S> | then mask the urls site-a = site |
| [06:20:49] | <Aaron-S> | so they can be load balanced and aegir treats them like site and site-a |
| [06:21:53] | <ergonlogic> | you want two completely separate servers with the same content on each, but no shared file-system ot shared db? |
| [06:22:39] | <gboudrias> | ergonlogic: Yeah I was thinking of doing that but at that point why not just extend hosting_services to allow Aegirs to "talk" to one another, that might kill two birds with one stone |
| [06:22:45] | <ergonlogic> | to avoid someone deploying broken php code? |
| [06:23:29] | <Aaron-S> | work at a univeristy with two datacenters, all our content to 25k+ students must be available at all times....so we have a elearn system, portal and the like that are load balanced on web tiers |
| [06:23:34] | <Aaron-S> | they want to apply that to drupl as well |
| [06:23:40] | <Aaron-S> | i told them easier said than done |
| [06:23:51] | <gboudrias> | (I'll think about this some more and maybe get some feedback from @develop) |
| [06:24:04] | <ergonlogic> | load-balancing the web tier is well-supported |
| [06:24:25] | <Aaron-S> | sharing a db is not welcome |
| [06:24:28] | <ergonlogic> | gboudrias: yeah, not sure... |
| [06:24:50] | <ergonlogic> | how is that handled for non-drupal sites? |
| [06:25:22] | <Aaron-S> | non drupal sites live on VM's |
| [06:25:39] | <Aaron-S> | that can be replicated and load balanced |
| [06:25:44] | <Aaron-S> | our drupal sites are load balanced |
| [06:25:49] | <Aaron-S> | with varnish |
| [06:26:05] | <ergonlogic> | but how would a db be replicated, then kept in sync in that scenario? |
| [06:26:34] | <ergonlogic> | are these mostly static sites? |
| [06:26:36] | <Aaron-S> | they are self contained |
| [06:26:40] | <Aaron-S> | but mostly static |
| [06:27:52] | <ergonlogic> | keeping content in sync between two drupal sites from within drupal is a recipe for disaster, imo |
| [06:30:23] | <ergonlogic> | the correct solution here, if you want redundancy at the db level, is to do replication at the db level |
| [06:30:38] | <Aaron-S> | right |
| [06:31:04] | <Aaron-S> | that is what I was expecting to hear |
| [06:31:16] | <Aaron-S> | but had to do my due diligence |
| [06:31:48] | <ergonlogic> | there's really no other reasonable way to keep it in sync |
| [06:32:21] | <ergonlogic> | and, no, aegir won't configure replication between mysql servers |
| [06:32:25] | <ergonlogic> | or anything like that |
| [06:32:30] | <Aaron-S> | boom |
| [06:32:34] | <Aaron-S> | copy and pasted |
| [06:32:35] | <Aaron-S> | thanks |
| [06:32:50] | <ergonlogic> | it also wouldn't resolve the problem of someone deploying broken php |
| [06:32:58] | <ergonlogic> | fwiw |
| [06:33:13] | <Aaron-S> | there is always a more clever idiot |
| [06:33:22] | <Aaron-S> | can't ever stop that |
| [06:33:30] | <ergonlogic> | whereas a proper test->stage->prod workflow would |
| [06:33:41] | <Aaron-S> | right |
| [06:35:16] | <ergonlogic> | in fact, automating the replication of everything between these servers would pretty much guarantee that both would go down if broken php were introduced |
| [06:35:38] | <ergonlogic> | HA solves a different problem |
| [06:41:43] | <ergonlogic> | gboudrias: you might find how remote_import works interesting |
| [06:42:01] | <ergonlogic> | it has a 'remote hostmaster' service, iirc |
| [06:42:14] | <gboudrias> | Huh interesting indeed |
| [06:42:17] | <ergonlogic> | which could be repurposed |
| [06:42:24] | <ergonlogic> | maybe not though |
| [06:42:45] | <ergonlogic> | the point of the 'smart nodes' was essentially to be running remote headless aegirs |
| [06:42:59] | <ergonlogic> | or more accurately, a 'shared-head' |
| [06:44:05] | <ergonlogic> | like, the idea was to deploy a platform on a remote by calling drush make over on the remote |
| [06:44:53] | <ergonlogic> | but we'd still need to get the packages registered on the master |
| [06:46:06] | <ergonlogic> | that'd probably be the simplest first step towards smarter remotes |
| [06:46:11] | <gboudrias> | Myeah |
| [06:46:56] | <ergonlogic> | but just stopping rsync from squashing changes is an easier solution for your use-case |
| [06:47:29] | <ergonlogic> | except, even there, it'd have to just be at the site level |
| [06:48:07] | <ergonlogic> | if the client changed anything at the platform level and we sync'd that back, it'd affect any other sites on the same platform |
| [06:49:03] | <gboudrias> | I mean, that's good enough, I just hate being the only one using something :p |
| [06:49:07] | <ergonlogic> | provisionacl is another solution for shared ssh access |
| [06:49:15] | <gboudrias> | Meaning it seems like a patch |
| [06:49:24] | <ergonlogic> | like a hack? |
| [06:49:34] | <gboudrias> | yeah little bit |
| [06:49:40] | <gboudrias> | Provision ACL needs to be migrated |
| [06:49:46] | <gboudrias> | (Either way) |
| [06:50:15] | <ergonlogic> | well, I don't think making a remote site canonical is a hack |
| [06:50:33] | <ergonlogic> | especially not if it's accomplished with a new service specifically with that intent |
| [06:50:46] | <ergonlogic> | how recently did you test this, btw? |
| [06:51:07] | <ergonlogic> | I thought themes, etc were canonical on the remote |
| [06:51:46] | <gboudrias> | Multiserver? Yesterday. But maybe I tested wrong |
| [06:52:12] | <gboudrias> | Looking at the rsync code I don't know how that could be but I just skimmed it so who knows |
| [06:53:25] | <gboudrias> | Oh actually that would be in the drush rsync function, I didn't get that far |
| [06:55:16] | * mstenta has joined #aegir |
| [06:55:42] | <ergonlogic> | http://cgit.drupalcode.org/provision/commit/?id=b40b6e3 |
| [06:56:18] | <gboudrias> | wow how did I miss that |
| [06:57:11] | <ergonlogic> | what operation is squashing the remote's contents |
| [06:57:26] | <gboudrias> | oh right that's the backup |
| [06:57:27] | <gboudrias> | Verify |
| [06:57:42] | <gboudrias> | I don't know if it overrides the modules and themes actually |
| [06:57:55] | <ergonlogic> | verify is sync'ing themes/modules/etc. from the site? |
| [06:57:59] | <gboudrias> | overwrites* rather |
| [06:58:30] | <ergonlogic> | sorry, verify is sync'ing over these? |
| [06:58:38] | <ergonlogic> | with the contents from the master? |
| [06:58:59] | <gboudrias> | Yeah as far as I can tell, I actually don't understand what it's removing or not |
| [07:00:17] | <ergonlogic> | so, maybe drop a file in each of the dirs on the remote, and see what remains after a verify |
| [07:00:22] | <gboudrias> | It's in Provision/Context/server.php , in the sync function (which is called all over the place afaict) |
| [07:00:53] | <ergonlogic> | right |
| [07:01:25] | <ergonlogic> | sync() and fetch() do the same thing, but in opposite directions, iirc |
| [07:07:29] | <ergonlogic> | gboudrias: Maybe we need to merge instead of overriding 'exclude-path' here: ./platform/provision_drupal.drush.inc +126 |
| [07:10:33] | <gboudrias> | ergonlogic: I need to test some more, but it doesn't seem like themes and modules are excluded, am I missing something? |
| [07:10:57] | <ergonlogic> | no, it looks like it's only on backups |
| [07:13:23] | <gboudrias> | Right, right. It seems like it was designed more for load balancing than anything |
| [07:15:19] | <ergonlogic> | I'm pretty sure remote servers weren't introduced as dev sandboxes, if that's what you mean :) |
| [07:15:26] | <gboudrias> | Yeah :p |
| [07:16:45] | <ergonlogic> | if we merged the existing `drush_get_option('exclude-paths')`, rather than replacing it, we should be able to then set it earlier to also exclude modules/, themes/, etc. |
| [07:18:03] | <gboudrias> | Yeah but it's sort of counter-intuitive that the root of the site would get reset while modules and themes stay intact (I'm using symlinks for now and that's pretty much the behavior) |
| [07:18:42] | <ergonlogic> | this latest change comes from https://www.drupal.org/node/1079274 |
| [07:18:43] | <hefring> | https://www.drupal.org/node/1079274 => Sites data get lost on migrate or clone / dont "spoke" the site [#1079274] => 11 comments, 1 IRC mention |
| [07:19:10] | <ergonlogic> | antoine had suggested an exclusion pattern instead |
| [07:19:53] | <ergonlogic> | like, sync everything except drushrc.php, settings.php etc |
| [07:20:00] | <ergonlogic> | the stuff we generate, essentially |
| [07:21:09] | <ergonlogic> | the problem, at this point, is that if we were to change the existing behaviour it would be an API change |
| [07:21:10] | <gboudrias> | Well, that makes the "master" authoritative, changing that could be a problem for current users |
| [07:21:17] | <ergonlogic> | exactly |
| [07:21:17] | <gboudrias> | You read my mind :p |
| [07:21:28] | <ergonlogic> | so, we can add some flexibility |
| [07:21:36] | <ergonlogic> | but not chnge the default behaviour |
| [07:22:16] | <gboudrias> | Yeah, I'm curious to know if others have the same use case/problem |
| [07:22:31] | <ergonlogic> | so, a service that drush_set_option('exclude-paths', 'modules/*'...) could work |
| [07:23:00] | <gboudrias> | Right, right |
| [07:23:43] | <ergonlogic> | http://cgit.drupalcode.org/provision/commit/?id=9d9e355 |
| [07:24:00] | <ergonlogic> | maybe just run that in a pre-verify hook |
| [07:24:20] | <ergonlogic> | provision_drupal_sync_site_back() |
| [07:24:20] | * Aaron-S has quit () |
| [07:24:46] | <gboudrias> | Oh neat |
| [07:25:00] | <gboudrias> | Really neat, actually |
| [07:25:28] | <ergonlogic> | well, a bit ridiculous, really, imo |
| [07:25:55] | <ergonlogic> | we sync everything back, so that when we do all our automatic syncs after, we preserve the stuff on the remote... |
| [07:26:12] | <ergonlogic> | we just shouldn't be doing so many syncs |
| [07:26:23] | <gboudrias> | Yeah but probably not a big hit performance-wise, I'm guessing rsync is pretty smart |
| [07:26:33] | <ergonlogic> | yes, generally |
| [07:27:04] | <ergonlogic> | but when we call a backup, we end up sync'ing out the db dump |
| [07:27:12] | <ergonlogic> | then deleting it on the next sync |
| [07:27:18] | <gboudrias> | Oh boy, I see |
| [07:27:29] | <ergonlogic> | which is where the ridiculous part kicks in :) |
| [07:27:48] | <ergonlogic> | anyway, pat of the reason for a re-write in AegirNG |
| [07:28:08] | <gboudrias> | heh |
| [07:28:22] | <ergonlogic> | but regardless, I think a new service would probably be the way to go |
| [07:28:40] | <ergonlogic> | it could just implement a pre verify hook to call provision_drupal_sync_site_back() |
| [07:28:56] | <ergonlogic> | it should be pretty simple |
| [07:29:36] | <ergonlogic> | hmm, maybe |
| [07:29:50] | <gboudrias> | Do we run an automatic verify before migrates and clones? It might have to be ran before all tasks |
| [07:30:08] | <ergonlogic> | cluster works by just subsequently calling the same command on each of it's nodes... |
| [07:30:33] | <ergonlogic> | you can be selective about it |
| [07:32:10] | <ergonlogic> | so, perhaps a server service isn't the easiest way to go... |
| [07:32:42] | <ergonlogic> | oh, wait... |
| [07:32:48] | <ergonlogic> | yes it probably would work |
| [07:33:08] | <gboudrias> | Well, I still don't get what each thing was designed for (clusters VS web packs). I think I get the gist of what they do but not why. |
| [07:33:12] | <ergonlogic> | I was thinking that we'd need it to inherit from both apache and nginx, but that's irrelevant here |
| [07:33:32] | <ergonlogic> | it comes down to how to handle the files/ dir |
| [07:33:46] | <ergonlogic> | webpack uses nfs |
| [07:34:01] | <ergonlogic> | webcluster doesn't really do anything |
| [07:34:21] | <ergonlogic> | hence why I wrote hosting_s3 |
| [07:35:02] | <ergonlogic> | when you have, say, 4 web nodes that your load-balancer is spreading traffic across, you need to keep the files in sync |
| [07:35:10] | <gboudrias> | Oh yeah that makes sense |
| [07:35:31] | <ergonlogic> | so, when someone up;oad a file to web0, it also appears on web2 |
| [07:36:16] | <ergonlogic> | so, about the server service... |
| [07:36:43] | <ergonlogic> | the reason I'm suggesting it, is that this seems like something we'd want to control on a server-wide basis, but maybe not |
| [07:37:17] | <gboudrias> | Control what? The syncing? |
| [07:37:21] | <ergonlogic> | yes |
| [07:37:35] | <ergonlogic> | the extra sync back of modules, etc |
| [07:37:58] | <gboudrias> | Right |
| [07:38:38] | <ergonlogic> | it only makes sense when a site is on a remote server, for example |
| [07:38:57] | <ergonlogic> | or rather, when the platform is on a remote |
| [07:39:12] | <gboudrias> | Indeed |
| [07:49:14] | * Egyptian[Home] has joined #aegir |
| [08:02:07] | * thunderWilly has joined #aegir |
| [08:03:13] | * e-anima has quit (Ping timeout: 256 seconds) |
| [08:05:41] | * zombiebeard has quit (Quit: zombiebeard) |
| [08:07:00] | * drakythe is now known as zz_drakythe |
| [08:14:25] | * zz_drakythe is now known as drakythe |
| [08:23:52] | * drakythe is now known as zz_drakythe |
| [08:28:24] | * gusaus has quit (Quit: gusaus) |
| [08:29:32] | * gusaus has joined #aegir |
| [08:35:54] | * Yaazkal has joined #aegir |
| [08:46:10] | * thunderWilly has quit (Quit: reallife not found) |
| [08:55:15] | * gusaus has quit (Quit: gusaus) |
| [09:00:42] | * ivanjaros has quit (Quit: https://drupal.org/user/135190) |
| [09:14:20] | * gusaus has joined #aegir |
| [09:18:52] | * gandhiano has quit (Ping timeout: 246 seconds) |
| [09:26:33] | * zz_drakythe is now known as drakythe |
| [09:28:01] | * shaneonabike has joined #aegir |
| [09:36:00] | * drakythe is now known as zz_drakythe |
