incubator-ooo-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject [CONF] Apache Community > Community Wiki Services
Date Fri, 21 Oct 2011 20:13:00 GMT
Space: Apache Community (
Page: Community Wiki Services (

Change Comment:
Add Salvage Plan in light of imminent shut-down.

Edited by T. J. Frazier:
h1. Overview

The Community wiki is hosted under the domain []
comprise some 10,000 content pages and 11,000 uploaded files (“_Current Prod_”). The wiki
is based on a standard MediaWiki package (version 1.15.1) with some 40 installed extensions. 
The wiki runs on Solaris Coolstack on a 4 core Solaris zone within a dedicated server in the
Oracle Hamburg machine room (at an average 75% us+sy load under normal working periods). 
MediaWiki supports a standard LAMP stack, and a support system has been  implemented on an
Ubuntu 10.04 LTS VM running a standard Ubuntu server minimal LAMP configuration (“_Test_”)
and this has been used to an accept dumps of the production system.  The target infrastructure
in will be an Ubuntu 10.04 LTS VM running on the Apache ESXi production environment

The MediaWiki application uses both a file system and D/B (currently MySQL) to maintain application
data. These are currently some 2.7GiB and 2.6 GiB in raw size respectively.  The
core MediaWiki software has no special-to-OOo modifications, other than the standard use of

There are various technical issues which must be addresses to enable the migration to to Apache
Infrastructure so this subsidiary page, [OOOUSERS:Community Wiki Infrastructure], provides
a baseline for this migration and details the technical options to address said issues.

h1. Task Breakdown

# Build _Test_ VM using Ubuntu VM and pull a copy of _Current Prod_ to validate. This work
will be done within the current OOo (Oracle) working practices to de-risk the migration ahead
of task 3. \[completed\]
# Set up initial build of _Target_ VM under VMware ESXi. This is a bare Ubuntu 10.04 LTS VM
configured as a “standard server” and including the Apache-standard security extension.
# Agree technical options for backup and cache acceleration on _Target_.  See [OOOUSERS:Community
Wiki Infrastructure] page for details.  \[in progress\]
# Obtain project endorsement  to transfer the application content. \[completed\]
# Transfer the _Current Prod_ MediaWiki build, with a snapshot of the wiki content from _Current
Prod_ as at 9th Aug 2011 to form the basis for full scale testing pre-prod. This will content
be stale and not synced to _Current Prod_.  All wiki content changes with be discarded
task 12. \[complete\]
# Integrate agreed backup and cache acceleration options on _Target_.
# Integrate agreed zero-admin management scripts
# Perform load testing an project evaluation of performance on _Target_ off-production.
# Agree branding changes to be applied to wiki and implement on _Target_ as a test off-production.
# Develop and maintain list of post-cutover improvements and fixed
# Obtain go-validation from project including DNS cut-over.
# (48 hrs before DNS cut-over) Bring _Current Prod_ offline for \~3 hrs whilst the current
prod D/B and file system updates post 28th Jul 2011 are backed up, transferred to Apache and
loaded onto _Target_. Reapply branding changes. Oracle to enable DNS redirection for all []
to Target’s external public IP address. Bring service back on-line: _Target_ is now the
Live Production environment, albeit though DNS redirection from the still Oracle-managed
domain. The service on ex\-_Current Prod_ is now offline.
# DNS cut-over. This takes up to 24hrs to cascade globally. User access to Live Production
continues whether direct or redirected via the Oracle IP addr. The now ex\-_Current Prod_
can be decommissioned by Oracle as necessary.

h1. Issues and Other Requirements

* All existing account-based access for legacy wiki must be disabled on this pre-prod instance.
 Only project-approved accounts can be enabled for update access.

* Assuming production at some point, how *will* accounts be initiated and managed?

* Any branding changes can be prepared and developed on the pre-prod instance.  The authors
can use standard MediaWiki export/import functionality to preserve such content when this
D/B is overwritten at live cut-over

h1. Status page

| 1. | Build of Test VM | completed 02-Aug-2011 | terrye |
| 2 | Initial Build of Target VM | completed 05-Aug-2011 | gmcdonald, rbircher |
| 4 | Obtain project endorsement for test migration | completed 09-Aug-2011 | as per DL |
| 5 | Transfer the _Current Prod_ MediaWiki build and available for testing at [
|]   | completed 10-Aug-2011 | terrye |
| 6 | terrye leaves project. | 04-Sept-2011 | |
| 7 | Due to possible lack of project support for MediaWiki in the future, discussion has
now turned to the possible use of Confluence (the already supported Apache wiki) for use as
the Apache OpenOffice (community) wiki | 06-Sept-2011 | |
| 8 | Wiki demise scheduled for Friday, 29-Sept-2011. See *Salvage Plan* below.| 21-Sep-2011|
_tj_ |

h1. Salvage Plan
h2. Background
h3. Problem #1
The OO.o wiki is scheduled to be shut down as of Friday, 29-Sept-2011.
h3. Problem #2
Operating the live wiki here on Apache is not considered feasible. Neither Infra nor the project
has been able to identify sufficient volunteers with sufficient skills to maintain a MediaWiki
installation in the long term, to a level that makes everyone comfortable.

No problems have been reported with the static wiki copy on Apache. This suggests that an
almost-static copy could be maintained for the middle-term with no insurmountable problems.
h2. Proposed plan
Capture a final dump from the live wiki, and install on Apache. This will be almost read-only,
requiring only a few notices from time to time. (TJ expects to be the only writer.) Required
maintenance (by Infra) should be absolutely minimal. Migration of various parts of the data
can then proceed, in parallel and as time allows.
The interactive benefits of the wiki will be lost, but it will still be a source of information.

*Action items:*
h3. Andrew Rist, for Oracle
* Promote TJFrazier to bureaucrat on the live wiki.
* Provide a date-certain for the shut-down.
* Provide a final data dump, after shut-down.

h3. Infra
* Prepare to load that final dump. The existing test copy here can be discarded. ASSUMPTION:
Terry's scripts/instructions are available and can be followed.
* Re-activate TJFrazier account after password-scrambling. The necessary command-line MySQL
command is available.
* Prepare to work DNS-magic for outside links to the wiki. 
* Provide what dates you can (dependent on shut-down date) to TJ, for communication to users.

h3. TJ
* Post notices on live wiki, as soon as dates (and URLs?) are available, to warn users.
* Fix DPL/template problems on new copy. (Minor.)
* Ongoing: post notices like, "This manual has been moved. Please see LINK for the latest

Change your notification preferences:

View raw message