W3C home > Mailing lists > Public > public-webplatform@w3.org > December 2013

Re: What plugins we have in MediaWiki that use file uploads

From: Renoir Boulanger <renoir@w3.org>
Date: Tue, 17 Dec 2013 10:07:45 -0500
Cc: List Team Webplatform Admin <team-webplatform-admin@w3.org>, Aaron Schulz <aschulz4587@gmail.com>
Message-Id: <FFBEF507-DAB4-44DA-9062-943957E8C50E@w3.org>
To: List WebPlatform public <public-webplatform@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?

    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.


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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:13:57 UTC