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 Sat, 05 Nov 2011 16:49:00 GMT
Space: Apache Community (
Page: Community Wiki Services (

Change Comment:
Update overview and task breakdown

Edited by Terry Ellison:
h1. Overview

The Community wiki is hosted under the domain []
comprise some 10,000 content pages and 11,000 uploaded files (“_Current Prod_”).

The "*{_}legacy wiki{_}*" was based on a standard MediaWiki package (version 1.15.1) with
some 40 installed extensions.  The wiki ran 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). This was decommissioned during the weekend commencing
30th Oct 2011, with the content having an update freeze starting 24th Oct and the content
transferred to ASF infrastructure on in the period 24-25th Oct.

The "*{_}new wiki{_}*" was brought up on an Ubuntu 10.04 LTS VM running on the Apache ESXi
production environment, running a MediaWiki package (version 1.15.5) with 33 installed extensions
(any redundant extension were removed as part of migration.) An [Apache Traffic Server|]
reverse-proxy is cohosted on the VM and front-ends the MediaWiki application.  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 were various technical issues to be addressed 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.  \[completed\]-
# -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_. \[completed\]-
# -Integrate agreed zero-admin management scripts. \[completed\]-
# -Perform load testing an project evaluation of performance on _Target_ off-production. \[completed\]-
# -Agree branding changes to be applied to wiki and implement on _Target_ as a test off-production.
\[Deferred to production \]-
# Develop and maintain list of post-cutover improvements.
# -Obtain go-validation from project including DNS cut-over. \[completed\]-
# -_(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 read-only. \[completed\]-
# -_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. \[completed\]-

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, 28-Oct-2011. See *Salvage Plan* below. | 21-Oct-2011
| _tj_ |
| 9 | {color:green}HURRAH\!{color} The wiki will be re-hosted intact. *Salvage Plan* now obsolete.
Current status will be maintained at []
| 24-Oct-2011 | _tj_ |

h1. Salvage Plan

(This plan is now obsolete.)

h2. Background

h3. Problem #1

The OO.o wiki is scheduled to be shut down as of Friday, 28-Oct-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.-
The MediaWiki wiki will be operated and maintained normally.

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:*
(Later note -- Except for the tone of finality, these items will still need to be accomplished.)

h3. Andrew Rist, for Oracle

* -Promote TJFrazier to bureaucrat on the live wiki.- Done.
* 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.- Unneeded. Accounts will remain live.
* Prepare to work DNS-magic for outside links to the wiki.
* Provide what dates you can (dependent on -shut-down- move 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. (In
* Fix DPL/template problems on new copy. (Minor.)
* Ongoing: post notices like, "This manual has been moved. Please see LINK for the latest
information." (Later -- now depends on hosting decisions for documents.)

Change your notification preferences:

View raw message