Decommission NodeJS IPoid service
Open, Needs TriagePublic
Actions

Assigned To

None

Authored By

	kostajh
	Feb 5 2026, 5:25 PM

Description

Summary

Once we are satisfied with the stability of the iPoid-Service (IPoid OpenSearch) setup, we can remove the NodeJS IPoid service from WikiKube, remove its database, and clean up other references to it.

Before removing, we want:

SLO conversation to be finalized
reads are happening across both data centers

Acceptance criteria

NodeJS WikiKube service is removed
Wikitech pages are updated
misc database for IPoid is removed

Related Objects
Search...

Status	Assigned	Task
Open	None	T416623 Decommission NodeJS IPoid service
Resolved	kostajh	T416164 IPReputation: Switch to OpenSearch backend
Resolved	kostajh	T416316 IPReputation: Improve caching logic to handle backend downtime

Event Timeline

kostajh created this task.Feb 5 2026, 5:25 PM

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptFeb 5 2026, 5:25 PM

kostajh added a subtask: T416164: IPReputation: Switch to OpenSearch backend.Feb 5 2026, 5:26 PM

RLazarus added projects: ServiceOps new, ServiceOps-Services-Oids.Feb 5 2026, 5:27 PM

RLazarus moved this task from Inbox to Radar (Awareness) on the ServiceOps new board.

RLazarus subscribed.

bking subscribed.Feb 5 2026, 7:44 PM

kostajh closed subtask T416164: IPReputation: Switch to OpenSearch backend as Resolved.Feb 19 2026, 1:00 PM

Dreamy_Jazz mentioned this in T384509: ipoid: Use consistent patterns for asynchronous code.Feb 24 2026, 3:05 PM

Dreamy_Jazz mentioned this in T384507: ipoid: Identify import process bottlenecks.

Dreamy_Jazz mentioned this in T384279: Investigate if timeouts during import are recoverable.

Dreamy_Jazz mentioned this in T384013: Investigate a new cron job to emit stats from.

Dreamy_Jazz mentioned this in T383898: Instrument data point to view status of `tunnels.anonymous`.

Dreamy_Jazz mentioned this in T383895: If `tunnels.anonymous` no longer uses the NULL value, remove support for it.

Dreamy_Jazz mentioned this in T383773: Catch errors from ipoid schema updates and push to logstash.

Dreamy_Jazz mentioned this in T383770: Improve ipoid's grafana dashboard.

Dreamy_Jazz mentioned this in T358448: Support pagination of results.Feb 24 2026, 3:09 PM

Dreamy_Jazz mentioned this in T354944: Ensure database is up-to-date with latest data file.

Dreamy_Jazz mentioned this in T347488: Decide how to represent missing data vs unexpected data.

Dreamy_Jazz mentioned this in T343943: Investigate: Normalize how we log errors when importing data.

Dreamy_Jazz mentioned this in T351793: Refactor mariadb calls.

Dreamy_Jazz mentioned this in T355400: Refactor/DRY date handling in import script.

Dreamy_Jazz mentioned this in T350351: Investigate: Missing import declarations in unit tests.

Dreamy_Jazz mentioned this in T348479: Consider a CLI framework for ipoid.

Dreamy_Jazz mentioned this in T347417: Investigate: Stop storing unnecessary data in the ipoid database.

Dreamy_Jazz mentioned this in T345151: Support capability to inform WMF tools about new, removed, and updated information .

Dreamy_Jazz mentioned this in T325641: Investigate: Next steps for /all (v2).

Dreamy_Jazz mentioned this in T351430: Epic: Improve logging for ipoid app.Feb 24 2026, 3:13 PM

Dreamy_Jazz mentioned this in T356180: Error: Invalid date passed. Date should be in yyyymmdd format..

Dreamy_Jazz mentioned this in T355261: Ensure that timeout errors are caught and logged.

Dreamy_Jazz mentioned this in T355260: Ensure that shell script errors appear in Logstash in ECS format.

Dreamy_Jazz mentioned this in T375371: Expose metric for last successful ipoid import date.

Dreamy_Jazz mentioned this in T358617: Simplify log messages and add more useful information to messages.

Dreamy_Jazz mentioned this in T353538: Log unknown actor, risk and tunnel types.

Dreamy_Jazz mentioned this in T351746: Include batch file context lines when throwing an error.

Dreamy_Jazz mentioned this in T355048: Observability: Emit metrics event per request and emit latency per request.

Dreamy_Jazz mentioned this in T355051: Observability: Emit counts in data pipeline.

Dreamy_Jazz mentioned this in T355136: CI should report failed assertions and not time out.

Dreamy_Jazz mentioned this in T354642: Respond to osv_dependency_check on ipoid.

Dreamy_Jazz mentioned this in T354639: Un-leaky integration tests for ipoid.

Dreamy_Jazz mentioned this in T359517: Duplicate IP errors for IPs which are not duplicated.

Dreamy_Jazz mentioned this in T359384: IPs sometimes not deleted but updated with old data.

Dreamy_Jazz mentioned this in T359181: Data updated incorrectly if yesterday's feed has duplicate IPs.

Dreamy_Jazz mentioned this in T350470: When processing data files, ensure the "ip" key comes first in the stringified JSONs before sorting.Feb 24 2026, 3:16 PM

Dreamy_Jazz mentioned this in T355896: output-sql.js throws an error if actor.client does not exist in the dataset.Feb 24 2026, 3:16 PM

Dreamy_Jazz mentioned this in T354314: Provide developer documentation for getting started with ipoid.

Dreamy_Jazz mentioned this in T355133: Add documentation and tests for `--updatedb` and get-latest-run-date.js.

Dreamy_Jazz mentioned this in T393434: Migrate node-based services in production to node22.Feb 24 2026, 3:19 PM

Dreamy_Jazz mentioned this in T355678: Handle ipoid api returning invalid data.Feb 24 2026, 3:25 PM

kostajh updated the task description. (Show Details)Mar 3 2026, 10:07 AM

kostajh updated the task description. (Show Details)

kostajh added a subscriber: Gehel.

RLazarus moved this task from Radar (Awareness) to Radar (Pending) on the ServiceOps new board.Thu, Mar 12, 5:13 PM

@kostajh @Gehel AFAIK the traffic is now migrated, could we clean up the old service?

It was written in description to wait for SLO conversations to be finalized. While technically capturing the SLOs is still ongoing, I don't think it should be a blocker to decommission.

In T416623#11752681, @MLechvien-WMF wrote:

@kostajh @Gehel AFAIK the traffic is now migrated, could we clean up the old service?

It was written in description to wait for SLO conversations to be finalized. While technically capturing the SLOs is still ongoing, I don't think it should be a blocker to decommission.

Yes, I think we could do that.

In T416623#11757466, @kostajh wrote:

In T416623#11752681, @MLechvien-WMF wrote:

@kostajh @Gehel AFAIK the traffic is now migrated, could we clean up the old service?

It was written in description to wait for SLO conversations to be finalized. While technically capturing the SLOs is still ongoing, I don't think it should be a blocker to decommission.

Yes, I think we could do that.

You can refer to https://wikitech.wikimedia.org/wiki/Kubernetes/Remove_a_service as a starting point, please do not hesitate to reach out if you need support from us.

Decommission NodeJS IPoid serviceOpen, Needs TriagePublicActions