What's going on with images on the wiki

[Karsten 'quaid' Wade]

== Summary ==

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.

== What's next ==

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.)

== Questions and comments ==

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.)

== Details ==

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 => ../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
-- 
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: 253 bytes
Desc: OpenPGP digital signature
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20121212/3bf4765d/attachment.sig>