MediaWiki

Wikimedia Labs/Tool Labs/Needed Toolserver features

< Wikimedia Labs | Tool Labs
(Redirected from Wikimedia Labs/Toolserver features wanted in Tool Labs)

In addition, please do not add new requirements to this page. Please open a bug in Bugzilla using this link.


This page contains a list of Toolserver features needed in Tool Labs.

Database replication/access

edit

Filesystem / shared storage

edit
  • project-directories for working together.   Done Please see wikitech:Help:Shared_storage#Project_storage for documentation
  • home-directories.   Done Please see wikitech:Help:Shared_storage#Home_directory_storage for documentation
  • common-directory for wikimedia-dumps with an automatic update of them.   Done
  • common-directory for page-stats with an automatic update of them. -> status? planned? in place?
  • Quota limits on filesystem usage / method for users to check their quota usage   Done

Note: April 7th, 2013: The above items are marked as done, but WMF is currently working on a replacement of glusterfs. The features are there though and will be.

Question (copied here from the bottom of the page): Is there a way on Labs to easily share data across all projects? --Nemo 05:15, 26 September 2012 (UTC)[reply]

  • There is no technical hurdle to doing so (it would be fairly simple to share a NFS volume accross more than one project, for instance) but there are important considerations to keep in, the most sallient of which is that access to root on some projects is not particularly limited, so any files on a share volume might as well by considered publicly writable.
    That said, we might have a terminology confusion; "project" in the context of the Labs is a set of instances (virtual machines) sharing users and settings, of which the Tool Labs proper is one. If you meant between bots, or other tools, then that is provided by default and manageable through normal Unix file permissions. — MPelletier (WMF) (talk) 13:31, 26 April 2013 (UTC)[reply]

Languages

edit

Web

edit
  • Server/project for web tools and pages.   Done

Bug tracker

edit

This is now an issue on bugzilla: bugzilla:58794


  • Bugreporting-site (issue and bug tracker like JIRA or bugzilla) with the possibility to create (sub-)projects that can administrate by an user/project.
    • preferably with conversion/migration from TS JIRA to the new one on labs

Open questions:

  • Do we know if an import from jira is possible or if jira's content is going to be lost?
  • Can this bugzilla instance also host user projects or "products"? E.g. like "DrTrigon's tools"? What about migration from JIRA? --DrTrigon (talk) 19:36, 24 January 2013 (UTC)[reply]
    1. Yes, every tool will be given a component for their own support on request.
    2. It is not clear that migration of data from Jira is feasible. There is no technical hurdle, both Jira and Bugzilla have APIs that would allow it, but someone would have to write a tool to fetch, filter, convert and recreate issues – this is a major undertaking. — MPelletier (WMF) (talk) 19:25, 8 April 2013 (UTC)[reply]
    • ACK. There are some reports on successful migrations, and there is even a Python client for JIRA somewhere, but this should be tested on some obsolete JIRA project first, and even then will probably require a lot of manual intervention. While most of the JIRA issues relating to Toolserver specifics aren't that interesting to archive, I think there's some historical value in them so if there is a reasonable way to migrate them, we should do that. --Tim Landscheidt 19:41, 8 April 2013 (UTC)[reply]
    • A quick search on google lets me tend to following scheme JIRA→XML→(adopt data)→XML→bugzilla. For this we need:
      • An xml export of jira data - how to get this? Who has the permission to do this? (TS admins?)
      • Somebody has to write a script that does the (adopt data) part - volunteers?
      • The new xml data have to be imported to bugzilla - how to do this? Who has the permission? (labs admins?) --DrTrigon (talk) 10:57, 22 September 2013 (UTC)[reply]

Version control

edit
  • Git repositories   Done (people can already request Git repositories in Gerrit for labs stuff)
    • To clarify, I'm fine with people hosting their code in SVN. What I'm saying is that WMF won't provide a SVN hosting solution. If volunteers want to create an svn project in Labs, and run svn.wmflabs.org, that's fine.--Ryan lane (talk) 21:52, 20 December 2012 (UTC)[reply]

