Rolling over to new MediaWiki

[Karsten 'quaid' Wade]

On 09/29/2012 05:03 AM, Dave Neary wrote:
> Hi Karsten,
> 
> On 09/28/2012 09:07 PM, Karsten 'quaid' Wade wrote:
>> 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.
> 
> It's even easier than that - you point a MediaWiki 1.19.2 install at a
> 1.16 database, and MediaWiki upgrades the database for you the first
> time you load it. There are also other resources that need to move,
> images & file uploads, themes and so on. But the database upgrade is
> trivial.

OK, great.

>> 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.
> 
> OK - so we should clarify what we're looking for with AlterWay - two
> servers, one for Gerrit and one for Jenkins, and that's it? Where will
> our git repositories live?

AIUI, Jenkins should be bare metal. Jenkins can be virtualized, but
needs to be larger than a web server.

We also should move Mailman and the httpd served directories (the yum
repositories.) We've also been talking about a new service around the
hooks and plugins, that needs a web host with some kind of application
stack.

>>> 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.
> 
> Parity in the sense of fulfilling the same function as the former
> WordPress pages - providing news, download information, links to
> documentation and community resources - the "features" that are
> currently done in WordPress.
> 
> The reason I use feature partity is because Garrett's made it clear that
> the move to MediaWiki is primarily to replace what the site does now -
> after that we will need to add extensions for things like embedding
> videos and screenshots, providing RSS feeds for news and events,
> including a calendar on the website, all the other cool stuff we want to
> add (like the extensions download page, better integration with Bugzilla
> via the REST API, etc).

OK, I was reading parity as meaning, "we need to update the current
MediaWiki before we move the site to the new instance." +1 to above.

>>> 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.
> 
> I meant in terms of having the service available. Is there anything we
> need to do besides updating DNS and moving the database & files to the
> new server?

Garrett, anything here?

We'll want to have testing steps in there so we can rollback, etc.

>>> 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.
> 
> I have no opposition to upgrading the standing wiki to 1.19 as a
> preparatory step - with the usual precautions (database back-up, don't
> over-write the old MW install before checking the new one works, etc).
> But if you need a package, then that is not practical. That is up to the
> infra team to decide.

OK. I'm not directly opposed to upgrading the standing wiki to 1.19, but
I think it's an unnecessary step and additional risk and hassle we don't
need. Sounds like the risk and hassle are more minor than I feared, but
if we don't need this step, perhaps we can just skip it?

- 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/20121001/78bc4c0c/attachment.sig>