-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
hi,
on Monday 29th, 5AM - 7AM UTC vandale.toolserver.org will be rebooted for
maintenance. this will affect the toolserver web appliations (JIRA, MediaWiki,
etc). no other services will be affected. the expected time for this
maintenance is less than one hour.
- river.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (SunOS)
iEYEARECAAYFAkjaUzAACgkQIXd7fCuc5vIKagCgiUReO0HxoBoeeheg0Bp9vKf8
YDsAn1N6ZAG+KPGBIrJ+JYFPak0cnUpF
=l5sE
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
(this mail only applies to people with projects on the stable toolserver.)
hi,
i have revised the maintenance schedule for the stable server. the new
schedule provides no additional downtime windows, but reduces the amount of
downtime compared to the old one. the new schedule is documented here:
https://wiki.toolserver.org/view/Using_the_stable_server#What_is_.22stable.…
- river.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (SunOS)
iEYEARECAAYFAkjZ2eQACgkQIXd7fCuc5vJcNACfZo5FrZ9r7Mg9Cyhh/Z3rr7g5
skIAn1jmd77/U1f0OGEk06+DPPenAq02
=tMm0
-----END PGP SIGNATURE-----
Hello all
As of today, access to thumb.php has been disabled for performance reasons.
(Update: TimStarling offered to re-enable it for now. But it WILL go away SOON).
Thumbnail images need to be accessed by their real path, like
http://upload.wikimedia.org/wikipedia/commons/thumb/9/99/Meerkatmascotfull.…
Note that this will work for any size, if a thumbnail in the requested size
doesn't exist, it is created on-the-fly. There are two problems with this:
1) you have to know if the image is on commons or not
2) you have to know the path for the images of a given wiki (in this case,
"/wikipedia/commons")
Note that Special:FilePath SHOULD NOT BE USED to get the URL of the full size
image, for performance reasons.
You should also NOT USE THE API to get the actual URL - for the same reason. We
have to get all info needed locally from the toolserver, from the database or
otherwise.
The best solution IMHO would be a small script on the toolserver that, given a
wiki, an image, and a size, will generate an HTTP redirect to the image file.
This would require us to maintain a database of URL prefixes for all wikis -
could be done as a new column in toolserver.wiki. And for each request, the
script needs to run a query to see if the image is uploaded locally or not.
I'll not be able to build such a script for a while, because I'm quite busy. DaB
said he'd look into it. Let's hope for the best.
-- Daniel
PS: @river: this should really go to to toolser-announce. apparently, i can't
post there. please change that :)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
hi,
there is currently a problem on stable where the web server sometimes stops
responding to requests for a period of time. i am working on resolving the
issue now; in the meantime, there may be some service interruption for users.
- river.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (SunOS)
iEYEARECAAYFAkjSASkACgkQIXd7fCuc5vKvtACgtaZB7mIUjIkYVs/Y2zXFToQR
3g8An1zg7PSg7VS8MH8+UaQx1rZ6CAPm
=d8ja
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
hi,
so the test version of the reports tool is now live at
<http://stable.toolserver.org/reptest/>. the basic framework is in place, but
the user interface needs work, and there are no useful reports yet.
Wuzur (W) has offered to improve the interface. we also need translations
(i18n files). no doubt changes will need to be made to the software, so Python
programmers would be helpful.
i've written some documentation here about how to develop the tool:
<https://wiki.toolserver.org/view/Report_tool> (please feel free to extend
this).
if you'd like to be added to the project, just open a request in the REPORTS
project on JIRA.
- river.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (SunOS)
iEYEARECAAYFAkjP3P4ACgkQIXd7fCuc5vI/8QCgoMZfc8ERufvA4y3RfEPMg8Nk
GpMAn2T/+f7pG0oTEKkmYsZndOYtizZA
=BRms
-----END PGP SIGNATURE-----
Is it possible to locally create some indexes specific for toolserver?
As for now, it will help to seriously speed up most tools. E.g. index
(rev_user,rev_page) will speed up all editcounters, which usually uses
query like
SELECT COUNT(*), page_namespace FROM page JOIN revision ON page_id =
rev_page WHERE rev_user = 37880 GROUP BY page_namespace ORDER BY
page_namespace;
Any ideas whether it would be possible and how useful would it be?
--vvv
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
so, it's quite common that people want various kinds of reports on wikis, which
are usually generated by a standard SQL query. in fact, this is so common that
we have the "query service" to handle these requests.
this isn't the most efficient way to do it, though; a toolserver user has to
run the actual query, and if it's meant to be a regular report, they need to
crontab it to run as needed. there's a lot of duplication of effort.
instead, what about a collaborative 'report' tool? i would envisage this
working as follows: each query (for example, '100 users with most edits') is
described in a file. the exact way isn't that important, but for the sake of
example, the file might look like this:
name=Top 100 editors
# For a slow query, run it once a day from crontab. Faster queries could be
# done on demand (for example, 'when=immediately'), or cached for a certain
# period of time (for example, 'cache=1h').
when=nightly
query=SELECT ...
then for users, there's a web interface where they can select the wiki and the
report they want to run. for queries that need parameters (e.g. those that
report on a particular article), they could select the article (preferably with
a nice ajaxy input box). then the SQL might look like:
SELECT ... WHERE page_namespace=<NAMESPACE> AND page_title=<TITLE>
<NAMESPACE> and <TITLE> would be filled in by the report generator.
the web interface would display the result of the query in a nice,
easy-to-read table (and probably with some kind of XML or CSV export feature).
any project developer would be able to add new queries, which users could
request in JIRA.
as the project would have many developers, i envisage it running on the stable
server. if people are actually interested in doing this, i'd be willing to
create at least the basic framework (hopefully the interface would have several
maintainers who would add nice features).
opinions?
- river.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (SunOS)
iEYEARECAAYFAkjLZI0ACgkQIXd7fCuc5vIsjwCgtnOixZhmqE+SNzQ/vnliTdzF
f7wAmwcdE6ctpH8//aMg79BcsUJuxQNp
=Q0vB
-----END PGP SIGNATURE-----
> -----Original Message-----
> Date: Sat, 13 Sep 2008 07:58:23 +0100
> From: River Tarnell <river(a)wikimedia.org>
> Subject: [Toolserver-l] collaborative report generator?
> To: toolserver-l(a)lists.wikimedia.org
> Message-ID: <20080913065821.GO10237(a)harmony.local>
> Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed
>
> -----BEGIN PGP SIGNED MESSAGE-----
>
> so, it's quite common that people want various kinds of
> reports on wikis, which are usually generated by a standard
> SQL query. in fact, this is so common that we have the
> "query service" to handle these requests.
>
> this isn't the most efficient way to do it, though; a
> toolserver user has to run the actual query, and if it's
> meant to be a regular report, they need to crontab it to run
> as needed. there's a lot of duplication of effort.
>
> instead, what about a collaborative 'report' tool? i would
> envisage this working as follows: each query (for example,
> '100 users with most edits') is described in a file. the
> exact way isn't that important, but for the sake of example,
> the file might look like this:
>
> name=Top 100 editors
> # For a slow query, run it once a day from crontab. Faster
> queries could be # done on demand (for example,
> 'when=immediately'), or cached for a certain # period of
> time (for example, 'cache=1h').
> when=nightly
> query=SELECT ...
>
> then for users, there's a web interface where they can select
> the wiki and the report they want to run. for queries that
> need parameters (e.g. those that report on a particular
> article), they could select the article (preferably with a
> nice ajaxy input box). then the SQL might look like:
>
> SELECT ... WHERE page_namespace=<NAMESPACE> AND page_title=<TITLE>
>
> <NAMESPACE> and <TITLE> would be filled in by the report generator.
>
> the web interface would display the result of the query in a
> nice, easy-to-read table (and probably with some kind of XML
> or CSV export feature).
> any project developer would be able to add new queries, which
> users could request in JIRA.
>
> as the project would have many developers, i envisage it
> running on the stable server. if people are actually
> interested in doing this, i'd be willing to create at least
> the basic framework (hopefully the interface would have
> several maintainers who would add nice features).
>
> opinions?
>
> - river.
> -----BEGIN PGP SIGNATURE-----
This sounds like a really neat and useful idea. Building it sounds like fun
for its own sake, too. But when I read it I was struck by the thought that
the specification and generation of reports is something that many
commercial tools do. (In my real job, one of the things that the software I
work with does is feed data warehouses that you can run Business Objects,
Cognos, Crystal Reports, and the like against).
Perhaps it might be worth doing an investigation to see if there is a
freeware alternative to one of those commercial tools that could be
deployed? (let me apologise in advance if this was done already and I missed
it!) And if there is none, consider if this project could be built in a way
that results in reusable components to make such a thing?
Here is an example:
http://www.jaspersoft.com/downloads.html
I have not evaluated this to see if it's truly "free" enough, or a technical
fit, or whatever, I just found it with a quick search, but it suggests that
free report generators/designers might be out there if we look.
Here is another one:
http://www.freereporting.com/
Same caveats... (in particular this one is not open source... so presumably
a non starter. it's just an example to consider.)
Now of course, we may not want to give the ability to create reports of
whatever sort, schedule them, and have them run, consuming who knows how
much resource, etc to "just anyone"... maybe we'd want to see some sort of a
"design/review/proposal/approval" process in place before a report went live
(but we'd want that in any case I'm guessing, even with something done
ourselves)
I hope this is helpful. I will say that being able to generate reports that
I design would be exceedingly useful functionality regardless of how it is
realised.
Larry Pieniazek
Hobby mail: Lar at Miltontrainworks dot com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
hi,
due to a failed linecard in the switch at knams, yarrow.toolserver.org, the
database replica for s1 (enwiki) and s3, is currently offline. this means s1
and s3 clusters are inaccessible from all servers (including stable).
hopefully someone will be able to visit the colo tomorrow and connect yarrow to
a different card until the failed module is replaced.
- river.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (SunOS)
iEYEARECAAYFAkjDFWoACgkQIXd7fCuc5vIHmQCgrYB2qGCX+Q9yePDUfNpTlIgu
4mEAoIR6ZWnJtFVmave88YJ7/xkRnSCH
=uPU+
-----END PGP SIGNATURE-----