Logs/Stats

edit

Which of the following items are crucial? Which are rather nice-to-have?

Job-system

edit
  • Job-system for executing of non-web-tasks, e.g. stable cron.  Done
    • crontab or else without "(CRON) CAN'T FORK (child_process): Not enough space." issue, please confer Cron#Timing and work load
    • may be add a queue system like SGE
  • Various resources like run-time, needed databases, free memory and user-slots.  Done
  • Automatic switch-over and moving in case of a server-failure.  Done
  • Possibility to let a non-root maintain the job-system (adding resources, killing jobs, etc. pp.).  Done

Backup

edit

FYI: Any backup done by ops is for disaster recovery. So automated backups are not restorable by users without ops intervention. Users should make their own backups to the project storage. Silke WMDE (talk) 17:41, 5 April 2013 (UTC)[reply]

  • Automated daily backups for user- and project-directories for minimum 1 week.
  • including crontab and all other necessary configuration files   Done
  • backups of user databases
    • Backups of databases should likely be handled by users, and saved in project storage--Ryan lane (talk) 06:11, 26 September 2012 (UTC) It's possible that we'll do automatic backups of the user databases as well, assuming they are provided by a database service.--Ryan lane (talk) 01:29, 2 October 2012 (UTC)
  • A bit of news on this point: the current experimental new filesystem is slated to provide "time travel" snapshots at fixed intervals in the past (several hours, several days, possibly a few weeks). This provides a measure of "oops-correction" backups.
    Best practice, however, is to make certain that important code and configuration be stored in git to allow keeping the full history. — MPelletier (WMF) (talk) 19:29, 8 April 2013 (UTC)[reply]

Various

edit

Mail: to do

edit

See bugzilla:58796


Uncertain how this is going to happen, but planned to find a way. For WMF, this is a legal question rather than a technical one. Main question: Which domain? Silke WMDE (talk) 10:27, 7 April 2013 (UTC)[reply]

  • discussion at WMF legal   In progress
  • Mail-address for users.
  • Mail-address for projects.
  • Configurable Mail-forwarding for both.

What's the status here? Any progress? --DrTrigon (talk) 08:23, 26 October 2013 (UTC)[reply]

Monitoring: done

edit

Licenses: Info

edit

access to instances: http/sftp

edit
  • SFTP access to instances   Done (ssh access needed)
  • Simple setup to allow HTTP access to projects/instances (reverse proxy, port forwarding, public ip)   Done

Updates

edit
  • transparent updating of packages with security problems/bug   Done

More

edit
  • Local and auto-updated copies of:
    • Wikimedia XML Dumps   Done
      • This is accessible on every instance at /public/datasets
    • visits per page (pagecounts) and project (projectcounts)
    • same visits stats, in database format to allow direct querying

End-user-support

edit

Projects

edit
  • Create generic project for web tools (Bug 40510)   Done
  • Create generic project for periodic/long-running bots   Done
    • It is not clear yet whether people should share instances or create their own. As they are unlikely to interfere with each other, the overhead of N linuxes may not be worth it. Instead it may be more useful to have 1 big instance, or a grid of instances but control distribution with SGE instead of manually.
  • The "production" Tool Labs has a more restrictive environment suited for stable tools that need high reliability, and uses gridengine for scheduling, this is the 'normal' destination for working tools. There is another project, 'bots', which is community maintained and more flexible in its architecture for more experimental tools and development. — MPelletier (WMF) (talk) 19:33, 8 April 2013 (UTC)[reply]

OSM

edit

Moved to tracking bug bugzilla:58797


  • A Postgresql-server for OSM.
  • access to OSM database -> db server with 600 GB of solid state disk space
  • a few terabytes of diskspace to save the rendered map tiles (more or less the same space needed now on the toolserver -> how much is this?)
  • user databases
  • Render-server with enough space to host several layouts.
