[Users] What's going on with images on the wiki

This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8EFCB4C6FA6FBF29C5B15E65 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable =3D=3D Summary =3D=3D Since the migration to OpenShift, due to a misconfiguration of MediaWiki, we were writing images uploaded to the wiki to a non-persistent data store location. This means that most images uploaded since the migration may have been destroyed, including archives of past versions of images. =3D=3D What's next =3D=3D Jason Brooks and I diagnosed the problem and fixed it last night. We didn't completely figure out which images were removed, but it's likely to be most or all the images since the migration. For any images you still have -- possibly including older version of the images -- we can likely reinsert them in to their (new) location in the filesystem and MediaWiki will pick them up. (Older versions are stored in 'images/archives/'. Depending on the trickiness of the problem, we may be able to reinsert the archived images.) Email me with details of what images you have, page names, and so forth. I'll work to get each one back where it belongs. Feel free to file a ticket on Trac at http://fedorahosted.org/ovirt to help keep track of the details. Or you can reply with details (but not images) If you've lost any work as a result of this mistake, please accept my apology. It was a mistake that didn't show itself in testing post-migration (which points to failings in the testing.) =3D=3D Questions and comments =3D=3D It's possible we haven't optimized our solution from here. Feel free to chime in with your thoughts and questions. (Please read the 'Details' section below first.) =3D=3D Details =3D=3D When I configured the MediaWiki instance on OpenShift, I made the writeable 'images' directory a symlink to what I thought was the persistent data store location. This appears as 'wiki/data', where the MediaWiki code and content live in 'wiki/php'. cd wiki ls -hal | grep images images =3D> ../data That is, 'wiki/php/images' was a symlink to 'wiki/data'. (Un)fortunately, 'wiki' is all entirely in a git repository. That means I copied the images from the old MediaWiki instance in to a git repository that OpenShift uses to completely rewrite the folder structure on the server every time the code is checked in ('git push'.) As it happens, the true persistent data store is '../../data', that is, one directory *above* the 'wiki' directory. When you put content in there, it is not overwritten with each 'git push'. What happened this week was I did an outage window on Monday to push a change to the app to make it hot deployable. (I actually did the same thing last week, but I don't know if anyone had uploaded any new images.)= When I did a 'git push' of my changes, I apparently overwrote the 'wiki/data/' directory with my older copy of the content. I did a 'git pull' before pushing but nothing came down; I'm not sure why but I believe it has to do with the way OpenShift is configured. Since Monday night, people began noticing images broken, complaints on making thumbnails, and so forth. Jason and I worked on the problem on Tuesday and figured out the solution. He moved all the content to the persistent data store (also, got our quota doubled to 2 GB as we were almost at 1 GB), and removed the data from the git repo. In the end, Jason added a build hook that i) makes sure the '../../data/images' directory is present, then ii) creates the necessary symlink in the 'wiki/' structure after the code is checked in. The same was done for 'compiled_templates', which was previously a symlink for the MediaWiki Widgets extension. (That symlink was also incorrectly written, so it may have been part of problems with the new Widgets extensions?) Thank you for your understanding, and I apologize for the inconvenience. - Karsten --=20 Karsten 'quaid' Wade, Sr. Analyst - Community Growth http://TheOpenSourceWay.org .^\ http://community.redhat.com @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41 --------------enig8EFCB4C6FA6FBF29C5B15E65 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" --------------enig8EFCB4C6FA6FBF29C5B15E65--