Change Details

* //Current maintainer:// #operations (barely) * //Number, severity, and age of known and confirmed security issues// None that we know of. The third-party software being used is old and antiquated though, possibly riddled with vulnerabilities. * //Was it a cause of production outages or incidents? List them.// The current design is one single daemon operating on a single server, in one datacenter. It, perhaps surprisingly, hasn't been part of a large unscheduled outage in the last few years, but even trivial maintenance tasks like a server reboot, cause short outages and require planning a long time ahead (for example, [[ https://lists.wikimedia.org/pipermail/wikitech-l/2018-January/089426.html | a schedule reboot for Feb 22nd, 2018, was announced on Jan 18th, 2018 ]]. * //Does it have sufficient hardware resources for now and the near future (to take into account expected usage growth)?// Sort of. The resources in terms of serving users are ample, and the service isn't growing. However, it's operating without any redundancy, in terms of both individual hardware failure, and datacenter failure. * //Is it a frequent cause of monitoring alerts that need action, and are they addressed timely and appropriately?// No. * //When it was first deployed to Wikimedia production// Unknown. Many, many years ago. * //Usage statistics based on audience(s) served// Serving almost exclusively bots. The IRC server's own statistics say: "Current global users 288, max 540". * //Changes committed in last 1, 3, 6, and 12 months// None. * //Reliance on outdated platforms (e.g. operating systems) // Relies on a custom, patched version of an IRC server (ircd-ratbox, found in `operations/debs/ircd-ratbox`) that we have to forward-port on every operating system upgrade. See T134271 for an old task that calls for its replacement. * //Number of developers who committed code in the last 1, 3, 6, and 12 months// Zero. * //Number and age of open patches// Probably zero. * //Number and age of open bugs// [[ https://phabricator.wikimedia.org/maniphest/?project=PHID-PROJ-5hz7eiz6llsoqf2krmqy&statuses=open()&group=none&order=newest#R | Six ]], from 2014-2016. * //Number of known dependencies?// None internally. Dozens of external bots depend on it however, for operations like counter-vandalism. Rumour has it that the projects absolutely depend on it for their operation and downtimes of the service are tolling on the editors. * //Is there a replacement/alternative for the feature? Is there a plan for a replacement?// The original replacement was RCStream, which was eventually replaced by [[ https://wikitech.wikimedia.org/wiki/EventStreams ]]. EventStreams is recommended for new projects, and while it has been a successful, well-maintained alternative, it requires porting those bots over to a new protocol (from IRC, to HTTP SSE), and these are controlled by volunteers at best (some may be even abandoned). Several people (including @ori, the author of the original replacement, RCStream), feel that fully deprecating the IRC feed is unrealistic and that we should keep and expand it, As an alternative, @faidon proposed building an API-compatible replacement instead, that would consume from Kafka but be designed with scalability in mind. He provided a rudimentary proof-of-concept [[ https://gist.github.com/paravoid/3419e0b5ae1f24b6ea21906a142f2f47 | on his GitHub ]], but estimates it will require more of an investment to productionize. @ottomata and #Analytics is potentially interested in doing so and maintaining it further.

* //Current maintainer:// #operations (barely) * //Number, severity, and age of known and confirmed security issues// None that we know of. The third-party software being used is old and antiquated though, possibly riddled with vulnerabilities. * //Was it a cause of production outages or incidents? List them.// The current design is one single daemon operating on a single server, in one datacenter. It, perhaps surprisingly, hasn't been part of a large unscheduled outage in the last few years, but even trivial maintenance tasks like a server reboot, cause short outages and require planning a long time ahead (for example, [[ https://lists.wikimedia.org/pipermail/wikitech-l/2018-January/089426.html | a schedule reboot for Feb 22nd, 2018, was announced on Jan 18th, 2018 ]]. * //Does it have sufficient hardware resources for now and the near future (to take into account expected usage growth)?// Sort of. The resources in terms of serving users are ample, and the service isn't growing. However, it's operating without any redundancy, in terms of both individual hardware failure, and datacenter failure. * //Is it a frequent cause of monitoring alerts that need action, and are they addressed timely and appropriately?// No. * //When it was first deployed to Wikimedia production// Many, many years ago ([May 2005](https://lists.wikimedia.org/pipermail/wikitech-l/2005-May/016990.html)). * //Usage statistics based on audience(s) served// Serving almost exclusively bots. The IRC server's own statistics say: "Current global users 288, max 540". * //Changes committed in last 1, 3, 6, and 12 months// None. * //Reliance on outdated platforms (e.g. operating systems) // Relies on a custom, patched version of an IRC server (ircd-ratbox, found in `operations/debs/ircd-ratbox`) that we have to forward-port on every operating system upgrade. See T134271 for an old task that calls for its replacement. * //Number of developers who committed code in the last 1, 3, 6, and 12 months// Zero. * //Number and age of open patches// Probably zero. * //Number and age of open bugs// [[ https://phabricator.wikimedia.org/maniphest/?project=PHID-PROJ-5hz7eiz6llsoqf2krmqy&statuses=open()&group=none&order=newest#R | Six ]], from 2014-2016. * //Number of known dependencies?// None internally. Dozens of external bots depend on it however, for operations like counter-vandalism. Rumour has it that the projects absolutely depend on it for their operation and downtimes of the service are tolling on the editors. * //Is there a replacement/alternative for the feature? Is there a plan for a replacement?// The original replacement was RCStream, which was eventually replaced by [[ https://wikitech.wikimedia.org/wiki/EventStreams ]]. EventStreams is recommended for new projects, and while it has been a successful, well-maintained alternative, it requires porting those bots over to a new protocol (from IRC, to HTTP SSE), and these are controlled by volunteers at best (some may be even abandoned). Several people (including @ori, the author of the original replacement, RCStream), feel that fully deprecating the IRC feed is unrealistic and that we should keep and expand it, As an alternative, @faidon proposed building an API-compatible replacement instead, that would consume from Kafka but be designed with scalability in mind. He provided a rudimentary proof-of-concept [[ https://gist.github.com/paravoid/3419e0b5ae1f24b6ea21906a142f2f47 | on his GitHub ]], but estimates it will require more of an investment to productionize. @ottomata and #Analytics is potentially interested in doing so and maintaining it further.