OSM is being added to WMF production. We'll have a test/dev version of OSM in Labs, but we have no plans on having a quasi-production like version of OSM in Labs.--Ryan lane (talk) 21:08, 20 December 2012 (UTC)[reply]
Without a live OSM-planet-db the labs fails the criteria to replace toolserver. --Kolossos 15:20, 23 December 2012 (UTC)[reply]
The plan is to clean up the styles and tools that are no longer maintained/needed, to move about 10 styles and 5 tools to Labs, to move one style to production.Silke WMDE (talk) 10:39, 6 April 2013 (UTC)[reply]

To be discussed

edit
  • will the database server be fast enough / What does it need to be fast enough?
  • Will rendering work in a VM? (Is this the plan to do it in a VM?)
  • definitions use of terms, avoid misunderstandings about what is "production" and what the Labs part is supposed to do. Please be as explicit as possible.

Render

edit

bugzilla:58798

Things available to Render on the Toolserver which are needed for a transition to WikiLabs/ToolLabs

  • Database access like currently on the Toolserver
  • Possibility to build and run C and C++ apps
  • Possibility to build external C and C++ libraries (app dependencies) from source and install in user directory, without packaging
  • 64-Bit OS for sufficient address space
  • ~28GB physical RAM (comparable to ortelius)
  • CPU with at least 4 cores with at least 3 GHz, which can actually be used in parallel (comparable to ortelius)
  • We need to keep large amounts of data available in RAM. Regenerating it is expensive so we need a server with good uptimes. A VM or server which reboots or needs to be re-setup every month or so is not acceptable.
  • Ideally, we need to use a physical machine like we currently can. It is not yet clear whether a VM will do.

WikiMiniAtlas

edit

depends on:

edit
  • Replicate or transfer MMP (multimaintainer projects) from Toolserver
    • Ryan says: "They can be created in LDAP by making a labsconsole account. Additionally, unless the account needs to directly log in via ssh, there's no request process needed for the user to be used. Alternatively, the user could be created as a system account via puppet."
    • What's that supposed to mean? The migration of (multi-maintainer) projects is the goal of this list, not one of its means. --Tim Landscheidt 12:27, 8 October 2012 (UTC)[reply]
    •   Done (implicitly). On Tool Labs, every tool is multi-maintainer even if there is only one current maintainer; there is no difference between tools with one maintainer or more. — MPelletier (WMF) (talk) 15:59, 8 April 2013 (UTC)[reply]
  • Localisation for tools on translatewiki.net
  • Per-project optional svn and/or git repo
    • For "Tool Labs" that is, since in "WikiDev Labs" this is mandatory workflow
    • Should versioning really be optional? Even for tools, is it ever a good idea not to have a repo? I'd rather improve Git/Gerrit usability and integration. Eloquence (talk) 21:07, 25 September 2012 (UTC)[reply]
      • I think it would be hard to enforce the use of source control, unless someone was policing things, or if we required it to deploy tools (maybe via git-deploy?). Using the deployment system for this actually may be the easiest way to enforce this.--Ryan lane (talk) 22:25, 25 September 2012 (UTC)[reply]
    • Do we want to have a a bare git server for wmflabs (like there svn.toolserver.org), or do it in Gerrit? Or maybe allow any git url so that users can store it where they like (be it gerrit.wikimedia.org, github.com etc.). Krinkle (talk) 02:42, 26 September 2012 (UTC)[reply]
    •   Done Gerrit is available on simple request for any tool maintainer; we could provide a Tool Labs-specific subversion server if specifically needed (e.g. for tools that do automatic version control). — MPelletier (WMF) (talk) 16:19, 8 April 2013 (UTC)[reply]
  • Mysql query killer (especially for queries to the replicated wmf wiki databases)
  • Need a clear story for access to bot credentials - should ownership of bot accounts be shared between all users of the server, or should each bot account be owned by an individual user? If the latter, how will projects get access to the credentials? Note that there are some bad practices going on that might affect this: some tools contain hardcoded bot credentials, and some people share passwords between their user accounts and bot accounts.
    •   Done (insofar as the support is there); there is no need to share credential to user accounts given that the Tool Labs natively supports multi-maintainer projects. Permission for multiple maintainers to operate bots on a single set of credentials (for the bot itself) is a requirement of the target project(s) and will need to be discussed with their communities. — MPelletier (WMF) (talk) 16:52, 5 April 2013 (UTC)[reply]
  • Server statistics, workload, status and else

