Rolling over to new MediaWiki

Fri Sep 28 19:07:06 UTC 2012

On 09/27/2012 02:06 PM, Dave Neary wrote:
> Hi Karsten,
> 
> On 09/27/2012 12:09 AM, Karsten 'quaid' Wade wrote:
>> Garrett's new MediaWiki skin is getting close to completion, and it
>> happens to run on MediaWiki 1.19, which we need to upgrade to.
>>
>> We have a few approaches:
>>
>> 1. Staggered upgrade - update MediaWiki 1.19 (either with an RPM or
>> ZIP), test, then update the theme. Do move to OpenShift as another
>> process.
>>
>> 2. One rollover - create the new site with the new version and the new
>> theme on OpenShift, import the data (pages and users), test; then freeze
>> the old wiki, do a final import of pages and users, and roll over DNS to
>> the OpenShift instance.
>>
>> Advantages? Disadvantages? Different approaches?
> 
> It seems to me that we can cut things up into different bits, each of
> which is independent. We can do some of the things independent of
> getting the new site ready to go:
> 
> 1. Upgrade MediaWiki to 1.19.2 - this should be a noop for site visitors
> and users

It occurred to me that we could skip the upgrade to 1.19.2 for the
current site. Can't we just migrate the data directly? There must be a
process or tool for updating the database before moving to 1.19.2, so we
i) copy the 1.16 data, ii) convert it to 1.19 data, iii) pull that in to
the new site.

Otherwise, I don't see the value in going through whatever will come up
in the update of the current instance.

> 2. Preparing the content of the site for the migration - we're replacing
> ~15 pages managed by Wordpress by ~6 or 7 wiki pages - we need to make
> sure all the links work, point at existing pages when it's appropriate,
> and we need to do the copy writing for Develop, Documentation and maybe
> review the contetn of Community (which is a bit wordy for my taste right
> now).
> 
> 3. Install extensions which we need for the new site - we need to
> evaluate first. I'd like to have an RSS extension, perhaps a Calendar
> extension, and one for embedding videos from YouTube
> 
> 4. Updating the content with some of the new content we have - videos
> and screenshots a-go-go, the updated installation guides that Jason has
> created, gathering links of blog entries from RobertM and jbrooks (among
> others) on topics like integrating Gluster storage, etc.
> 
> 5. Installing the new theme
> 
> 6. Moving to new hosting - either OpenShift or alternate hosting when we
> have it.

I'm still in favor of using OpenShift. It reduces the number of services
(and servers) that Infra manages. MediaWiki is a commodity service, so
perfect for a PaaS; cf. Jenkins and Gerritt that are key to the
development, so making those core services we manage makes more sense.
Similarly, I'd like to move Mailman over to OpenShift; I think we're
still waiting for some SMTP features.

> I think we can do the MediaWiki upgrade and extension selection now and
> completely dissociate those from the new website deployment.
> We definitely need to get to "feature parity" with the old site ASAP,
> and I think we need to integrate some newer content too pre-launch.

Yeah, I'd like to understand further why parity is necessary.

> The new hosting, I think, can come afterwards. Are we ready to move to
> OpenShift right now?

I think we have 1.19 on OpenShift, so no, there are steps to get there.

>> Garrett - we have our install at /wiki, which is a bit standard, and
>> there are reasons AIUI:
>>
>> http://www.mediawiki.org/wiki/Manual:Wiki_in_site_root_directory
>>
>> Note the admonition that doing the wiki at root-level means no support
>> from Wikimedia developers.
>>
>> The idea to make the MediaWiki instance the entire site means we need to
>> decide how we want www.ovirt.org to resolve, same with wiki.ovirt.org,
>> and do we hack MediaWiki to make it work with / instead of /wiki.
> 
> which do you prefer - redirecting to /wiki, or using modrewrite to spoof
> it?

I think it would be prettier, but I am wary of deviating from the
upstream way of doing things. Just using the EPEL RPM gets raised
eyebrows, even though it no longer moves things around (using symlinks
instead.)

>> - Karsten, who wrote all this when about to check on the situation with
>> MediaWiki 1.19 in Fedora/EPEL, and realized we could skip the problem by
>> using OpenShift directly and immediately.
> 
> What is your position, in general, on using upstream releases from
> .tar.gz? Do you think we should require an RPM?

Package is superior. But there is no 1.19 RPM from Fedora or EPEL, and
OpenShift can be thought of as another package format.

> There's a little issue upgrading 1.16 to 1.19 you should be aware of -
> $IP isn't set in the local config file any more, it's calculated at
> runtime - and it didn't quite work with the way Fedora packaged the RPM
> previously (to simplify, MediaWiki expects to find the whole application
> in one directory hierarchy).
> 
> Anyway, I favour doing it step by step if we can.

Sure, I think that makes sense. All-at-once rollover is more of a MO
around if we upgrade the standing wiki or not. I think we'll want to
take things in steps and stages, for sure.

- Karsten
-- 
Karsten 'quaid' Wade, Sr. Analyst - Community Growth
http://TheOpenSourceWay.org  .^\  http://community.redhat.com
@quaid (identi.ca/twitter/IRC)  \v'  gpg: AD0E0C41

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 251 bytes
Desc: OpenPGP digital signature
URL: <http://lists.ovirt.org/pipermail/infra/attachments/20120928/129afb89/attachment.sig>