* //Current maintainer:// #operations (barely) * //Number, severity, and age of known and confirmed security issues// None that we know of. The third-party software being used is old and antiquated though, possibly riddled with vulnerabilities. * //Was it a cause of production outages or incidents? List them.// The current design is one single daemon operating on a single server, in one datacenter. It, perhaps surprisingly, hasn't been part of a large unscheduled outage in the last few years, but even trivial maintenance tasks like a server reboot, cause short outages and require planning a long time ahead (for example, [[ https://lists.wikimedia.org/pipermail/wikitech-l/2018-January/089426.html | a schedule reboot for Feb 22nd, 2018, was announced on Jan 18th, 2018 ]]. * //Does it have sufficient hardware resources for now and the near future (to take into account expected usage growth)?// Sort of. The resources in terms of serving users are ample, and the service isn't growing. However, it's operating without any redundancy, in terms of both individual hardware failure, and datacenter failure. * //Is it a frequent cause of monitoring alerts that need action, and are they addressed timely and appropriately?// No. * //When it was first deployed to Wikimedia production// Unknown.Many, Many, many years agomany years ago ([May 2005](https://lists.wikimedia.org/pipermail/wikitech-l/2005-May/016990.html)). * //Usage statistics based on audience(s) served// Serving almost exclusively bots. The IRC server's own statistics say: "Current global users 288, max 540". * //Changes committed in last 1, 3, 6, and 12 months// None. * //Reliance on outdated platforms (e.g. operating systems) // Relies on a custom, patched version of an IRC server (ircd-ratbox, found in `operations/debs/ircd-ratbox`) that we have to forward-port on every operating system upgrade. See T134271 for an old task that calls for its replacement. * //Number of developers who committed code in the last 1, 3, 6, and 12 months// Zero. * //Number and age of open patches// Probably zero. * //Number and age of open bugs// [[ https://phabricator.wikimedia.org/maniphest/?project=PHID-PROJ-5hz7eiz6llsoqf2krmqy&statuses=open()&group=none&order=newest#R | Six ]], from 2014-2016. * //Number of known dependencies?// None internally. Dozens of external bots depend on it however, for operations like counter-vandalism. Rumour has it that the projects absolutely depend on it for their operation and downtimes of the service are tolling on the editors. * //Is there a replacement/alternative for the feature? Is there a plan for a replacement?// The original replacement was RCStream, which was eventually replaced by [[ https://wikitech.wikimedia.org/wiki/EventStreams ]]. EventStreams is recommended for new projects, and while it has been a successful, well-maintained alternative, it requires porting those bots over to a new protocol (from IRC, to HTTP SSE), and these are controlled by volunteers at best (some may be even abandoned). Several people (including @ori, the author of the original replacement, RCStream), feel that fully deprecating the IRC feed is unrealistic and that we should keep and expand it, As an alternative, @faidon proposed building an API-compatible replacement instead, that would consume from Kafka but be designed with scalability in mind. He provided a rudimentary proof-of-concept [[ https://gist.github.com/paravoid/3419e0b5ae1f24b6ea21906a142f2f47 | on his GitHub ]], but estimates it will require more of an investment to productionize. @ottomata and #Analytics is potentially interested in doing so and maintaining it further.