- From: Renoir Boulanger <renoir@w3.org>
- Date: Tue, 17 Dec 2013 10:07:45 -0500
- To: List WebPlatform public <public-webplatform@w3.org>
- Cc: List Team Webplatform Admin <team-webplatform-admin@w3.org>, Aaron Schulz <aschulz4587@gmail.com>
- Message-Id: <FFBEF507-DAB4-44DA-9062-943957E8C50E@w3.org>
Just an update on that thread. We can stop working on that issue. I suggest we resume in January. The resolution is that I installed GlusterFS the same was as the current live site on HPCloud. So, no images will be lost whatsoever. The cited components (listed at the bottom) that do not use DreamObjects is not a show stopper for this cloud-hop. We will see later to the possibility to have the components modified and migrate the data. As a <side-note />, in case you wonder about what is the difference with our current GlusterFS and DreamObjects anyway? <side-note> GlusterFS, Ceph provides the same thing: Replication of files between servers. The setup requires each web server to mount a network drive and serve the files through them (i.e. shared drive). The non components that do not support Swift (e.g. social profile) Will still use the same way as it was. Whereas with Swift/DreamObjects difference, besides the fact it uses Ceph instead of GlusterFS, is that it uses an HTTP API where supported components can POST/GET files. The improvement in this new setup is that we installed Fastly in front of it, and it’ll distribute them in their CDN for us. For example, the file: * http://docs.webplatform.org/w/images/b/b9/marcotte.jpg … is in GlusterFS, mounted drive from either app1, app2, app3, app4 * http://static.webplatform.org/w/public/b/b9/marcotte.jpg … is served only from DreamObjects because the web application had it sent there In this new way, we isolate static assets (for now, only images) from generated content and are using a separate hostname (e.g. static.webplatform.org). This will improve the site load speed because of the concurrent download limitation of the visitor web browser. Also, it will help DevOps to implement different caching strategies. Now, that some components do not use Swift/DreamObjects only means that we will either have to continue sharing a network drive, or have the components changed to use DreamObjects later down the road. </side-note> Renoir ~ On Dec 15, 2013, at 10:10 PM, Renoir Boulanger <renoir@w3.org> wrote: > Hi everybody, > > After spending some time with Aaron to help us use DreamObjects to store our file uploads in MediaWiki, we are now wondering if we forgot something behind. > > Note that the names below might not be the appropriate ones, but we think are all that there is. > > List of MW plugins that uses file upload: > 1. MW basic file upload [0] > 2. Social profile [1] > 3. GiftManager (badges, but I do not see any page that uses them)
Received on Tuesday, 17 December 2013 15:07:58 UTC