Permanent blockers for migration of some projects

edit
  • license problems ("i wrote code at work for my company and reuse parts for my bot framework. I have not the right to declare this code as open source which is needed by labs policy")  N Not done
      • This isn't going to change, we should be open and collaborative. Restricting access to code goes against that. DamianZaremba (talk) 11:13, 27 September 2012 (UTC)[reply]
        • +1. We will only ever allow open source and open content. I honestly wonder how you are legally using proprietary software on TS.--Ryan lane (talk) 01:29, 2 October 2012 (UTC)[reply]
          • You cannot simplify that much. E.g. I am operating a bot using a lot of CV (computer vision) algorithms. Some of them WE (wikipedia/wikimedia community) are just ALLOWED to use the code because I kindly asked the owners. But you cannot assume they to agree to change their license just because of TS to labs migration! So this could indeed become a blocker and the "irony" is it affects the mainly the newer algorithms (the interesting ones since they are state of the art - which is a pitty). To summarize; it is a good thing to force open source but we should not be too strict here - as a few people mentioned this was a strength of the TS as I see it. Greetings --DrTrigon (talk) 11:21, 1 January 2013 (UTC)[reply]
          • You're allowed to use the software for now. Is there a license agreement? What happens if you no longer want to support the bot and someone else needs to maintain it? Do they have permission? What if someone copied the software and publishes it? Who's liable? We do have a guideline for exceptions when using closed source software, but it would require proper paperwork (like license agreements from the owner, etc). There's a very good reason we have this rule, and it's insane that TS doesn't.--Ryan lane (talk) 22:49, 4 January 2013 (UTC)[reply]

Bots and webservices project

edit
  • Public webserver for logs   Done
    • CGI (perl, python, ...) for helper tools   Done
    • Text editors: vim (probably some others like nano etc.)   Done
    • Shells - bash, ksh, csh, tclsh   Done
    • Libraries - libtcl   Done (needs puppetize)
    • imagemagick   Done
    • Php, java   Done (needs puppetize)
  • Per-project optional custom MySQL databases   Done (bots-sql1, -sql2 ...) Petrb (talk) 07:36, 18 October 2012 (UTC)[reply]
    • This is on the roadmap. Will likely come some time after replicated databases.
    • Basically similar to the mounted project-wide storage. Not on any individual instance, accessible from within each project instance.
    • Toolserver also has the principle of public databases that can be read from other projects. This is probably something we'd want too, so that projects can build on top of each other.
      • The current concept behind this in Labs is that all databases will be accessible from all instances. Creation/modification/grants/etc. will be handled by sysadmins in the project that owns the database.--Ryan lane (talk) 06:09, 26 September 2012 (UTC)[reply]
  • Some packages to install
    • Flup[1] (Python WSGI)
    • All the packages requested by TS users and now taken as a given; see e.g. tswiki:User:Dab/Debian-Packages and install requests on JIRA – someone make a list
      • Question: What about packages from Debian testing in Labs? Are there repos for newer Ubuntu releases than the latest LTS release? is it the users' responsibility to install them without the package management? How is this planned? (On TS, OSM development requires some packages from testing.) Silke WMDE (talk) 10:22, 7 April 2013 (UTC)[reply]
        • As a rule, we have access to all of Precise and can pull and backport Raring packages when apropriate. When all else fails, a sysadmin can make a package and add it to our own repo (that would be the preferred solution in the scenarios you describe).
          There is no plan to allow the tool maintainers to directly install packages, but they can always install any software locally if they need it. — MPelletier (WMF) (talk) 15:37, 8 April 2013 (UTC)[reply]

Links

edit
Retrieved from "https://www.mediawiki.org/w/index.php?title=Wikimedia_Labs/Tool_Labs/Needed_Toolserver_features&oldid=5094039"