This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
Content-Type: text/plain; charset=ISO-8859-1
=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'.
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
Thank you for your understanding, and I apologize for the inconvenience.
Karsten 'quaid' Wade, Sr. Analyst - Community Growth
http://TheOpenSourceWay.org .^\ http://community.redhat.com
@quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41
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 undefined - http://www.enigmail.net/
-----END PGP SIGNATURE-----
I am the maintainer of the mom sub-project. Recently we upgraded the mom build
process to use autotools. Unfortunately this has broken the Jenkins build for
the project. Rather than asking here whenever I need an update to the build
job, I think it makes sense for me to administer that myself. If there is
agreement about this, could someone help me to acquire the relavent permissions?
Adam Litke <agl(a)us.ibm.com>
IBM Linux Technology Center
Content-Type: text/plain; charset=UTF-8
Build Number: 17
Build Status: Still Failing
Triggered By: Started by an SCM change
Changes Since Last Success:
Changes for Build #16
Changes for Build #17
No tests ran.
Started by an SCM change
Building remotely on jenkins.ekohl.nl in workspace /home/jenkins/workspace/ovirt-engine-cli_create_rpms_fedora
Checkout:ovirt-engine-cli_create_rpms_fedora / /home/jenkins/workspace/ovirt-engine-cli_create_rpms_fedora - hudson.remoting.Channel@780a60a5:jenkins.ekohl.nl
Using strategy: Default
Last Built Revision: Revision d77dad3073d8d1c7566ef3ce59901f4d35204e72 (origin/master)
Fetching changes from 1 remote Git repository
Fetching upstream changes from git://gerrit.ovirt.org/ovirt-engine-cli
Commencing build of Revision d77dad3073d8d1c7566ef3ce59901f4d35204e72 (origin/master)
Checking out Revision d77dad3073d8d1c7566ef3ce59901f4d35204e72 (origin/master)
Resetting working tree
No emails were triggered.
java-1.7.0-openjdk.x86_64,fedora17 completed with result FAILURE
java-1.7.0-openjdk.x86_64,fedora18 completed with result SUCCESS
Email was triggered for: Failure
Sending email for trigger: Failure
I was going through the wiki and I'm missing a place with a list of all the services the project has and all the machines (something that gives you a big picture of all the infrastructure).
Is that documented somewhere?
If not I can try to gather all that info and create a new wiki page while learning what do we actually have.
Red Hat Czech s.r.o.
Continuous Integration Engineer - EMEA ENG Virtualization R&D
Tel.: +420 532 294 605
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
RHT Global #: 82-62605
Recently we have added autotools support to the mom build process.
Unfortunately this is breaking the jenkins job since the build process has
changed. Could you help me get the build working again?
There is a script called autobuild.sh in the tree now. Perhaps the jenkins job
can be simplified to only call that script?
Thanks for your help.
Adam Litke <agl(a)us.ibm.com>
IBM Linux Technology Center