Rolling over to new MediaWiki
This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigFC112D71993FC584DA975D1C Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 proces= s. 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? 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. - 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. --=20 Karsten 'quaid' Wade, Sr. Analyst - Community Growth http://TheOpenSourceWay.org .^\ http://community.redhat.com @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41 --------------enigFC112D71993FC584DA975D1C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iD8DBQFQY30G2ZIOBq0ODEERAikdAJ0ZAmalWITyFe/JzFp+5D5FVXEpNQCfZoVx mFRgnovPojNyP7VgUDa8pPM= =OXB8 -----END PGP SIGNATURE----- --------------enigFC112D71993FC584DA975D1C--
On 09/26/2012 03:09 PM, 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.
Option two makes sense to me. That way we have the current wiki that's working and shift the dns when the new one is ready.
Advantages? Disadvantages? Different approaches?
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.
- 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.
_______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
-- @jasonbrooks
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 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 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. The new hosting, I think, can come afterwards. Are we ready to move to OpenShift right now?
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?
- 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? 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. Cheers, Dave. -- Dave Neary Community Action and Impact Open Source and Standards, Red Hat Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13
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
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).
I started a page to track this: http://wiki.ovirt.org/wiki/New_website_tasks. I put a list of all the pages on the existing site, sorted by all time traffic. I'll add the links from Garrett's demo site as well, and we can set about locating / writing / redirecting content.
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
The Fedora Project is preparing to roll out https://www.mediawiki.org/wiki/Extension:RSS in their wiki. See example: https://stg.fedoraproject.org/wiki/CNetSecurity Jason
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 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.
The new hosting, I think, can come afterwards. Are we ready to move to OpenShift right now?
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?
- 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?
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.
Cheers, Dave.
-- @jasonbrooks
This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig442D3761E89E1257982D9DE5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 09/27/2012 02:06 PM, Dave Neary wrote: > Hi Karsten, >=20 > 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 free= ze >> the old wiki, do a final import of pages and users, and roll over DNS = to >> the OpenShift instance. >> >> Advantages? Disadvantages? Different approaches? >=20 > 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: >=20 > 1. Upgrade MediaWiki to 1.19.2 - this should be a noop for site visitor= s > 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 replacin= g > ~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 righ= t > now). >=20 > 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 >=20 > 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 (amon= g > others) on topics like integrating Gluster storage, etc. >=20 > 5. Installing the new theme >=20 > 6. Moving to new hosting - either OpenShift or alternate hosting when w= e > 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. >=20 > which do you prefer - redirecting to /wiki, or using modrewrite to spoo= f > 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 wit= h >> MediaWiki 1.19 in Fedora/EPEL, and realized we could skip the problem = by >> using OpenShift directly and immediately. >=20 > 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 applicatio= n > in one directory hierarchy). >=20 > 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 --=20 Karsten 'quaid' Wade, Sr. Analyst - Community Growth http://TheOpenSourceWay.org .^\ http://community.redhat.com @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41 --------------enig442D3761E89E1257982D9DE5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iD8DBQFQZfVa2ZIOBq0ODEERAovmAJ9ezKsK6PUs7b39nAHon4O8Y+W3IgCeIWss rWAHWP9BA2Y9hSkIbol2De0= =FuPk -----END PGP SIGNATURE----- --------------enig442D3761E89E1257982D9DE5--
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.
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?
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).
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?
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. Cheers, Dave. -- Dave Neary Community Action and Impact Open Source and Standards, Red Hat Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13
This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5757A9B7B044898DED5F3BC9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 09/29/2012 05:03 AM, Dave Neary wrote:
Hi Karsten, =20 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 u= p in the update of the current instance. =20 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 servic= es (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. =20 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. =20 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. =20 The reason I use feature partity is because Garrett's made it clear tha= t 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 t= o add (like the extensions download page, better integration with Bugzill= a 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 t= o OpenShift right now?
I think we have 1.19 on OpenShift, so no, there are steps to get there= =2E =20 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. =20 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 th= e 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 --=20 Karsten 'quaid' Wade, Sr. Analyst - Community Growth http://TheOpenSourceWay.org .^\ http://community.redhat.com @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41 --------------enig5757A9B7B044898DED5F3BC9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iD8DBQFQaUYO2ZIOBq0ODEERArPmAKDkfFp6R/TtDrIrIOhRNhgglRN77gCeJnoU GYpYHWW7pgDkQ1dLHAoBc0w= =7rPt -----END PGP SIGNATURE----- --------------enig5757A9B7B044898DED5F3BC9--
On Fri, Sep 28, 2012 at 12:07:06PM -0700, Karsten 'quaid' Wade wrote:
On 09/27/2012 02:06 PM, Dave Neary wrote:
On 09/27/2012 12:09 AM, Karsten 'quaid' Wade wrote:
- 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.
mediawiki119 is available in EPEL6: https://koji.fedoraproject.org/koji/buildinfo?buildID=353584
participants (4)
-
Dave Neary -
Ewoud Kohl van Wijngaarden -
Jason Brooks -
Karsten 'quaid' Wade