--=-DvBECKhlQMWW2/tJYDKS Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Le lundi 20 octobre 2014 =C3=A0 11:05 -0400, Barak Korren a =C3=A9crit :
There has been some talk recently about moving the ovirt.org wiki to a de= dicated VM in the PHX data-center. I would like to open this up to some discussion. Here is the current situation as far as I could gather, more info and com= ment are welcome. =20 What do we have now ------------------- MediaWiki (Which version? eedri told me its a rather old one) 1.18 ( or 1.19 )
PHP (Which version?) 5.3.3
MySQL 5.1 All running in a single (?) 'large' OpenShift gear. yes
Our OpenShift account is classified as 'silver' (is it?) thereby granting= us gears with 6GB storage instead=20 of 1GB)=20 yes. I think we even already have 10G
Why do we want to migrate? -------------------------- We occasionally have a problem where the site goes down. This seems to be= caused by one of: 1. The OpenShift gear runs out of space 2. The MySQL DB gets stuck with no errors in the logs (Does restarting it= resolve it?)
Why not to migrate? ------------------- 1. Migrating the wiki to PHX VM will make the infra team have to manage t= he wiki hosting infrastructure.=20 While one may claim that this is not complicated and that this work ne= eds to also be done when the wiki=20 is hosted on OpenShift, there are still many things that the OpenShift=
it usually was out of memory issue. besides the problem, one reason to go to a more traditional setup for me is that, being traditional, we have more freedom. For example, installing varnish directly, having access to log without a middleman, ease of backup. And the capacity to use vanilla mediawiki. maintainers do for us such as:
- Keeping the webservers updated
there is just yum upgrade -y to do. I do not see that much as a hindrance.
- Managing selinux
There is nothing to manage, selinux work out of the box on RHEL. Also, due to the nature of openshift, the policy will only protect the host, but you would still be able to access network and this kind access. While with our own setup, we can have a tailored policy or firewall.
- Enablign automatic scale-up
We have no scale up for that, and due to mediawiki itself, we either have to patch it to not use the filesystem ( people suggested to use s3 ), or wait until fs is shared on openshift.=20
2. There are security concerns with having a public-facing (outdated?) PH= P application running on a VM in=20 the same network where our build and CI servers run. (I might be too p= aranoid here, having had one of my own sites defaced recently, but OpenShift makes it easy to create a ne= w gear and git push the code to=20 get back up and running, with our own VM, forensics and cleanup might = be more complicated)=20
I do not see how openshift will be easier. We can make a snapshot of the VM in ovirt too, afaik, so the forensic wouldn't be harder ( and in fact, would preserve the memory, which is rather important ).
Known infra issues with existing configuration ---------------------------------------------- 1. The MySQL DB was setup without 'innodb_file_per_table' turned on, this= can impact DB performance. To=20 resolve this, one need to dump and import the entire DB. =20 Things we can try (Besides migrating) ------------------------------------- 1. Place ovirt.org behind a caching reverse-proxy CDN like cloudflare, th= at can mask some of our downtime. 2. Dump and import the DB to rebuild and optimize the DB files we need to have a bit more space to operate, that's the issue.=20
3. Rebuild the wiki in a new gear to get rid of possibly accumulating cru= ft 4. Upgrade the MySQL to 5.5 (Or whatever latest supported by OpenShift) We can't do that easily.=20
5. Upgrade MediaWiki We would have to rediff some of the patchs, I would rather start from scratch.
6. Add a redundant MySQL/Wiki server using MySQL replication Not working due to gears isolation. IE, 2 gears cannot communicate that easily. This would be doable with a special embedded cartridge.
7. Trim the wiki history (AFAIK MediaWiki saves every edit ever, but one = can maybe use export/import to get rid of some) =20 Why drop history, that's like dropping git history :/
8. Try to come up with a way to spread the Wiki across multiple OpenShift= gears Rather hard to do, especially since we are not root.
9. Tune DB parameters (is it possible to do on OpenShift?) No, since the mysql is managed by openshift we are not root.
I eagerly await your comments,
I still think the easiest way is to host our own setup. --=20 Michael Scherer Open Source and Standards, Sysadmin --=-DvBECKhlQMWW2/tJYDKS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAABAgAGBQJUR/UuAAoJEE89Wa+PrSK9vwsQAKk3vb4q105VK+TUpYH/SdnU Emn/y3y6zaBNnE0UudOzXp2LhIxCdao7Yri59PnsKM9gjPZJkMPdTwjFuw8S67sm 8MdNCZDz1AkSqHAh2TQyA+iY4L6BOHQQlbSGfxhDH1+ewGhbWVDELNzyvNmUJz01 Y5edB0YVeCeQ7GrGzlF4494edDUnFURQHogVu5tFwqtAzPguruKSsVsuaZMK1SQO H8y0BvBrWUkVsh9y11PbByKx/GspeQb3Jh+7HAcGwUeCIAcq7cPT1SdZePXsjb9p 9ruyHu/2V91W8KuQ7eVCkqAPXwFn+cjJCFwj9XFxks/XlcOSVZibleFjxYiOEGzL QyDozkldM5/FRaqynLtpuxtS0hwRMIS8EZLin36fut0RBTiE2V8I8htzthwk+Kgf IHe9II54wzdcjNvfXt2xMvqSURP0siTj6P20SxLnLTtMR/es14x/ugIbYiMP2HE+ AZQBTUlke6vSumKp0AlOsK5WN/uv6tcRplz3A/YQATs8xdZA1q8Leeeg8Nx96yRt +UsxQwFMf6ecsKKXxFNi1WcV1IlniOJdMEkFXsRmd3LKUYvdHPs2YE1RqFszcp4I E0jHV8quh0gB/9qlkuLrhRt211bV456ZHaGLCT4/uBWEDrScOh+RIkavd/iwX3jQ W8hBxZuklseO/W71vK8s =+no9 -----END PGP SIGNATURE----- --=-DvBECKhlQMWW2/tJYDKS--